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 believe that aversion is antithetical to the spirit of the tech world and is a major hindrance in any innovation.
Chris Boss authored the article, “Six lessons I learned about writing software” for BetaNews.com that illustrates that fear with stunning clarity. After reading the article I am not even sure what it's about. The six lessons he shares with readers can be boiled down to three overarching themes:
- Chris Boss is awesome and makes awesome software and has never not been awesome
- Higher education is worthless
- Object Oriented Programming ("OOP") is as close to worthless as it gets without actually being worthless
Before I address those points I should say that I'm actually in general agreement 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 it cannot be improved to any noticeable degree, performance 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 indeed the first and last line of defense against bugs. 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 Mr. Boss does not like OOP.
The fact is, though, that Object Oriented Programming is a tool in a programmer's tool box similar to a wrench in his father the plumber's toolbox (or whatever tools a plumbing professional might carry since I admittedly don't know much about plumbing and there could be hammers in there for all I know).
There are times to not utilize OOP so that you can satisfy other requirements such as performance or rapid proof of concept development. In reality though, 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 likely deem misconceptions.
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 like how not everybody can learn to fluently speak a foreign language).
For people who find it more natural though, it's simpler to be able to locate a point in execution based on what they know was happening between the objects.
The fact of the matter is that by using objects and abstracting functionality properly, you can easily include entire classes of useful functionality in any number of projects without any modification to behavior. In juxtaposition to procedural programming where you might find that a function may 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.
This is similar to the misconception about code readability mentioned above in that a poorly written procedural program will be just as complex as a poorly written OOP program. However, the difference lies in the effects of well written software. Well written OOP software has more code execution jumps than well written procedural software, but such is a beneficial trade off for the added direction of knowing that objects are interacting.
If you're hunting down a bug in the portion of the software that handles a customer paying a bill, in OOP you know that you should check the customer model or the transaction model. But with procedural programming the bug could be in the main flow of execution or it could be shuffled into a subroutine that you're not even sure is running until you manually trace the code step by step.
Just a Case of "Change is a Bad Thing"?
I understand 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. (interestingly, like him I also cut my teeth on BASIC and teaching myself 8086 ASM). However, while there is still a time and place for procedural programming, code is constantly evolving to add functionality that we didn't previously even think possible.
By teaching compilers to think in terms of objects, something we do naturally every day, we enable brilliant programmers to conceptualize complex systems such as neural networks and machine learning. At the end of the day, “Six lessons I learned about writing software” left me with a gnawing question. How can somebody so against learning how to properly use these new tools actually form a solid opinion about them?
The author of this article was Web Development Professional Anthony Corbelli with minor editing by EnderTech's Digital Media Coordinator Casey.
Top Photo Source: Michael Mandiberg (https://www.flickr.com/photos/theredproject/) under http://creativecommons.org/licenses/by-sa/4.0/Back