Turning things into routine work is advantageous for management. It simply makes them predictable – you know in advance how the job gets done, what the quality of the result will be, and how you can measure progress on the way.
Wouldn’t it be great to run projects like this, and to get rid of all this uncertainty usually going along with them?
The idea is tempting, and traditional approaches for developing software (e.g. sequential processes or CMMI) try exactly that.
To know or not to know
Jobs done in routine are characterized by a high degree of existing knowledge.
As an example let’s take the production of a hamburger at your favorite fastfood restaurant. The desired end product is known in detail, the ingredients as well as the steps to prepare the burger are exactly defined. No problem, but routine repeated thousands of times.
Opposed to this, software development is usually characterized by a high degree of missing knowledge. The users’ needs are typically expressed more or less fuzzy, details about features and technical implementations are only developed over time, the team has to form and learn to cooperate, and eventually some surprising requirements are discovered.
A task associated with obstacles is called a problem. Software projects have many obstacles in terms of unknowns, variables and dependencies. They belong to the most difficult category of problems.
How do you handle that?
Can you treat problem solving the same way as routine work, or is it wise to do so?
Short answer: No.
Problem solving works in a fundamentally different way: One tries a step towards a supposed solution, compares the result with the desired target, learns from this and defines another step towards a better solution. This continues iteratively until the achieved solution is considered good enough.
That means: Defining the perfect solution in advance and then just follow an implemention plan is not possible, at least not for non-trivial problems.
You can’t just absorb information and hope to synthesize it into a solution. What you need to know about a problem only becomes apparent as you are trying to solve it.
Richard MacCormac, 1976
For software projects this implies that an understanding of the requirements must go along with the development of the solution. It’s an iterative learning process – without working on the solution and trying it out the requirements will never be complete.
This phenomenon can frequently be observed: It is exactly the reason why there are always change requests after a demo or a release, because this learning process includes the customer.
The human factor
Understanding how human beings work together in a team also does not leave much room for treating this like routine work. Humans have highly individual ways of thinking and doing knowledge work, of knowledge and experiences, of strengths and weaknesses. These aspects do not only have a significant influence on how the people work together, they also affect the way the problem is solved and how the solution eventually looks like.
Processes in problem solving teams are driven by evolution and dynamics – the traditional tayloristic approach of assigning pure functions to people falls short of this.
So even if it may be desirable – software development can not simply be declared routine work. A modern and productive management of software projects and organizations considers that. It advances the development and efficient usage of new knowledge, and it advances teams by letting people perform and contribute beyond a mere functional role.