Reality-Loop

Abstraction, Encapsulation and social Darwinism (The Antipattern of Framework- vs. Business-Programmers)

September 29, 2009 | 4 Minute Read
This post was originally posted on my old blog.

Responsibility trap number one: Building a platform to make other (lesser) programmers more productive.

- Eric Evans at SET 2008


Hiding things from developers often requires more effort in the long run than simply trying to educate your developers as to how they should properly do their job.

- Educate Developers Instead Of Protecting Them by Davy Brion


Making development "safe" for lesser skilled developers by taking choices away from developers [...] does far more to hamper the efforts of your best developers than it does to make weaker developers more productive. I'll say that there is a silver bullet(s), it's: Skill. Knowledge. Experience. Passion. Discipline.

- Jeremy Miller


Again and again I come across projects, teams and companies that misuse the concepts of Abstraction and Encapsulation to establish a two class society among the developers.

mind_the_gap-logo.jpg In those setups you usually find on one side a framework-team that is responsible for a supposedly productivity-boosting, supposedly well crafted framework / platform / infrastructure. On the other side you find an army of business programmers that have to use the provided framework / platform / infrastructure to actually realize business value.

Usually the framework-team members think of themselves as the gurus, the elite, the "real" programmers, while the business programmers are considered as "lesser" foot soldiers.
These attitudes are mostly shared and therefore promoted by management. Indeed the framework-programmers often have the better education and/or more technical expertise.
If the situation is really bad then the framework team does not like to mingle with the business-programmers and the worst thing is, when they are not even co-located.

Teamwork.gif I heavily oppose this setup. It is an antipattern, that prevents team enabling. Agile, self-enabling, highly-motivated teams will never evolve in such a structured and divided team setup. This is not an environment where individuals are allowed to grow, this is an environment where employees are assigned! In such an environment, people just start to not care any more: framework-developers do not really care about business value, business-developers dont't feel like being able to make a difference...

As I don't believe in the factory analogy, I don't believe there is a situation where lesser developers have to be shielded/protected by a technical framework. The time to create a patronizing framework, would be better invested in teaching and exchanging knowledge.
In my experience, if a developer is not productive, then this is usually a management failure. Simple measures like assigning another task, changing the setup, pair programming, coaching, reviews etc. would usually improve the situation. I have seen projects where this has been achieved successfully, but in the above setup, this is usually not going to happen.
And in the rare case that you are really dealing with a net negative producing programmer (NNPP), no technological solution will save you... Abstraction and Encapsulation are pillars of object-oriented design. They are intellectual constructs to tackle complexity. They are technical tools and not a mechanism to legitimate team structure.

Using engineering techniques from object-oriented design to enforce team structure and separation feels just as wrong as applying Darwin's evolution theory to human societies.

medicine20logo.jpg Possible remedies and counter measures for the situation are:
  • Eat your own dogfood: Framework-developers have to use their own framework. They have to be involved in business-programming.
  • Empower the business developers: Establish an environment where it is absolutely clear, that the business developers are the ones that are providing value. The framework-team has the sole purpose to enable the business-developers.
  • Productize the framework: Nobody is forced to use the framework. The framework-programers have to actively sell their work, the business developers can freely decide if they want to use it. (According to a disscussion with Mark Striebeck, this philosophy is very successful at Google)
  • Collective ownership of the code, including the framework.


  • follow me on twitter, I need some friends :-)