tacoma narrows The design is never right the first time. Nor is it usually right the second time. This is one of those key lessons you learn over time building real software, and is the source of one of the chief complaints leveled at the Waterfall methodology for building software, which puts heavy emphasis on getting the design right up front.

We have to define “right” in this case. If by “right” you mean perfect, then I don’t think the design is ever right, as I’ve argued in the past that there is no perfect design.

Recently, this lesson was driven home as my feature team (ASP.NET MVC) were hashing out some tricky design issues. Many times, we find ourselves in a tight spot in which we have two different audiences demanding a different approach to a design problem. The tough part is that the solutions we come up with inevitable satisfy one camp at the expense of the other.

Let me be clear, it’s not our goal and intention to try and satisfy everyone as that is a sure means to satisfying nobody. As Bill Cosby once said…

I don’t know the key to success, but the key to failure is to trying to please everybody.

At the same time, I also think it’s a copout to simply give up immediately when a thorny design problem comes up with two disagreeing camps. It’s worth a good faith effort to try and gather ideas you haven’t considered before and see if you can’t just solve the problem in a manner that both camps are happy with. Or at least in a manner that one camp is happy, and the other is merely less happy.

An illustration of this point happened recently at work. After many iterations, I sent out our design meeting notes internally with our solution to a particular issue. ScottGu noticed the write-up and had some questions about the design (questions like WTF?) and called me and Eilon (the lead dev) into his office for a “short” meeting to discuss these recent design changes.

I made sure to call my wife before the meeting to let her know I would be late for dinner. Once we get a talking about MVC, I know it won’t be short. We spent two hours hashing out the design, going over options, shooting them down, trying out other ideas, and so on.

At some point, Scott proposed something my team had rejected earlier due to a major flaw. However this time, as he was proposing the idea, it suddenly occurred to me that there were two different ways to implement this idea. The one we thought of wouldn’t work, but a slight adjustment to the idea, the very one Scott was proposing, would make it workable.

Eilon and I left the meeting happy with the improved design, but now concerned with the fact that we had already implemented another solution, had a bunch of unit tests and automated web functional tests. Not to mention having to deal with explaining it to the team and getting buy in so close to our release deadline.

So we did the cowboy thing (which I generally don’t recommend) and decided instead of telling the rest of the team about it, we’d follow the old maxim: “Show, don’t tell”. So that night, we went and coded the whole implementation, updated all the unit and web tests, and had something to demo in the morning rather than talk about. Since we had updated all the tests, QA was much more amenable to signing off on making this change so close to the deadline.

In retrospect, the part that causes me pain in the missed opportunities sense was just how tantalizingly close we were to having implemented this very idea from the beginning. All that time spent prototyping, app building, etc… we could have saved by getting it right the first time.

But that’s the way design goes. Sometimes, you are so close to a great solution that if the wind blows a certain way, you’ll hit upon it, but if it blows another way, you dismiss your line of thought and move onto other plans. Try as you might, it is very difficult to get the design just right the very first time all of the time.

Luckily for us, our team had the agility to respond to a better design. Our suite of unit and integration tests gave us confidence that the changes we were making were not breaking the framework in other areas. To me, this is a real testament to the benefits of applying lean and agile principles in software development, as well as the benefits of having good unit test coverage.