Design Patterns for the Win

It was the middle of 2000’s. Our only working developer had just quit. I, as the only software person left, had to take over everything he used to be responsible for. I was the software architect. A programming one, tasked with database design, etc., as well. The other developer wasn’t really doing development. I am not sure what he did, but hey, the whole executive suite was his friend, so he could do whatever he wanted to. Once in a while, even impeding what I was doing. Anyhow, that is worth a different article to talk about, life inside a fresh start up.

So, a bug was found in the software by the tester. That was good. So, I dove in to find out what the bug was caused by. I traced the execution path on the stack trace, trying to reconstruct what was done along the way.

I checked the first method called. No functional code. Just a call to another method. Fine, this is nothing special. Many methods don’t really do anything. I went on to check the next level of call. Same thing. No functional code, just a call to another method in another object. Bewildered, I was starting to wonder how deep I would have to go to see the first functional statement, not a naked method call or object creation.

Eventually, I found the first functional statement. It was 17 levels down. Amazing. The developer who left was a design pattern fanatic. I am sure it was fun when he wrote the code.

Well, I fixed the problem. I guess I should have started from the top of the stack? But I wanted to know what was going on to the point when the exception was thrown.

I never bothered to decipher the design patterns used for those 17 levels. It really did not matter for me. It is one thing to design something and another thing to maintain that same thing. An elegant design is not always something easy to maintain. This is just like efficient code is not always something that is easy to maintain.

As the person responsible for production. Ease of maintenance counts for more for me.

I don’t deny the usefulness of design patterns. I follow certain patterns all the time myself, some with names, some without. When I have the time, I guess I will talk about why design patterns in real life can be easily nested, but it seems to be quite difficult to do in programming. You will know what I mean when you encounter problems integrating two frameworks together.

I learned the other day that Christopher Alexander had died. His book “The Timeless Way of Building” is one of the top programming books that every programmer should read, even though it is a book on building architecture philosophy.

(Yes, I understand the value of code review, etc. But with two working developers, and mountain high of features to write for a fresh start up, all those wonderful development methodology stuff was luxury items. Unfortunately. We did have very strict source control and build discipline. I made sure of that.)