Over the years that I’ve worked on teams developing software, I regularly hear of the “three legged stool”, a metaphor for balancing three opposing aspects of the development process. The metaphor works well because if any leg of a stool is shorter than the other, the stool can stay upright but any pressure can cause it to fall over.

Not practicing one of them at all can make it not even able to stand. These three legs are quality, features, and schedule. The motivation between choosing these 3 aspects is to help business stakeholders, managers and developers make smart decisions about the compromises we inevitably make on projects. In practice however, I find that business owners will always choose features, managers will always choose schedule, and developers will always choose quality.

The reason behind this is simply a human desire for self-preservation. Business stakeholders’ performance is measured by what features they deliver, managers are measured by their ability to deliver on time, and developers are often measured by their ability to write solid code and deliver it with minimal defects. Since most organizations are structured where developers report to managers, who in turn report to the business; this places an uneven emphasis on adding new features at the expense of consistent time to market with new features of high quality.

As a developer or architect, the list of features and desired release date is often out of our hands, even with a backlog and a fairly well followed set of agile processes. Rather than continue this trend, I’m of the belief that even though business stakeholders are supposed to be the best people at knowing the business, they are often not well versed enough in technology to understand the implications of ignoring requests for refactoring, and making smart decisions with respect to technology selection. Developers are still the core of the value chain in this aspect of the development process. Rather than argue this point, I’d like to propose a list of 4 priorities that developers can regularly consider when making technology and design decisions. If you follow this set of priorities, you’ll find yourself regularly making the best decisions for all parties.

1. Can I implement the feature?
2. Does the design allow extension of features along planned integration points?
3. Is the design flexible enough to allow unplanned changes to be made?
4. Is the design, and are the technologies, the most modern available?

Can I implement the feature?

If you don’t make the software do what the business wants it to, you’ve failed as a developer. It doesn’t matter if you’ve used to most forward thinking technologies and patterns, and written unit tests to give you 110% code coverage (chuckle). If you don’t deliver to market what your business expects, users won’t have compelling reasons to use the software, your business stakeholders won’t have much to sell, and you probably won’t be seen as having much value in the company at one point or another. This assumes that the business is choosing the right features, and designing them to be usable, for success in the marketplace. If you don’t trust the business to make the right decisions here, I’d suggest you join another company you can be passionate about where you believe in the vision and leadership there. Above all else, evaluate design decisions and technology selections by their ability to enable you to meet the requirements and make the feature work. Usability and quality are included in this priority. I’m of the opinion that one should never deliver features that are unusable or of bad quality to the market. If a feature is hard to use, users won’t use it, or worse yet use it as an example of bad design to laugh at with their peers. If a feature doesn’t work, they will say bad things to their friends about your company and kill your brand. Enough said.

Does the design allow extension of features along planned integration points?

When you build a software product, unless you want to see a competitor blow you out of the water very soon after you ship your first version of a feature, you’ve got to have a backlog of new features to add in future releases. I’m of the opinion that this list of future features should be readily available to developers to provide transparency into the direction of the business. While it’s true that an inexperienced developer may look at a backlog and be tempted to make design decisions that extend the schedule and don’t add value needed in that feature or release, a quick read of YAGNI and a revisiting of that principle during design decisions should be all it takes to avoid this. The downside to not letting developers see the backlog of future features is much more nefarious; they can make design decisions that make it difficult, if not impossible to support features planned in the short to medium term future. There is a delicate balance here, but the heading says it well. Make decisions in your design that allow extension of features along integration points you really have planned. Stakeholders should have a way to identify features on the backlog that are uncertain (nice to have) or a duration of time past the current release after which they should not be considered in design decisions. If you’re not sure, don’t do it.

Is the design flexible enough to allow unplanned changes to be made?

I often encounter developers new to OO, data driven design, and contract-first development that go crazy with decoupling and make their designs overly complicated to implement with little value. They add interfaces to classes with trivial logic to enable unit testing (thus adding un-necessary assets to maintain, test, and revisit during refactoring), use solution-specific patterns to implement logic that really belongs in one method, and create complicated multi-step ETL processes to cover up for bad database design. As a developer, you should try to select patterns and technologies that follow best practices in the industry for enabling refactoring, testing, and feature integration; but only to a level that is sufficient to support the first two priorities. This priority is closely related to the one above with a crucial difference – the 2nd priority has a business stakeholder driving the decision for flexibility while this one is driven by a developer desire to use patterns that make the code easy to maintain or rapid to extend but that will be difficult to explain to business stakeholders and management. Usually it’s easy to convince management or stakeholders that you have to design an interface to support integration with data providers they have planned integration with in their backlog. It’s not as easy to convince them that a set of your classes need interfaces for passing into a processing pipeline of some sort when the processing could be done in one method, and there are no plans to modify the pipeline’s order. Read the Tradable Quality Hypothesis from Martin Fowler to help you convince management of the importance for supporting activities that fall into this priority when you feel the need for them.

Is the design, and are the technologies, the most modern available?

Last on your set of priorities should be using new technologies. ASP.NET MVC3, JQuery Templates, OData, Ruby, and F# may offer significant advantages over past technologies or patterns; but if using these doesn’t result in more success with the first 3 priorities, it’s hard to make a logical case for it. There are times where using a technology is necessary for marketing purposes, and in this case use of that technology becomes a feature itself (thus bumping it to priority 1) but otherwise there are many times when using an older version of a database, framework, or language is more than sufficient to enable the business to consistently deliver quality value to customers. Unless your organization has a handle on the first 3 priorities, you’ve got work to do before tackling this one.