3 Things I Learned from Chris Boss

Most of the time I consider myself to be an old man: my back hurts in the morning, I'm almost always grumpy, I really do not appreciate kids on my lawn and popular music just makes me confused and angry. One thing I apparently lack, however, is a near crippling aversion to new technology and changes in the tech world. I feel that aversion is antithetical to the spirit of the tech world and is a major hindrance in any innovation.

Chris Boss posted an article titled “Six lessons I learned about writing software” over on BetaNews.com, which illustrated this fear with stunning clarity. After reading the article I am not even sure what it's about, the six lessons he shares with his readers are all shoehorned into three overarching themes:

• Chris Boss is awesome and makes awesome software and has never not been awesome
• Higher education is worthless
• Object Oriented Programming is as close to worthless as it gets without actually being worthless

Before I address those points I would like to say that in general I actually agree with his six lessons:

1) Development time is critical, especially for custom software – Absolutely. I don't think anyone can really disagree with this idea.

2) Performance is always important – Once again, I don't think anyone can disagree with this. Even when performance cannot be improved to any noticeable degree it is an important part of any piece of software.

3) Productivity depends upon the ability to reuse code, and building quality library code is always important – Any programmer can tell you that without having to spend a paragraph defending their use, or lack thereof, of OOP.

4) The less code you have to type the faster it gets done – I think this is more of a side note to the first point, but either way this is an obvious corollary to the fact that the less you have to do the less time it will take you.

5) The programmer is the debugger – Programmers are the first and last line of defense against bugs, true, but whatever Mr. Boss might think of the newfangled technology unit tests, debuggers and automated testers are an invaluable time saving resource for even the most simple projects.

6) Keep it simple – The KISS principle applies in almost every area of life and his paragraph here just seems like another chance to talk about how much he does not like OOP.

The fact is, though, that Object Oriented Programming is a tool in the belt of a programmer just as his fathers wrench (or other tools a plumber might carry, I don't know much about plumbing admittedly, hammers maybe?). There are times to not utilize it so you can satisfy other requirements, like performance or rapid proof of concept development, but the fact is that almost every problem can be solved efficiently via modeling the issues as real world objects. In fact, almost all of the reasons Mr. Boss listed to not use OOP are based on what most Object Oriented programmers would probably call misconceptions.

Code Readability:
Not everyone has the same skills or the same way of looking at the world and that is true for programmers as well; not every programmer will be able to shift modes and think of how to model problems and solutions as objects and object interactions, much the same way as not everyone can learn to speak a foreign language fluently.
For people who find it more natural, though, it's much more simple to be able to locate a point in execution based on what they know was happening between the objects.

Code Reusability:
The fact of the matter is that by using objects and abstracting functionality properly I can easily included entire classes of useful functionality in any number of projects without any modification to behavior, whereas with procedural programming I might find that a function might be useful in many projects but either it or the surrounding logic would have to be changed to fit the new situation. Objects can be extended and only specific behavior modified to meet new needs while keeping the rest of the functionality intact.

Simplicity:
This is similar to the readability argument in that a poorly written procedural program will be just as complex as a poorly written OOP program. The difference, though, is in the well written software. Well written OOP software does have more code execution jumps than well written procedural software but its traded off by the added direction of knowing that objects are interacting. If I'm hunting down a bug in the portion of my software that handles a customer paying a bill I know I should check my customer model or my transaction model, whereas with procedural programming it could be in the main flow of execution or it could be shuffled into a subroutine I'm not even sure is running until I manually trace the code step by step.

I know that Mr. Boss is a successful and skilled programmer and that this is a topic of much contention between old school programmers and the younger generation of programmers (interestingly, Mr. Boss, I also cut my teeth on BASIC and teaching myself 8086 ASM) but the fact remains that while there is still a time and place for procedural programming code is evolving to add functionality we would not have even thought was possible before.

By teaching our compilers to think in terms of objects, something we do naturally every day, we enable brilliant programmers to conceptualize complex systems like neural networks and machine learning. I hate to say it, Mr. Boss, but if you are so against learning how to use these new tools properly how can you have a solid opinion of them?