The Right Tool for Every Job

My grandfather was a carpenter from the old world. He, and then my father taught me some carpentry when I was a youngster. They always told me to use the "right tool for the job." About once a year, maybe more, I catch an article in IEEE Computer or the Communications of the ACM by some college professor telling me that object-oriented programming is a bad approach to software development. First I have a "huh?" moment. Then I think about using a bigger hammer, because clearly that is the best tool for every job!

Seriously, I learned a long time ago in school that the computer vendors like Digital Equipment Corporation were practically giving away their equipment to universities. Why? Because when students learn to use their computers in school, then after they leave they push for their employers to use the same systems too. When you have a favorite tool you want to use it everywhere. It's the old adage: "when your favorite tool is a hammer, every problem looks like a nail!"

So what does that have to do with languages? Well, the same principle applies: people tend to use their favorite language to solve every problem. Your favorite language may not be the best tool for the job. And more importantly: your favorite problem is not always the same problem that everyone else has!

I have been around long enough that I have touched on a lot of problem domains: business applications, operating systems, compilers, communication systems, radar, intelligence (yeah, the spy stuff), military hardware, rocket science, and many more. Back in the 1980s the U.S. congress got a bee in its bonnet about software development. They mandated that all software development done for the government should be built using the Ada programming language. The idea was that if the entire government codebase used the same language then all programmers would be plug-compatible.

Now, do you really want an programmer familiar with the country's tax-code mucking around in the code for your newest fighter jet? So it didn't work. Even worse, Ada, the language that tries to be the Swiss-army knife of the U.S. government programming world is OK but doesn't do anything really well. My appologies if you are an Ada fanatic, but I am entitled to my opinion.

The underlying reason that some folks advocate against OOP is not the language, it is their problem domain. That is a good thing! I would not want to use OOP to develop software for much of the research done in universities, it simply is not the right tool for the job. But OOP is still massively important in the business environment! Just because it does not work for you doesn't mean that you should decide that it is bad for me.

Developing software to distribute to many people for everyday tasks has its own requirements. We absolutely need this software to support the RAM paradigm: reliable, adaptable, and maintainable. Especially if the software supports some critical operation, like 911 emergency services here in the U.S. or 999 in the U.K. or 112 in many European countries. So why does OOP fit the bill?

Well unfortunately many people miss the point about OOP: it is not so much about building objects as it is about supporting good design principles. Many people talk about object-oriented design principles, but a majority of the principles are not "object-oriented" at all: they go much deeper and should simply be called good software design principles! For example, Single Responsibility is the "S" in Robert Martin's first five SOLID principles (Mhttp://blog.askjoelit.com/p/references.htmlartin). Single responsibility says that a class should be designed to support one responsibility. But even Uncle Bob himself has extended that definition to say that a function should be about one responsibility, a statement should be about one responsibility, etc. (Hansel). So single responsibility is a fundamental software principle that applies to all languages!

In fact, if we combine Bob's first five principles and add Do Not Repeat Yourself, the Liskov Substitution Principle is the only one that may not apply outside of OOP:

1. Single Responsibility Principle
2. Open for Extension, Closed for Modification
3. the Liskov Substitution Principle
4. Interface Segregation
5. Dependency Inversion
6. Do Not Repeat Yourself (Hunt)

But if I consider the LSP at the level of components (libraries) instead of classes, even that really applies to my non-OOP programs. I will leave it as an exercise for you to do some more investigation on your own if you are not familiar with the details of these principles. Coincidentally you can start here with my blog post Don't Get Wet, Stay Dry on Solid Ground.

So object-oriented programming is first and fundamentally about organization. When a system is organized it functions more reliably. When a system is organized it is simple to adapt it to changing requirements. And when a system is organized it is much easier to locate, isolate, and fix a problem.

In the 1970s and 1980s my associates learned that if we grouped related components of a system together we had a better platform for RAM. We were using the language C, so we put the data and functions that worked together into libraries to keep the related parts near each other. Is that much different from how we use a class in a modern OOP language? I cannot repeat it enough: these principles apply to all languages!

So all of this is about choosing the right tool for every job, not about about a single tool that is right for every job! Truthfully an OOP language is not the best tool for doing scientific programming, and that is fine. Been there, done that, and have a t-shirt, but the fundamental principles still apply. First and foremost we should teach the principles. But OOP in the business world helps enforce those principles across really large applications to build reliable software, so it is still the best tool we have for that job.

References

See the references page.