Software developers think in code, in diagrams, in technical terms. Business people think in features, revenue, and customer stickiness. In most cases, business owners care little about how the software is actually made, despite the fact that software developers want to show them how elegant their design is, or how bad the architecture is and needs to be refactored. The truth is, you have your job and they have theirs.

Selling Architecture to Business is a Losing Battle

Selling the business on architecture, or time to address technical debt, is a losing battle. So where does the responsibility fall for addressing these critical topics? By the time business recognizes architectural deficiencies, it’s too late. This is because the deficiencies will be visibly harming the business in ways such as an inability to add new features or difficulty remaining competitive.

To this end, software developers need to get better at a couple of things. First, we need to communicate with business stakeholders using business terms. We need to seek their engagement and figure out ways to talk at the code level while still speaking English (or whichever natural language is used in your organization). User stories, popularized by Agile methodologies, provide a mechanism to do this. This brings a natural language conversation pretty close to the code, but without the need to show ERD or UML diagrams.

Second, software developers need to take responsibility for technical debt. It’s unrealistic to think that any business could afford to dedicate large time chucks to refactoring architecture. Instead, incremental improvements should be made to architecture all the time. Architecture is never finished, and you can always do a better job. Especially as time goes on and everyone gains a better understanding of what truly needs to be supported.

Unfortunately, deadlines often place developers in positions of, “let’s get past this release and deal with the architecture later.” Later never really happens. There are more features to build and more deadlines to meet. And more architecture to put off.

Heading for a Cliff?

One trend that you’re heading for a cliff is if the analysis to put new features into the software is increasing. Does the solution to implement new features take longer and longer to develop? Even if the coding portion is relatively constant (once a solution is discovered), are you solutioning your way through a snake pit of fragile code, cobbled together short-cuts, short-lived design patterns, and a myriad of abandoned approaches?

If this is the case, you may be enabling your organization towards inevitable failure. When this happens, development needs to own the problem. This doesn’t mean begging the business for time. Instead, you need to identify key problems, develop strategies and remedies, and start addressing these solutions in the context of new features, improvements and other projects that are vital to the business.

I know, I know…

As a developer this is the most frustrating situation I’ve faced in my career. But I’m convinced that there are solutions and ways to remedy these situations. The responsibility rests on the shoulders of development, not the business. Ideally, this starts at the first line of code, so that incremental architecture is part of the coding culture. However, you can introduce this process at any time. The goal is to incrementally drive towards improved architecture. But you cannot think in terms of ideal design, and major refactors need to be introduced over time in phases. Usually, this requires insulating the rest of the environment from the changes using facade patterns and other techniques. Most of the big wins will come one at a time, with small improvements towards an end goal.