Remember the invaluable software design patterns? It’s debt time

I want you to re-visit a time of my, and perhaps yours, when i was obsessed of Gang of Four, GoF. The super (?) popular collection of design patterns for OOP programmers to follow, when develop solutions and applications.

  • Developer role has evolved
  • Separation of programmers and strategists
  • Using patterns to communicate over principals
  • Identify value by investigate dependencies

GoF was a collection of programming design patterns that could be used to solve many common problems in object oriented software development. So much value they bring to the OOP style development.

In addition to the man hours I spent as a developer to read and learn the patterns, I also spent countless of hours to develop and implement patterns during the years. Like a bible, both in professional and in spare time projects. I was never challenge the importance of the patterns seriously, just followed it slavishly.

A sign not being enough senior. Or perhaps, as I would say today, not being questioned enough. As the programmer, knowing my patterns, I was not questioned what I said or did. Instead. my agitators were at StackExchange. I challenged my implementations and worked close to StackOverflow. Of course I was boiled with razor blades. But I got skilled, learned my lessons.

But the patterns were still bible, even on StackOverflow.

Within time I learned to look back to what I really did and also how I did it. Increased the holistic view and a whole thinking perspective. What did those patterns really mean? And I am still not sure why this view happened to me. Has the role of programmer evolved lately, where it’s more expected by the role to demonstrate the value of the code to strategists? and business? Sometimes the roles are (and should, depending on the organization and assignment) be mixed. Mixed as in strategist and developer is the same resource (for instance in a very high skilled expert resource. While this separate topic might be interesting, we re-connect focus to the patterns.

OOP Design patterns back at the time

Patterns was back at the times quite easy to demonstrate, because problem was solved with one or few tools and frameworks. For instance JDK/JRE or .Net C#. Collections as GoF cover most scenarios, so not follow one pattern was strange. But the missing important question to the patterns was: how the pattern was implemented. Not much questionaries’ or analysis methods to confirm that the development was valuable. Back at the times, I didn’t need to provide proof that the implementation will be measured in value. For sure, I would be questioned in terms of SOLID or even OOP, and boiled or blamed for every mistake. But I would for certain not be questioned how I can ensure business not losing money when CTO requested a new integration.

That was the good thing for me, bad thing for business. You know already why that was bad for everyone? Including the customers? Because it would for sure create a Business (or sales) vs IT (technology) culture.

For a strategist, the segregation and understanding of dependency between the value that objects hold or enable, is way more important. Not to mention the value that might be loss in one part of the system, if another part will be in trouble. I will demonstrate below. Let say I back at the time (programmer following design patterns) wanted to describe for CTO a pattern I built and how good it is, so I created models, because it obviously hard to traverse through code, classes, namespaces and technologies.

With this model, it looks all clean and good. But the 10-point question is: how does it stand if it’s described in value to the business? Sometime later, the CTO or business may ask to move a new logic in addition to this nicely described adapter pattern. Or may ask what amount of money we lose if XmlAdapter inexpertly stop work.

Impact in terms of (any measurable) value

By look into the model, it’s easy to trace the impact by disconnect a component. The XmlAdapter seem to be just to cut off. Assuming that the model is true, that this assumption will probably cause big problem. One might ask what means with ”Value”. The context is probably changeable over trends and times. The value might be monetary, number of deployments required, or components impacted.

In current generation of development of technology, it’s a losing concept to just throw a design pattern over the table and then implement it. A change need traceability, explanation from relevant views and be intentional. Documenting, structuring, adding traceability and communicate to stakeholders, confirming and have signoff might take more time then the actual development. But that’s the point. The result will be systems that are understood by audience, stable (or known reasons to not be stable) operational conditions and development, change and release that have a process.

How can a CTO plan for emerging trends or match the business rapidly changes, if the CTO don’t know the technology significance, between planning and deployment? Shouldn’t CTO know where the changes require re-factoring of half the codebase or just a minor?

How do we ask correct questions for this? and who care about the value? Simple answer: Make sure that there is a strategist role in the project, company or department. A quite simple way to challenge the valuation in the earlier sample, starting in a company from zero, could be like this from CTO:

“We want to introduce a manufacturer that produce nano sensors. It will for sure require a new adapter, but should behave exactly the same against TheDataHub. The difference I think of, is to make sure that hardware identification have space for 256 characters. See sample model”

We can also see the level of understanding from the CTO, which is really important. And that the CTO think he or she have an idea about what need to be done. According to the pattern we followed in an earlier model, a dummy-adoptee should be able to implement with a kick. Right? The tricky part should be to attach the functionality of connecting nano sensors, preferrably done in a separate space attached to the adapter.

“Cool, just relax – i code it and return to you when it’s done!”

The true developer (looking to myself back in time), would stick with this comment and start develop. I tell my CTO that he can relax while I realize the model with the new adoptee for nano sensors. So now the time for truth has come. Will it be so easy? In flexibility to technology changes to the business, do you think the CTO does float in the land of unawareness? On his hands there is most likely some external expectations from a manufacturer, that also might have development to do, to meet the CTO’s expectations.

Let us jump back to the view of developer. We must today be able to questionate models and code implementation in more ways. It’s simply not enough to just be provided a simple view. Once we are provided several (relevant for the situation) views, the strategist can ensure that the change or new capability get the correct attention and or resources.

Assume that the following model was more close to the actual implementation of the famous pattern? Which is a completely possible truth scenario:

An experienced developer can quickly see that the CTO or a architect, have some problem if a new emerging technology would be implemented here.

The strategist would have need to ask for some views that are not completely code related. For instance;

  • How would authentications touch the components.
  • What infrastructure objects exists? and their relations (for instance Database on a separate server?)
  • How do backoffice/admin connect to the components?
  • How many kind of readable objects
  • Each objects frequency is it, currently?
  • How does the frequency and degree of numbers of objects relate to and between the adapters?

… and so on. The pattern here is questions that may have significance on the design.

It does not say “we don’t trust developers”, it’s more like say “there is a nurse between the client and the doctor”

Value in adding an strategist

In this fictive example, it’s clear that we have a responsibility to support the way the application is meant to provide service to the users. Not clear is that we should leave all that responsibility in hands of a developer, with nothing more between CTO and developer. It does not say “we don’t trust developers”, it’s more like say “there is a nurse between the client and the doctor”. With very good reason. The view and concern is different. Also the tasks. Is simply not fair to place all responsibility in hands of the developer (or require the CTO to have very developer focused skills).

Let’s take some of those example questions to the model above, not much is answered. Right? We just see that the implementation really is an adapter pattern. Points earned there. But it’s more a adapter style, rather than a pattern. This pattern implementation will for sure cost a lot to separate into modules.

We can quickly see some required improvements, but that’s not the point. We already see that the lack of clear abstraction between datalayer and adapters require a very ill smell to stability and deployment, just to increase the length of the string column object name identifier. Also that the authentication is really in shadows.

Having a strategist, for instance an architect, architect alike CTO or analyst that know to ask the right questions to provide a bridge between strategic need and technical requirement, can really save or increase the room for improvements you have in the roadmap.

The days where the heavy / senior developer can do everything must be passed to history. That’s not to, as already emphasized, question the skills or understanding for the role, more because the concerns are different. The skilled heavy developer resources can deliver both strategy and code, but be aware that they provide value within different principals — and make a way to be clear about it. If not, this resource (you?) might consider if it’s really a developer, or really a strategist and continue with one of them, as the homezone.


Jonas Nordin | Professional Profile | LinkedIn

View Jonas Nordin’s professional profile on LinkedIn. LinkedIn is the world’s largest business network, helping professionals like Jonas Nordin discover inside connections to recommended job candidates, industry experts, and business partners.


Read a recent page that list about the GoF patterns hers:

The 23 Gang of Four Design Patterns .. Revisited

Technical musings on Win8, mobile (iOS / android / WP7) and WCF The Gang of Four (GoF)(from Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Professional Computing Series, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides). These 23 GoF patterns are generally considered the foundation for all other patterns.