#begin

On today’s menu we got chapter 11 from a book called A Philosophy of Software Design. We’ll be looking into a chapter that covers a really simple yet very effective practice which is design your solution twice (or more). Let’s check out what Prof. Ousterhout teaches us next.

Chapter 11: Design it twice

Well I think the title of the chapter already spoils what it’s about. John says that designing software is hard and thus it is unlikely that you will have the best design at your very first try or iteration. He says you will end up with a much better design if you design it twice or even more.

Try to pick approaches that are radically different from each other since you will learn more that way. He even says that when you already have a perfectly reasonable approach, try to take another one no matter how bad it might seem in the first place. It will be really helpful to consider both design’s strong and weak points. Thus you can compare them and maybe end up with something in between.

And I personally think this is a great idea! How many times have you designed some system, implemented it immediately and then found out it wasn’t really the best approach. It certainly happened to me before. I’ve even been in situations where everything was just thrown away since the first approach was not correct. But that had to do with incomplete requirements as well. But I still think that, if I would have designed it multiple times I may have gotten a better solution the first time I implemented it. I wont bore you with the details of the feature so let’s continue with the book.

Prof. Ousterhout says that once you have compared alternatives you are in a better position to identify the best design. He also says that maybe, none of those alternatives might be the best choice and you find out when you combine the two, you will end up with something that is really good. This is exactly what I described just a second ago. He’s totally right.

He then continues saying that this design-it-twice approach can be applied in all levels in a system. So for some class or module, you might first design it’s interface. When you have made a choice for the interface, you design the implementation. John says that when you design an implementation, most of the times the main goals to focus on are simplicity and performance.

But it’s also very useful to explore multiple designs at higher levels of abstraction like when you need to decompose your system into components. And it’s always easier to compare approaches when you have a few alternatives. So you might want to design something more than twice.

Then he says something I think is a bit over-reaching and I’ll quote Prof Ousterhout directly: “Designing it twice does not need to take a lot of extra time. For a smaller module such as a class, you may not need more than an hour or two to consider alternatives. This is a small amount of time compared to the days or weeks you will spend implementing the class.”

I mean, taking just an hour or two for designing just a single class, and then spending days or weeks just implementing this one class? Wow, isn’t that a bit much? I have never taken the such a long time to let alone design a class’s interface, and taken weeks to implement a single class. I think we have found a really large contrast to clean code here. In one of his lecture’s John also says that he doesn’t really care how large a class is, as long as it’s interface it simple and clear. And on the other hand, Uncle bob wants you to write really small classes that adhere to the Single Responsibility principle. With such classes, you wont spend such a long time on design and implementation.

I personally agree more with Uncle bob here. I would rather design a system from smaller classes than just a couple of really large ones. You can make these classes internal or protected so your consumers won’t be able to see them. So you hide all these small classes behind a simple interface which is implemented on some public class. But I think John will agree with this. And I also think, this is what he meant by that quote. I can’t imagine he wants you to create like 5000 line long classes. I suspect he wants you to break them up as well, and hide their implementation. This would mean, you could indeed spend a couple of hours on designing some class, I would call it a component since it will hide all these internal classes inside of it’s namespace. And then spend a week, or weeks implementing it.

But then again, he mentions that for larger modules you might spend even more time on designing it. Here, the value of design-it-twice will really show it’s value. Since the impact of the size of modules is higher, you really need to think things through properly before you start implementing. And he then says something pretty funny and I’ll simply quote: “I have noticed that the design-it-twice principle is sometimes hard for really smart people to embrace. When they are growing up, smart people discover that their first quick idea about any problem is sufficient for a good grade; there is no need to consider a second or third possibility. This makes it easy to develop bad
work habits. However, as these people get older, they get promoted into environments with harder and harder problems. Eventually, everyone reaches a point where your first ideas are no longer good enough; if you want to get really great results, you have to consider a second possibility, or perhaps a third, no matter how smart you are.”

Hahaha, I mean isn’t that funny. He’s so right. When designing a large system, your first idea is probably not the best one, so you shouldn’t go with your first try. The design-it-twice approach will not just improve the quality of your design, but also your skills to design a software system. The process of creating and comparing multiple designs will teach you about the factors that make designs better or worse. And over time, this will make it easier for you to rule out bad designs and hone in on really great ones.

John is so right about all this. Designing things twice or more is such a great concept everyone should apply more. If everyone would do this, I bet our games would become much simpler. I also think that if you design things twice and also ask your colleagues for their opinions about those designs you will grow, learn a great deal as a team. This way you can keep everyone educated and familiar with systems in your game.

But alright. That’s all about chapter 11, Design it twice. What do you think about this practice? Do you like it? Have you applied it yourself before? And, what do you think about spending hours upon hours of design and implementation for just a single class? Let me know in the comments.

#end

01010010 01110101 01100010 01100101 01101110.