Cargo Cult Mentality in Software Development
"It's always been this way" isn't a good reason
Contents
Introduction
Have you ever worked on a project where people insisted that the team follow arbitrary rules?
There’s often a reason for the original ‘rule’ but like any Cargo Cult the reason has been long forgotten and lost over time leaving little behind but a blind adherance to a practice in the belief that it somehow magically bestows benefits on a project.
The best example of it for me that I see all the time on teams is the insistence on using fibonacci numbers when estimating.
“We must use fibonacci numbers if we’re to estimate properly” someone on the team will proclaim.
What they are saying is we can only give estimates in terms of numbers from the fibonacci sequence such as:
1, 2, 3, 5, 8, 13, 21, 34 …
Really? Why?
Why can’t I say that I think a story is going to take 4 or 7 days? If that is what I think it will take? Or that it is twice as big as one that took 5 so should be 10?
Well, of course you can and then you’ll be able to see if your colleague understands the reason for the original suggestion to use the number sequence when estimating or is just repeating it as a mantra.
The original suggestion was to avoid people mistaking precision with accuracy. Some people think that are the same thing but they are not.
For example, the mathematical symbol pi (3.14159265358 from memory) could be described as “3” which would be accurate but imprecise or 4.56195139589324562 which is very very precise but completely innacurate.
When estimating effort on software development user-stories they tend to reduce in accuracy the larger they get. When you are talking about a small, specific task then you can give small precise numbers and even a 50% or 100% difference doesn’t really have a huge impact so will still be fairly accurate.
For larger tasks, there is little point arguing whether a task will be 20 days or 21 days - both are likely to be very inaccurate so why worry about the precision?
The suggestion to use the fibbonaci series is to avoid these pointless debates about precision of a number that is innacurate anyway ignoring of course that if supposedly professional adult software developers can’t reach agreement without it escalating into an argument then you likely have other problems on the team that you need to deal with.
The other reason was because there was a trend of using “planning poker cards” where developers would hold up a card to give their estimate. If it sounds childish it’s because it usually was and again, there was a reason which was to prevent ‘anchoring’ where the first number given would be the one everyone converged on instead of people communicating what they really thought and discussing the task - again, if people are not taking the estimating process seriously then you have bigger problems that handing out cards likely isn’t going to solve.
But all these things of the past are fogotten when people are asked for estimates and someone who “used them on their last team” wants to insist that somehow “7 isn’t a valid number”.
Don’t teams often forget that their job is not really to create estimates or split up user stories or come up with velocity measures in points, gummy bears or shirt sizes or any of the peripheral nonsense that some agile consultant once sold someone on … but to actually develop working code that does the job.
Let’s stop obsessing over meaningless numbers !
