The Emperor Has No Clothes – The Need for Object-Oriented Training

July 19, 2008 — Posted by Al Shalloway

My company has taken an interesting path through the last decade. We started out as a technical training company. We still do a lot of technical training (I wish we did a lot more as I'll be explaining in this blog). Now, we split our time between:

  • Enterprise engagements (bringing agility to the enterprise) with assessments, consulting and training
  • Assisting teams with Scrum by providing coaching and training in both Lean and Scrum methods
  • Providing technical training (sometimes coaching, but not as much)

For the first few years of our company's existence, it seemed that most teams understood the need for writing good object-oriented code. For the last several years, it seems people think they are doing this – but I have my doubts. I'm not sure where their confidence comes from. Perhaps it's that people have been using object-oriented languages now for a few years – so they figure they know what object orientation is. When people went from C to C++ or Java or VB to C# there was a definite sense that object-oriented skills were something they possibly didn't have. Now, I believe they just assume they have them.

Today, the technical skills that everyone wants seems to be test-driven development. While design patterns comes into play every now and then, it seems that most people think patterns "are so yesterday."

So why do I think they are still as necessary as ever? Because of a simple question I have asked for seven years – with little variation over this time in the answer. The question is this:

Consider when working on an existing system that is 1-2 years old (not yet considered legacy. If you have a new feature to add, what takes more time – writing the new feature or integrating it in? With the exception of teams that write incredibly complex algorithms, about 95 per cent of the people I ask this say it is the integration. This is because one needs to pay attention to which case is present and which data to use in managing the case.

Of course, object-orientation is supposed to stop just this need. Over the last several years, however, I have not seen an improvement in the answers to this question. If people truly had object-oriented skills, I think this number would be dropping precipitously. This has led me to believe our general programming skills are not improving significantly. That, and when I do look at code being written today, it still has a lot of the problems it had years ago.  Unfortunately, I don't see a lot of improvement until after they have taken our design patterns training or its equivalent.

While improving process is critical and Scrum is often a good place to start, you must pay attention to the quality of code. Just writing tests up-front (while helpful to design) does not guarantee good code quality. I'm

I am not sure what to do about this, of course. If you have any ideas, please tell me.

Alan Shalloway

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


This is a complicated question to answer....

I think there is still a lot of people who need training in OO. Actually, software construction incorporating OO ideas....

The thing that makes me uncomfortable in your thinking is that it kind of assumes OO makes the integration proportion smaller. I think this only holds true for a certain class of features. I think they actually just become really easy and you don't suffer much pain/challenge from it so it kind of slips under the radar.

I think maybe as part of the overall project effort you get about the same amount of integration work, its just you leverage what you already have a lot better, but it is still difficult to incorporate new ideas/technology etc. At the very least, it will still cause you the most memorable pain on your project.

OO suffers from leaky abstractions, your abstractions are never perfect, as you scale up and leverage more and more, those leaks become more significant and need to be dealt with. eg....

if you scale from single threaded, to multi threaded, to multi computer....
or as you go from a pure custom solution, incorporating a plugin architecture, web services, scripting support, providing APIs.

a bad software design is going to make that HUGELY hard. But even if you have a nice design, there is still a significant amount of integration work you need to do.

I think a better question is to find out how much leverage people are getting from their software, but not quite sure how you'd phrase such a question to get meaningful answers.

(Preface: Since I work for Net Objectives, people may naturally assume that I'm just towing the line, and trying to drum up more sales, but I'm sure Alan can attest to the fact that I'm far too unruly for those tags to stick. ;-)

In response to the comment, and the BLOG post, itself, I'll draw from experience visiting numerous teams, and also from teaching numerous TDD courses:

You gotta have both comprehensive automated regressive tests, and good OO design skills.

I've known good TDD developers who tested their way into a deep corner, because they didn't know the real tenets of good OO design. And I've known great software designers who were deeply familiar with the fundamentals of patterns, but who still lamented that changes to the system (architectural changes like those described in the comment) were very difficult to complete without accidental side effects. That should come as no surprise! People make mistakes. No amount of change-control, code review, or oversight is going to change that fact.

TDD includes refactoring as a design step, but you have to know what to refactor towards. If you grew up (as I did) on the notions that we subclass existing objects in order to specialize/leverage/reuse, then you need to unlearn that and get some patterns-based OO coaching, and fast! Put concretely (you'll see a pun, here): Subclassing a concrete class is almost always an example of poor cohesion, accidental coupling, and/or a dangerous breach of encapsulation. What was often taught as OO was wrong.

Design Patterns (the Gang of Four set, and beyond) are great examples of designs that are simultaneously encapsulating appropriate variations and abstractions, reducing duplication, and allowing for ready integration of new behaviors.

Design patterns are great design examples, and make code easier to change, but I still prefer to have a fully comprehensive suite of automated regression tests to make sure my change broke *nothing.* The only way I've ever seen such a wondrous suite exist is via diligent TDD. It's not that I think TDD is the silver bullet, but that I find it to be an exceptionally efficient way to self-manage the realities of my own human nature, and that of my team. (Of course, one must first accept the premise that developers are human! ;-)

TDD also takes as a given that there is no such thing as perfect design. We drop that pursuit in favor of just-in-time design.

But don't spend too many cycles lamenting the past or pounding your head against your legacy code. Start paying off the design-debt and testing-debt that exists in your code (start thinking of it as real financial debt), and start "paying cash" on any new development on the legacy product (including bug-fixes).

And whether or not you take a Net Objectives course (we hope you will...Test-Driven Development and Design Patterns Explained cover these two complementary approaches), go out and learn deeply: Strong cohesion, intentional coupling, appropriate encapsulation, no duplication, testability, readability/clarity, and Alan includes focus (but I'm still learning what he means). That may be the entire list, but these are some deep seas to fathom. It's a lifelong process that requires some humility. The real danger to your products lies in what you don't know you don't know.

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban