Avoiding Overdesign

I’m reading Dreaming In Code and I came across this really cool quote from Linus Torvalds:

Nobody should start to undertake a large project.  You should start with a small trivial project, and you should never expect it to get large.  If you do, you’ll just overdesign and generally think it is more important than it likely is at that stage.  Or, worse, you might be scared away by details.  Don’t think about some big picture fancy design.  If it doesn’t solve some fairly immediate need, it’s almost certainly overdesigned.

He’s totally correct.  I’ve seen many projects fail (or at least go way past their ship dates) because they were worried about solving the next problem and not this one.  Almost every time we plan for our perceived future needs, we plan wrong.  By the time we get to the future, the needs have changed.  Instead, it is better to design a flexible product that can be changed in many ways, rather than planning for the next big specific change.

Writing flexible code is possible by following basic OO design principles like writing to interfaces, keeping coupling to a minimum, keeping classes coherent, etc.  If you do that, you’ll be able to easily refactor your way to success.

Comments (3)

  1. Nick Malik says:

    Where does architecture fit in this scheme?  Do you architect for the system you will build, but build only for the current iteration?  (assuming 12 iterations of one month each, in the budget).

  2. SteveRowe says:

    I think you want to design ahead of the current sprint.  This might be called architecture.  You should have some concept of how you’re going to build everything over your 12-month release cycle.  Of course, be willing to revisit those decisions as you progress.  I don’t think Linus is saying not to think ahead of the current feature, but rather not to think ahead of the current release.  Building software totally organically tends to lead toward chaos.  You need to think ahead, just don’t think about features for the next release.

  3. Toward the end of Dreaming in Code, there is this quote from Mitch Kapor: We've constantly over-invested

Skip to main content