The typical question always comes, often in the form: “How long will it take to build this app?” or “To add this feature to a piece of software?”
For non programmers, it may be difficult to understand that giving an answer to such a question is by no means simple. Or, it is not simple giving an answer which is by any means non random, and bears a minimum of truth.
Most software development methodologies often rely on making such a prediction, as a guess.
Guessing, is subject to the same problems commonly studied in Economics and outlined by researchers such as Kanheman and Ariely.
Just in case you had any doubt, people are not rational being, and most of their economical predictions are wrong, depend on the setting, their perceptions, their mood.
When it comest to trying to predict how long a particular software will take, most of the times people err because of being too optimistic, and overestimating their own skills, while underestimating the complexity of the problem at hand.
You can’t really know how difficult a single problem was, until you have completely solved it.
Exactly like economists, software developers are better skilled in explaining the past, than in making realistical predictions on the future.
It is not their fault, we humans have been driven to using quick heuristics in order to give some answers in a very short time. Ariely talks about two modes in which the human mind works: quick and slow. The quick mind does not compute, just gives some fast answer using heuristics.
The slow mind, is the one an economist would use in order to solve a probability problem using pencil, paper and a pocket calculator, or Matlab . The slow mind follows knowledge and a painstaking complex approach, trained and learned, which often involves math, statistics and formulaic approaches.
With the “slow mind” you don’t try to give a quick estimates, you compute an exact value, following a learned approach, may it be computing long division, solving an integral, or computing the expected rate of return of an investment.
You may still be wrong, might have used the wrong formula, or may have used a correct formula outside its field of applicability, but you have significant more chances at getting a more correct answer.
Then, why is it that when it comes to making predictions on time required for the completion of a software problem, developers are asked to “guess” a length of time, on their toes, typically daily during the so called “stand-ups” typical of many Agile approaches? These predictions suffer from anchoring, frame setting, bias.
If someone mentioned a certain number before asking that question, that number influences the answers which are going to be produced from that point on.
The problem is not entirely new, Tom De Marco, stated some thirty years ago, that whenever a software developer is asked a for time prediction, he or she would simply regurgitate an answer. Tom was even too kind in using that description, other ways of describing the process would be too graphic. I would be politically correct to the point of calling the process “pulling a number out of thin air”.
The more experienced the developer, the more realistic the answer, and the less optimistic it is going to be, unless the software developer fails into the very human trap of trying to appear smarter, better and more competitive than his or her peers.
Often an answer is produced just in order to appease clients, or managers, and made to fit existing budget and time constraints: you are practically not allowed to give an answer unless that matches preconceived expectations, which might be wrong.
According to my own experience, people are just terrible at predicting their own behaviour, and being more experienced as a developer does not cure the problem. After all the already mentioned fathers of the non-rational view on economics, Ariely and Kanheman, might be entirely correct, this approach of “guessing” simply does not work, and never will.
Unfortunately, this guess based approach is pretty much the foundation of the so called Scrum Process, in which developers are asked to rate the complexity of software artifacts they are trying to build, and their own productivity is scored according to those numbers.
There are a number of agilist methodologists who would like to remove time estimates completely from the software development, and simply refusing to produce any, whether towards clients or towards management. They are quite vocal, and have actually trying to propel the so called “no estimates movement”, with the handy hashtag #NoEstimates.
They argument that Estimates are too often used as a ‘bludgeon’ to try to get programmers to work faster. That leads to unhappy programmers and poorer software.
Often, and that is based on my own experience across several organisations, programmers are lead to “cheat” inflating their productivity by just working longer hours, desperately trying to “fit” predictions and look faster than they are.
Poor managers might try to exploit that attitude deliberately, trying to squeeze more product from the available budget and resources.
Actually that does not work, as longer hours eventually lead to more tired programmers, making increasingly worse decisions and producing more bugs.
Managers might feel safer dealing with numbers, and having some numbers in front of them, even when those numbers are actually shaky, make the situation at hand appear more “under control”. Unfortunately this “control” on processes which are inherently hard and unpredictable might be only an illusion.
What game is it that we are all playing when making this kind of predictions on time?
Well, the name of the game is gambling, only that few of us are honest enough to admit it.
While construction work is pretty much an exact science when it comes to predicting time, developing software is an entirely different process.
Most of the time, each software development activity is, especially if it has any economic value at all, different from all others so that we developers are often rowing in uncharted territory, and trying to produce something which may bear some similarities to things we did in the past, but is otherwise very unique.
The exact name of the game of making these predictions is gambling, but few of us are honest enough to admit it. It is especially a gambit if the software developer is also an entrepreneur, trying to determine the cost and date of completion of a project.
According to a (very cynical) study, all late software projects had one common factor: they had started late, and the reason for their late start was that they weren’t expected to produce enough economical value. In fact, if a software project produces money, you would indeed start it as soon as possible and devote enough resources to ensure that it is completed in the shortest time possible.
Unfortunately, throwing bodies at the problem will not accelerate the problem solution, this is the “classical man month problem”: adding more resources to a late project, often risks delaying it even more.
Then, what was the morale I was trying to convey?
Developing software is difficult, and relying blindly on methodologies as if they were as sort of panacea, won’t necessarily make the process more predictable, easier or better.
Reality is complex, and any attempt of seeing it under a reductionist lens, in which everything is conveniently simple, is often just an illusion and the product of false assumptions.
Risks mitigation requires understanding that reality is complex. Refusing it may feel more satisfying, like the tale of the hedgehog who was smarter than the fox, because he only knew one secret, but a big one.
Unfortunately, in nature I would bet on the fox survival, while hedgehogs are getting (sadly, despite their cuteness) extinct. The universe we live in is a complex one, with no “simple” unifying theories in sight. Even in software development, understanding that a plurality of views and complexity exist, is a better approach than blindly following a broken process not actually grounded in any science.
So, if you have a scrum master who insists on maximising velocity, start by asking if confusing a measure with an objective is the right thing to do, and if that won’t lead to some interesting office politics and number playing games, which are going to be very detrimental to the general success of the project.
As a guideline, the production of working software should trump all other considerations, and working software is software which works as expected, and satisfies the requirements of its users.
User satisfaction is always king, while developing something shoddy quickly, might eventually cost more and take longer, a lot longer.
As a line of inspiration, my personal view is that software developers should take pride in what they do, and try to produce something which is remarkable and works very well.
Producing correct and better software should come first, rather than producing mediocre software, full of bugs, but respecting an arbitrary metric of “velocity” in a “Agile” process.
Is there anything worse than software developers producing estimates? Yes, there is.
It is their managers, producing even less accurate and even more optimistic estimates, without even being involved in the process of writing software, and often never having written a line of code in their career.
In order to understands the risks of software development, a project manager should have been a software developer, ideally a good one, for a considerable period of time, before switching to a managerial career.
