#begin

Hi there again! Today we are going to continue with a short blog about the chapters in a book called A Philosophy of Software Design by John R. Ousterhout. On today’s menu we have chapter three, working code is not enough. Let’s take a look.

Working code is not enough

Professor Ousterhout has some nice things to say here. He defines two different mindset’s when it comes to programming, the tactical mind and the strategic mind.

In tactical programming, what most people do, a programmer is focused to get things working such as a feature or a bug fix. This seems totally reasonable right because we want things to work right? Well it is rather short-sitghted. If you only program tactically, you’re trying to to finish a task as quickly as possible and as a result, you do not plan for the future since it is not a priority. John says that if you just program tactically, you are tying to get things done as quickly as you can and he thinks this is why systems become complicated. As he said in the previous chapter, complexity is incremental. It accumulates in your game. And I agree with him, complexity does accumulate due to badly implemented features or dirty bug fixes like not fixing the root problem but fixing its symptoms. This is why we did a couple of blogs about clean code, and now this book; A Philosophy of Software Design.

He finishes this section with a descriptions of a person who takes the tactical mindset to the extreme. This is that persons who can write code very, very fast. Deliver something “working” for every deadline, he never misses one. However, he leaves a path of destruction in his wake and typically, other engineers must clean up all the mess behind him. He is called the tactical tornado and I bet it’s this tornado that wrangled the spaghetti monster into a giant knotted ball. A common thing however, is that the tactical tornado is often praised by management because he or she can get things done way faster than anything else, he might even get promoted faster. But what they don’t get is that this person is also actively working against them by not thinking all the code through and thus leaving a mess for the entire team to work with.

This is cool right. If you have worked in IT or the game industry for some time, you probably know someone you can describe as being the tactical tornado. But, I don’t really agree with John on this one, Although I do recognize this personality trait in some people. I also know people who get things done very quickly, deliver on time, might even cut some corners here and there but still deliver good quality software that stands the test of time. This comes with experience! And as I have talked about in the previous blogs; sometimes you might do things very tactically oriented just to make a deadline, and after it’s delivery you dive back into the code to fix things. This is most certainly not optimal, but it is realistic. This will happen sometimes. And yes it sucks because you need to touch the code multiple times and thus it’s more work and more potential to introduce bugs.

But let’s continue the chapter with the section about the other end of the spectrum; strategic programming. This is oriented towards the fact that working code isn’t enough. It’s unacceptable to introduce complexities in order to finish a task and the most important thing about a system is it’s long-term structure. Strategic programming requires an investment mindset. Instead of getting things done quickly, tactically you should think a problem through and solve it in the cleanest way possible for the long term.

And he says that some investments you make will be proactive. So it’s OK, to spend just a little bit of time designing code and maybe draw some UML diagrams for example. He also makes a very nice comment here and that is to always design a solution twice, at minimal. This allows you to find trade offs in the designs you make and choose the best one, or maybe combine them to take the best of two worlds. I think this is a very good idea. I also think that pair-programming has a place here as well. If you pair with someone on a difficult problem then you can solve it together and most likely, you will have some opposing opinions about things and thus need to discuss them. This is great for developing a system and sharing knowledge about it. You can also teach each other some tricks when pairing so don’t see this as wasted time.

Other investments might be reactive; John says, “no matter how much you invest up front, there will inevitably be mistakes in your design decisions”. And over time, these decision will become more obvious. He’s totally right! Just because you design a system very nicely doesn’t mean it doesn’t need to evolve. So a system that was clean last week, doesn’t have to be clean anymore today because the requirements drastically changed. Sometimes you cannot anticipate that. So you must be reactive and adapt the system back towards a more clean state. We talked about this in the clean code blogs as well. We talked about the concept that Uncle Bob called emergence. That a small system grows into a larger system, it emerges. During this process the design will change here and there and thus you must adapt it strategically. A nice way to do this is to follow Uncle Bobs, “boy scout rule” which says: “Leave the campground cleaner than you found it”. What he means is that you always check the code in cleaner than you checked it out, and thus the quality will only increase.

So I hope you enjoyed reading this as much as I did, It’s been quite a while ago since I last read this book so it was really nice to refresh some of the concepts that are in it. In the next blog we will take a look at chapter four.

#end

01010010 01110101 01100010 01100101 01101110.