The Software Dilemma

Any time software and business come together, there is an inherent conflict between “get it done fast” and “do a good job”. This conflict often comes to a head when deadlines are missed, whether through unrealistic expectation or underestimation on the part of the developers.

The dilemma between quantity, speed and feature set isn’t going to go away any time soon. It’s an inherent dilemma in software. But there are approaches we can take to help solve it.

Any software project has three core elements: the speed at which the software ships, the fidelity of the feature set, and the quality of the underlying code base. In a perfect world, we’d be right in the middle, like so:

The triangle makes clear that as you move towards one goal, you tend to move away from the others. Pushing for speed, for example, sacrifices quality and feature fidelity to some degree.

And yet, often its impossible to live completely in the center of the triangle. After all, there are deadlines to be met, and sometimes we need to push software out, even while incurring technical debt. But leaving the center of the triangle does not necessarily mean project ruin.

Imagine that the triangle has concentric zones. The outermost zone is a danger zone, where one priority is overemphasized to the detriment of all others. Inside that zone is a warning area, an area where a project can live temporarily, or even for a longer period of time, before things begin to go wrong. This area might represent short pushes in one direction or another for the good of the project or the company. And of course in the center of the triangle is a “green zone”, where all priorities are largely equal in value to the organization and the team.

Notice how the widest and largest area is the danger zone around the outside of the triangle. The inner core of warning and good are smaller. This is only natural: it’s easy in a software project to move too far off the safe ground, and too far towards one of the corners of the triangle.

We haven’t really explored the pitfalls of moving too far in one direction, so let’s take a look at each potential individually.

The need for speed

One of the most common things that developers hear from upper management is, “we need to ship, and we need to ship now!” The need to ship a product to the greater market is understandable, but can be misguided if we move too far away from the fidelity of the features or the qualtiy of the code. The effects may not be felt for some time, but at the end of the day, they will be felt, and usually with terrible consequences.

What happens when you sacrifice everything else for speed? You begin to incur something called “technical debt.” This is the weight of poor decisions made in the sacrifice of quality and feature set to speed. And that debt, like any debt, must be paid down eventually. The “interest” on the debt is longer lead times to implement new features in the future. And the payments can sometimes be so high that you end up in “bankruptcy” – a position where the code is so disasterous that it must be cleaned up at the expense of all new feature work.

Of course there are times when “damn the torpedoes, full speed ahead” is called for. From time to time shipping something to match a competitor is essential. Other times you may need to patch a vulnerability or a serious bug. These are valid uses of speed over all other considerations, and should be used sparingly.

A focus on features

One company I worked for had this plan to ship a piece of software that was at feature parity with all existing software in the field. They insisted that each feature be able to do everything that all their competitors features did. The end result? The product never shipped and the company inevitably went out of business.

Feature parity with existing software is a fool’s game. You end up chasing a moving target and never really focusing on what makes you special. Similarly, expecting that you’ll ship every single feature you can conceivably think of is a foolish enterprise as well. Multi-billion dollar companies (think Apple) have shipped with incomplete feature sets only to make modest improvements later on. Surely you can do the same thing.

Death by Code Quality

I am a huge fan of code quality, and I push for code reviews and code quality analysis as a core part of my business and a core part of the development process. But it’s possible to have too much code quality focus in your code.

Code quality focus becomes onerous when you start focusing on it at the expense of everything else. When code quality becomes a goal in and of itself, feature development halts and we’re ultimately never going to ship. Code quality for its own sake is a dangerous game, and one with serious consequences.

Any project will take on certain levels of technical debt in order to function. Some design decisions won’t be perfect or pure. That’s okay. But the developer who insists that no technical debt be taken and no corners ever be cut will find herself quickly holding together a failing project, because the end result will be a perfect monstrosity that doesn’t accomplish any of the goals of the company.

Striking A Balance

In every project it’s crucial to strike a balance. It’s important that every team understand the business needs of the project, alongside the technical needs of the project. Moreover, hiring a well-rounded team that includes business-focused programmers, creative developers and code purists helps ensure a healthy balance of developers all the way around.

For example, on a well-balanced team the business focused developer will understand the need to ship early and often and push on this central theme. Balancing him will be a creative engineer that suggests a new feature that could be incorporated. He convinces the business-minded developer and they together present it to a manager. Meanwhile the code purist has found several places for refactoring and recommends that we do them because they’ll make the product faster. Management likes this idea too, and agrees. All elements of the team are working, and no one area is overly represented.

Building this kind of team is hard, but worthwhile. Developer managers would do well for themselves to invest heavily in finding these right people and putting them in the right positions to have an impact.

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

There are currently no comments.

Copyright © 2023 by Brandon Savage. All rights reserved.