Code Simplicity

Design From The Start

I don’t know if this has become clear to everybody yet, but you really need to design from the start. You need to be working on simplicity and the other Laws of Software Design from the very beginning of your project.

My policy on projects that I control is that we never add a feature unless the design can support it simply. This drives some people crazy, notably people who have no concept of the future. They start to foam at the mouth and say things like, “We can’t wait! This feature is so important!” or “Just put it in now and we’ll just clean it up later!” They don’t realize that this is their normal attitude. They’re going to say the same thing about the next feature. If you give in to them, then all of your code will be poorly designed and much too complex. It’ll be Frankenstein’s monster, jammed together out of broken parts. And just like the friendly green giant, it’ll be big, ugly, unstable, and harmful to your health.

Adding a tiny little piece and refactoring it afterward is fine. Landing a huge feature that the architecture can’t support and then trying to clean it up afterward is a terrible task. Size matters.

The worst situation, however, is when you let people keep adding features with no design for months or years, and then one day you wake up and realize that something is not right. Now you have to fix your whole codebase. This is a terrible task, because just like adding a new feature, it can’t be done all at once, unless you want to re-write. If you want to start doing things the right way, you have to start doing things the right way. And that means that you have to fix the design piece by piece, in simple steps. That usually requires months or years of effort–totally wasted effort, because you should have just designed from the start. You should have thought about the future.

If your project lacks a strict design, and it continues to grow, then you will eventually end up over your head in complexity. I understand that this is hard for some people to imagine. Some folks can’t imagine that there is a future beyond lunch. Other folks just haven’t had enough experience to understand how complex things can get. And I understand that there can be a corporate culture that says, “Oh, we just hack in new features, and we should do things the right way, but we can’t because blah blah blah.” But one day your project will fail. And no matter how many reasons you can give for that failure, it won’t change the fact that your project failed.

Often, when you’ve done your design right, there’s not a whole lot of credit that comes your way. Catastrophic failures in design are big and noticeable, small increments of work toward a good design are invisible to people who aren’t intimately connected with the code. So this can make it difficult–handling a big failure gets you a lot of thanks, preventing one in the first place, well, nobody noticed.

So I’ll congratulate you myself. Did you design from the start? That was awesome. You absolutely did the right thing. Have you started designing now? Well, you should have started earlier, but congratulations on starting to move in the right direction. Your users and fellow developers will see the benefits–working software, on-time releases, and a clear, understandable codebase. Will they know how much work it took to get it that way? Maybe not. But that’s OK. Sometimes doing things the right way is really its own reward.


8 Responses to Design From The Start

  1. Max, interesting post. No matter how much design you do, users will always sneak in requests and features which ends up as patches and workarounds. Eventually you start to see more and more regressions and a major refactoring or perhaps even redesign is called for. This is the single most difficult (but also fascinating) aspect of software design.

    I am going to guess I am not the only one who tried adding to an application with a bad feeling that this is just the wrong way. However, the right way is often just not practically or economically feasible for the time being so you go along with it. So I am afraid I for one am not worthy of your congratulations, having had to do big-bang rewrites as I got smarter, several times in my career. Also it is not uncommon to be characterized by colleagues as a gold plating perfectionist and, like it or not, the best feature of a peace of software is being able to ship it.

    • Max Kanat-Alexander says:

      Hey Casper! I have seen the same thing happen. At least caring about design, and noticing that patches and workarounds are moving away from it, that’s commendable.

      Now, I too have seen situations where people said that doing things the right way wasn’t practically or economically feasible. But somehow a re-write (more effort later) is?

      In commercial environments (and a little bit in open-source environments), there’s also a big push to “stay competitive.” That is, to make sure that you have the same or better features than your competitors. Sadly, that’s all too often just measured by the size of the feature list, and not by the quality of each individual feature in the product. Shipping a little later than your competitor with a better product isn’t actually harmful to business. Shipping years later (witness IE7 and Vista) is, but it’s not usually gold-plating that causes years of lateness. It’s re-writing that does.

      As far as being called a gold-plating perfectionist, people who say that are probably the types who can’t see beyond lunch. They’re also often the types who don’t want to stand away from the computer for even a few minutes to think about a design. That’s one reason why design shouldn’t be a democracy. Design should really be a dictatorship, and anybody who doesn’t understand it (and would rather do things the wrong way, often out of ignorance) should be forced to implement it. And actually, usually what happens is when you force them, after about two years they start to understand why you did it and what’s important about it, at least a tiny bit.

      There have been times with Bugzilla that I’ve compromised, I will say that. But it was because all our contributors are volunteers, and I had to make the decision: “If I tell them to fix this, they won’t, and then we won’t have the feature at all. If I let it in as-is, we’ll have the feature but it’ll suck.” But honestly, the more I do that, the less I think it was a good idea. I’ve had so much trouble caused by allowing those things–particularly bugs and incomplete features that users complain about–that I’m really disinclined to ever do it again.


  2. I just finished reading “Practical API design – Confessions of a Java Framework Architect” by Jaroslav Tulach (original author of NetBeans). And in it he describes similar experiences to yours. However, he focuses a lot (too much) on backwards compatibility and comes with statements such as “simplicity and elegance is not the goal at all”. That made me a little depressed so, intentional or not, thanks for pulling a little in the other direction with this blog! 😉

  3. fulano says:

    “Nobody should start to undertake a large project. You 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 the sheer size of the work you envision. So start small, and think about the details. Don’t think about some big picture and fancy design. If it doesn’t solve some fairly immediate need, it’s almost certainly over-designed. And don’t expect people to jump in and help you. That’s not how these things work. You need to get something half-way _useful_ first, and then others will say “hey, that _almost_ works for me”, and they’ll get involved in the project.” – Torvalds

    • Max Kanat-Alexander says:

      He’s right, but he’s wrong about why he’s right and he’s wrong in some of the things he says. You should expect the project to get large. You should not overengineer. And you should not design too far into the future (which is the point he’s actually making).

      Also note that he’s making a point about open-source software–about what makes people want to contribute.


Leave a Reply

Your email address will not be published. Required fields are marked *