The laws of
software development - Part2
A collection of insights and wisdom when in need of a guide
3 min read time
This is the second part of the article “The laws of software development – Part1“.
1 – Gall’s Law
Gall’s law is a rule of thumb for systems design from Gall’s book “Systemantics: How Systems Really Work and How They Fail”. Have you ever wondered why big-bang releases or integrations are so painful? Modern software products are very complex systems, they put together many different technologies and moving parts that need to fit together nicely for the whole system to work. How do we manage this complexity?
We should start with something simple that works, which will later evolve into a more complex solution. This is the basis for the iterative approach advocated in the Agile software development.
This is a valuable approach to reduce risk both technical (earl check that the overall system work, even if much simpler than the final one) and business (do customer like what they see so far?).
2 – Parkinson’s Law
This law was articulated by Cyril Northcote Parkinson and it expresses a very simple notion:
- If you give yourself a year to do something, it will take a year.
- If you give yourself a month, it will take a month.
- If you give yourself a day, it will take a day.
Why does the work expand? There are several reasons, at least three come to my mind:
- the work itself becomes increasingly complex
- procrastination: there’s plenty of time, I don’t have to do this today
- perfectionism: there’s still time left, I can make this better
How do we manage this? Some things that might help are:
- have clear measurable goals, so that once you reach them you know that you can stop
- Identify an MVP, clearly state for each milestone what’s in scope, what’s not
- have timeboxes for all your activities. Scrum uses them extensively (i.e. for all the ceremonies)
- control your perfectionism by keeping in mind the law of diminishing returns: ask yourself what is the effort and the value achieved by the next iteration, stop when the return on the investment is too low
3 – The 90-90 rule
Cargill came up with the “90-90 rule” in 1985 when he was working at the legendary Bell Labs. And yes, that adds up to 180%. Under the humor, Cargill was making an important point: it’s really hard in software development to predict when a task will be completed. Teams that are aware of this take a very pragmatic approach: they don’t report the percentage of completion; instead they break down the work into small more manageable tasks and these are either done or not. Usually, they also define and agree on a definition of done, to be on the same page on what “done” means.
This second article concludes our collection of the laws of software development. We hope you enjoyed them and that they will provide you guidance when you operate in the complex realm of software development.
As usual, we’d love to hear your thoughts: Did you know them already? Have you experienced them in your daily work? Is there any important law for you that is not in our collection? Let us know in the comments.