Lesson 5: If you take thinking out of development, you take thinking out of the developer

Background

I joined the healthcare division of one of the three main credit bureaus as an application architect. My responsibility was to educate, mentor, and guide six development teams that were responsible for roughly a dozen product platforms all in the revenue cycle management space for healthcare providers and hospitals. When I joined, the flagship product was a legacy, monolithic system that was incredibly powerful, customizable, and complex.

Outcomes

Due to the size of the codebase for this flagship product, combined with the complexity of the system design, enhancing and fixing this system was a nightmare for the development teams responsible for it. The software architect who designed and implemented much of the core functionality had a singular vision in mind: allow any junior developer to be able to quickly add pieces of functionality to the system with just a few objects. The architect had created an ingeniously clever way to allow developers to create a new database table, create a new web page, and very quickly wire everything up together with just a few lines of code. When the functionality to be added fit into the model supported by his architectural design, the system’s functionality grew easily and quickly.

The primary problem was that the business was evolving, and new functionality didn’t fit the model of the old architecture. It was a classic “square peg, round hole” dilemma. In addition, because the inner workings of the system were so complex and known only by a couple of people, the development teams didn’t have the knowledge nor the confidence to change or enhance the system. It was brittle. (That’s bad.)

Mistakes

The primary mistake in this story wasn’t made by me, but I had previously made this particular mistake all too many times. Essentially, the previous architect fell for the IDTFY blunder: I’ll Do the Thinking For You. He was convinced that he was smarter and more capable than most others around him, and he was probably right! However, clever architecture is seldom good architecture; simple beats clever every time.

For my part, my mistake was in not pushing harder and faster to use the Strangler Architecture pattern to build new capabilities into the system while allowing the previous architectural design to continue to function. I quickly recognized the problem (I had seen it, and done it, many times before), but I allowed the development teams to languish too long in the classic “big ball of mud” codebase.

Lessons Learned

The previous architect didn’t want developers having to waste time thinking about how to implement new functionality. After all, time is money, and why waste money on thinking time when someone more clever and more capable can come up with the design and allow others to implement the vision? The lesson here is that when you take the thinking out of development, you take the thinking out of the developer. Development is a mentally-intensive process, requiring a lot of thinking! Good developers think about the existing code base, the new patterns the team plans on using, the users and how they interact with the system, the previous capabilities of the system, the new functionality to be added, and how other developers will interact with, and respond to, the code that is created. This is a lot to think about, and the thinking associated with every one of these concepts adds quality into the system. When you eliminate one or more of these thought topics for a developer, you’re removing the ability for the developer to add quality through their thought processes. People are amazingly brilliant if you give them the opportunity to shine. So, give them that chance!

Agile Reinforcement

There are three principles from the Agile Manifesto that give us guidance here.

1. Continuous attention to technical excellence and good design enhances agility.

2. Simplicity--the art of maximizing the amount of work not done--is essential.

3. The best architectures, requirements, and designs emerge from self-organizing teams.

Together, these three principles tell the story of a great way for development teams to interact with the systems which they maintain. First, the development teams owns the software, lock, stock, and barrel. An outsider, such as an architect, that is responsible for the code or the solution removes ownership from the team. Second, when a team has collective ownership for a product, simplicity is encouraged. Collective ownership is innately hard because it involves multiple people. So, simplicity is key since simplicity improves readability and understandability, the two most important architectural constraints in virtually every system. Finally, a team that collectively owns their product can only continue to be agile and nimble when technical excellence and good design reign. Technical excellence and good design can never come from without, only from within a team that exhibits collective ownership.

SAFe Reinforcement

Adding to these principles, the Scaled Agile Framework also encourages us to…

1. Apply systems thinking,

2. And to unlock the intrinsic motivation of knowledge workers.

The first principle helps us recognize that we need to think about both the solution and the enterprise that builds the solution as systems that need to be managed. Embedded in the second principle is a subtle reminder that self-organizing teams are in the best position to enhance and improve any system. Self-organizing teams can most easily be identified by their engagement in collective ownership. When collective ownership is common, the team is largely self-organizing; conversely, when collective ownership is rare or difficult, the team flounders and is always looking for direction from others, usually from people outside the team. These non-self-organizing teams will invariably have quality problems, and any success will be the result of heroics. Self-organizing teams will invariably find a much more consistent pattern of success, with the occasional failure (although, they don’t call them failures, they are instead improvement opportunities).

I hope my struggles and failures can help teach you this important lesson: If you take the thinking out of the development, you take the thinking out of the developer.