Many of these rules relate to software development, but can be applied more broadly and produce some interesting learnings for business.
The simplest answer is usually correct.
Recognised long before the time of William of Ockham, after whom the rule is named, the learning from this rule is that minimising your assumptions can lead you to the right answer sooner. If you have competing theories about a problem, then follow first the theory that assumes the least.
Don’t attribute to malice what can be explained by stupidity.
Follows on from Occam’s Razor – it’s much more likely that someone made a mistake than it is that they are out to get you! Remember: Cock-up before conspiracy!
Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.
Endeavour to make things easy as possible for the person who will pick up the project after you because it’s likely that that person could be you! In software, that can mean spending time naming things clearly and seek to make your code understandable to a human instead of just the computer.
Organisations which design systems are constrained to produce designs which are copies of the organisation.
The secret to building large complex software is actually not to! Instead, make lots of small, simple pieces that add up to something greater. Large organisations need to adopt a modular structure to be successful in creating complex systems; this translates to modular and flexible code. Netflix and Amazon are the oft-cited examples of how large organisations have succeeded in building complex systems. More generally, CW implies that big problems are best solved by breaking them down into smaller problems.
Work expands so as to fill the time available for its completion.
Remember your student days when you would leave everything till the last minute? That’s why Parkinson’s Law is also known as the Student effect.
It always takes longer than you expect, even when you take into account Hofstadter’s Law.
When work fills the time available, and something unplanned occurs in that time, then suddenly you’ve missed your deadline. The Planning Fallacy describes just how bad we are at estimating the size of a task, which exacerbates Hofstadter’s Law.
We can try to approach Parkinson’s Law, Hofstadter’s Law and The Planning Fallacy together with some lessons from Agile methodologies. Instead of trying to plan too far in advance, try to plan only for the next month or the next week at most; this is sometimes known as a ‘sprint’ in Agile.
The benefit of short-term planning is that when the unexpected occurs the impact on your schedule is minimal. Furthermore, spending more time executing and less time planning results in real feedback. This feedback can then inform further decision making and allow you to adjust your next plan to make sure you are still on the right track.
Another tenant from the Agile Manifesto is that “Simplicity -The art of maximizing the amount of work not done – is essential”. Simplicity does not come for free. It’s not always easy to decide what work you can afford not to do, or what is making your product more complicated for your customer. The learning is that it’s usually worth spending time figuring out how to make things simple, which can lead to a reduced overall effort.
“So, I think generally you do want to have a timeline where, based on everything you know about, the schedule should be X, and you execute towards that, but with the understanding that there will be all sorts of things that you don’t know about that you will encounter that will push the date beyond that. It doesn’t mean that you shouldn’t have tried to aim for that date from the beginning because aiming for something else would have been an arbitrary time increase.” – Elon Musk
Describes the cognitive bias humans exhibit when they are under-skilled at a task: they routinely overestimate their ability. Additionally, they are less able to detect their mistakes or recognise the errors in their judgement; this tends not to be true of people with greater ability.
It’s inherently difficult to tell if you are exhibiting the traits of the Dunning-Kruger effect, but there is something we can take from it: If you feel like you’ve got it all figured out, be prepared to discover that there’s something you haven’t learned yet.
Ever get the feeling that someone is going to pull the rug from under your feet? Can’t believe that someone has actually trusted you with this responsibility? “Don’t they know I don’t know what I’m doing!?” It sounds like you’re suffering from Imposter Syndrome.
The inverse of the Dunning-Kruger Effect, people with Imposter Syndrome regularly underestimate their ability to perform a task. Sufferers will attribute previous success to luck or the misjudgement of others. Lacking confidence and an inability to execute despite having the ability is the main negative impact.
In software, we are continuously presented with problems. As an engineer, if you do not know how to solve a problem immediately then you begin to search for a solution. On your journey, you come across many potential answers.
Once you have solved the problem, you have learned something, but because you have been exposed to so many alternative solutions that you know nothing about, you end up feeling as though you have less knowledge now than when you started!
What we can take from this is that Imposter Syndrome is actually a side-effect of all your experience. It’s precisely because of the perspective you have gained that you end up feeling like an imposter. The other positive to take is that at least you know you can’t possibly be experiencing the Dunning-Kruger effect!
You can graph the relationship between the Dunning-Kruger effect and Imposter syndrome.
It’s not uncommon for your position on the graph to fluctuate over time. As you overcome more and more problems, you veer from one extreme to the other. There is no get out of jail free card here.
The best way to come to terms with this is to embrace life-long learning. Being ready to accept that there will always be more to something more to know can bring comfort whether you are feeling overconfident or overwhelmed.
Inspired by the article 15 Fundamental Laws of Software Development