Plan, plan, plan part II: What you don’t need
This is the next article on planning, and what could go wrong on a huge project, and what to do to avoid pitfalls.
The first part was about technical feature planning. Here, I’m about to write a bit about the very start of the project, the first plan and vision, and what you want to have and what you probably do not want to have.
This article is actually triggered by a friend of mine, Csaba Házi. We work on a same project, and talk a lot about architecture, practices, etc.. When he read the first article, that triggered a conversation about other things too.
Actually we spoked a lot about where and when things went wrong, and what should never happen again, if we start a new project.
We agreed on one thing, that has nothing to do actually with planning, but ignoring it can ruin the whole process:
Only technical people should bring technical decisions.
Of course we were speaking about the legacy system we work on. He was the one who created a workflow from scratch, because there were no workflow engine at that time, that could satisfy the needs of the customers, or more probably the project management.
“We should never create that workflow!” – he said to me. And I was a bit surprised. The workflow was his “child”. And it was stable and well done. I thought he was proud of it. So I diged deeper, and I realized that the sadness came from another sources:
- misuse/overuse – there are flows (or microflows) built with workflow
- complexity – big feature list led to complex system and user interface; it is not easy to build a workflow definition.
- not easy to use
We ran lots of times into workflow definitions that has nothing to do with workflow. For example there are workflows that:
- has no roles (only one role)
- has only 1 step! – This is the worst of all. And the story behind it: developer were instructed by the management (!!) to put one part of the code into a workflow. And he did it… (should I laugh or cry here?!)
- that are too complex to understand, not documented – it is harder to document a workflow, then a simple code.
Probably the biggest problem is, that workflows (definitions) have been never built by customers, – because it is hard to do it. To complex for a simple user. Programmers build them. So the question is: do we need it? If programmers build it, it could be a code (for example a kind of script) too. It would be easier to debug, maintain (what about versions?), install, change.
A workflow could be a great thing. But the question is do we really need it?
We could do without it. For sure. We could use different approach, techniques to accomplish same things. But at that stage, workflow looked so fancy. It was a good selling flag. But in it’s reality, today, we think it should never happened.
So what went wrong?
- We created something that we did not really need. – And now we have to support it until the end of time…
- Non technical staff made technical decision: the “idea” that we need workflow came from the project management.
What we learned is, – same is true for coding -, you should provide only what you must provide. No less, no more.
And 1 more thought: If there is a possibility to remove unused thing afterwards do it as soon as you can.
