Why developers should not write features.

At least not in the context of the system …

Now I know this is going to create many comments and many will not agree with me, but allow me to explain why.

The reasons for my statement are many, but the one that comes to mind first is that feature specifications tends to be incorrect. They are also changing constantly as in reality they try to capture a dynamic real world problem in a static snapshot . The feature specification only presents a synopsis of the user interaction and the desired outcome. The user will do x in some way using y to achieve z.

Let’s suppose the outcome of our solution architecture was a system that resembled a car. The car had components like seats, wheels, engine and gearbox.

Your feature specification would come in the form of a user story that looks something like this:

Some <persona> will do some <action>  so that they can achieve some <goal>.

<Johnny> needs a vehicle he can <commute> to <get to work>.

<Sandra> needs a vehicle so that she can <transport goods> to <deliver the goods to the market>

<Bronwyn> must be able to <Park> the vehicle so that it <is not obstructing traffic>

… and so your feature specifications continue forever …

Given 3 developers and a sprint you would land up with the following components:



Goods Transport


In the physical world, one will not design a car, based on the feature spec that says the user needs to travel from home to work. In fact if there was a feature spec for a car, based on user stories, and we built each story, we would have a huge amount of components. Many of these components would be variations of the same thing. In the context of feature driven development methodologies how is it ever possible to call out the  gear box and engine components? Can you imagine how many variations of engine and gearbox you will have if each developer creates similar components for , parking, reversing, driving ….

A feature specification also lacks the detail of the non-functional characteristics of the system. What are the transaction boundaries, security contexts, process boundaries,  machine boundaries, error handling, availability / durability / scaling strategies?

Sadly in most cases system plumbing runs on a one to one implementation ratio with the feature of the day. This means your system begins to explode with components, as each developer derives there own strategy to support there particular feature in isolation. When the feature changes, the change tends to resonate with the entire system, often injecting loads of risk into the production pipe line.

Scrum (which I have nothing against) unfortunately tends to put features on a story board as opposed to components. Developers tend to sit around the table and pick which features they would like to build. This act substitutes the the action of architecture and system design  for the act of “give me the spec” and I will build “parking”. The problem is this code stays in the system and adds to technical debt of the project life cycle.

Much like anything we build in the physical world, a feature ONLY surfaces as the product of integrating the underlying components together.  An architect will compile the list of required components, based on the natureof the over arching problem and not the feature specifications.  The developers should be building the components, and then finally integrate the parts, into working software meeting specification, under the guidance of the architect.

It is for this reason that I say, developers should not build features in the context of the system, they should focus on building the gear boxes and the engines and forget about driving, parking and reversing. It is the job of the architect to ensure that the composition of components, can meet all requirements based on the nature of the business. The composition should also capture the business volatility as to contain change at the component level.

All of this is much easier said than done, and it is for this reason that so many software systems, become non-maintainable and are due for that inevitable re-write. The fact is is that the act of writing a user story or feature, is easier than considering the real nature of the problem, and encapsulating that which changes. The skilled software architect if supported by the business can literally save the business millions of R&D dollars.

It is for the very nature of change, that system design is so important. A well designed system, is easy to maintain, lower in risk and cost of ownership is radically reduced.

More on architecture to follow soon …

Please be sure to leave your rant below. Thanks for reading 🙂

About The Author

Passionate about technology and software architecture. Husband and father. Chief Architect at Assima. Director of research and development for Assima South Africa.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.