3. Always Consider the Return | The Axioms of Software Development

Team Avatar - Mikel Lindsaar
Mikel Lindsaar
March 11, 2020

Axioms are self-evident truths. The axioms of Software Development isolate key basics underpinning successful software development. These axioms build on each other. Understanding the first one will aid your understanding of the subsequent ones.

This is part of the series on the Axioms of Software Development. If you haven’t read the previous axioms - you can see them here.

It’s my aim that by helping you understand these axioms, I can help you resolve problems associated with coordinating developers, time and resources and ensuring your software project is successful.

3. Always Consider the Return

This axiom is key when working out which features should you develop and in what sequence. This is closely related to the first axiom: required features will ALWAYS exceed available budget. A return can be considered a profit from an investment, be that time, money or goodwill.

In our earlier example, if the feature is created to allow a customer to edit the line-item, then that’s a feature that brings a return. We then have to ask what the return will be for each feature: how much better is the application if it’s a pop-up or an inline edit, thus avoiding a page reload? 50% better or only 1% better?

Just say it works out to only be a 10th of 1% better. Is that worth spending two days building it? The answer is obviously “no”. So, let’s move on and pick the next feature and examine the return it will bring.

As you do this, you’ll find you will start concentrating on the things that really matter in your application. For example, an ecommerce solution is useless without a way to checkout. It’s even more useless if you can’t see a list of products for sale and below that it’s basically worthless if you can not even display a product! So prioritising a smooth checkout flow before you have delivered viewing a product on the site would be out of sequence and detrimental to the project’s success.

While it is an extreme example, ending up with an ecommerce application with the world’s most intuitive, mobile friendly, super fast, high conversion checkout flow, but no way to view and add a product to a cart because you ran out of time or budget, would be a pretty useless ecommerce solution.

As your application becomes more and more feature complete, the incremental return on each new feature will reduce to the point where you are looking at building features that might only make the app one 10th of 1% better. But this is fine, because over time more and more people should be using the application and this 10th of 1% would represent quite a large return from an expanded user base.


Deciding What Feature to Develop Next

In deciding which feature to develop next, you should keep this formula in mind: The Return Value is equal to the Benefit Gained multiplied by the Volume of Use with the Cost to Implement subtracted, or:

RV = (B x V) - C

While it might be possible to plug in actual numbers and rank a feature backlog precisely, usually there is no need. Just look at your list of features and scan down them and assign each of them a Return Value (tiny, small, medium, large, huge). Then rank these by their return value and you will instantly have the key features you need to deliver first.

This “correct sequence” thinking in terms of return on investment is critical to how you get a project delivered on time and on budget.

Sometimes though, you really want this special feature. It’s going to add some pizzazz to your application, setting it apart from the competition and you are heavily invested in it.

Even in this case, it is still best to put it off until after all the critical features are done first. You don’t have to launch immediately once all the critical features are done. But you CAN.

This is an important distinction.

Being in a situation where your app is ready to launch and you are polishing it with any remaining budget of time and money is a much better space to be in than the budget running out with key features barely started.

Every feature of your minimum viable product must be evaluated based on its return and development must be prioritised on those features that deliver the highest return first.

This may seem pretty obvious but you would be surprised how often it doesn’t happen and you end up with zombie projects that are draining everyone’s will to live.

Are These Axioms Helping You?

I hope you are getting value from these axioms. Please send me through your feedback and thoughts.