Have you ever heard of the principle known as Occam’s Razor (or Ockham’s Razor)? I like to think of it as the law of simplicity — simpler explanations are better — all things being equal. Another way to think about it is that you should always start with what you know in trying to understand a situation, outcome or behavior. Only add complexity when you conclude that your simple approach isn’t good enough.
Every business and every software development team should embrace Occam’s Razor. Start simple. Add complexity as you go. The principle applies both to the software being developed and to the process being used to develop it. Good agile development teams understand this.
Start Simple.
Keeping the software system simple at the outset and adding complexity over time makes good sense. It’s easier to envision, build and test a simple system. As the system becomes more complex, the testing effort benefits from all the work that’s already been done.
It helps the stakeholders and end users too. It’s much easier for them to comprehend and evaluate a simple system than a complex one at the outset. Their feedback will be more focused and constructive.
Add Complexity as Needed.
Keeping the development process simple also makes sense. Why over-complicate the process with rules, procedures, documents and other artifacts that may add little or no value? Only add complexity and artifacts to the process when you’ve identified clear needs.
That’s why retrospectives are so important to the continuous improvement of software development. Don’t try to change too much, too quickly. Make frequent small changes to the process and evolve it rapidly.
If you’d like to be more agile, embrace Occam’s Razor. When in doubt, opt for the simpler approach or solution. The team will make faster progress and it will be much easier to apply corrections and/or re-group. Add complexity if needed, but only if needed.
For a more detailed explanation of Occam’s Razor, read this Wikipedia entry.
Hi Vin
Interesting post….. I had a small quibble about the Occam part and then get to the more meaty aspects I guess.
Occam’s Razor is explaining unknown phenomenon using the simplest theory; that’s different than engineering the simplest system possible (the KISS/YAGNI principle).
Your last sentence says “Add complexity…only if needed”.
I would disagree here.
The Turing Complex theorem states that any more complex program running on some more complex hardware could be written in a simpler language using a simpler machine, but it would take more time to write and run.
So there is never a “need” — per se — to do the more complex thing — there is just the desire/business case to do so.
There is never a “need” to use separate name spaces, to split up the project, to use a more advanced language, to use a SQL database, all those things *could* be done using a simpler system.
At what point is the simpler system no longer the best solution? That is a judgement call, in some ways, and a business analysis decision on the other hand.
I think people should use the more complex method “when it makes sense” — not just “only if needed”.
Judgement is a large part of the sw dev game, and a big reason why experienced developers bring more to the table.
Best regards,
Jordan
Jordan, while we may disagree on some of the finer points, it’s clear that we have general agreement. Simpler is better. Don’t add complexity without justification.