Unused features are technical debt

Technical debt is often described on a low level, where developers will take some kind of shortcut in order to deliver a feature quicker; at a cost to future development which must be "paid" sometime.

However technical debt can manifest itself in many different ways and one way it has reared it's head on a project I am working on is by unused features.

Delivery culture

Agile development has many flavours and in my experience it has been broadly about improving a team's capacity to release software by improving processes.

For the team I work on, it has worked out great. We generally deliver things in good time and we work well in a productive and enjoyable environment.

Right from the very top of the business at even the board level, the whole company is focused on delivering software and features to the areas of the business who need it. In our company we have a number of departments who fight for the features they want on our main website; plus a number of other products. These requests eventually filter down to the development team and we build them.

From there, that's more or less it; and that's the problem.

When a company becomes delivery focused, it forgets that it should be value focused.

Build - Measure - Learn

I've been reading Lean Startup and it focuses heavily on validating your assumptions when building products. It seems obvious really; you need to verify that the features you make actually have value.

From my (admittedly limited) experience with agile, teams invest a lot of time in terms of reviewing processes in order to deliver things more efficiently; but it doesn't matter how efficiently you deliver a feature that isn't used; you are wasting money by doing so.

This can sometimes be a hard sell to the business. People have forged jobs for themselves by making decisions on what should be built; based on their previous successes. It takes quite a culture shift for a business to acknowledge that it's assumptions about it's customers could be wrong.

However unless you validate your learning with actual real hard numbers, all that you are doing is guessing.

When you consider how expensive software development is, guessing is not good enough.

This is not to say that we shouldn't build anything without some peer reviewed, scientific thesis. In fact, building something and learning that customers don't want a feature is actually a really valuable piece of knowledge for a business to learn about their customers.

Lean startup talks about this in greater detail and I really do encourage you to check it out.

 So why is it technical debt too?

We have established that building unused stuff doesn't make business sense (duh); but it has many other unintended side-effects, which I will illustrate with an example.

I am currently working on a project which is taking some useful code we have within our big-blob mothership product and trying to extract it into smaller useful services for the rest of the business.

While doing this we invested a lot of time trying to figure out how we can refactor certain areas of functionality so that they carry on working as we break up the system.

Of course, a BA comes along who happens to look at Google Analytics and then tells us "oh well only a tiny percentage (like 0.0001%) of our users use that anyway".

facepalm

When you don't measure the success of features but leave them in the system, developers have no choice than to treat all the features on the product equally.

Developers have to be mindful of these features when trying to change the system to meet the business's needs; and this can have a considerable cost.

I felt frustrated, and I'm sure the business would too, knowing the time and effort wasted; simply because we don't know our product (and customers) well enough.

Side effects of unused features

I am quite confident that the business realises that a number of features on the site are much less important than others; but probably think "well what's the harm in it being there?". I shall try and debunk this line of reasoning here.

Every unused feature effects a businesses' ability to deliver value and makes the product worse.

Build time

Builds can often slow down the velocity of a team. For us functional tests with Selinium have often really slowed us down. Unused features are a pointless way of slowing down your build.

Refactoring

The best commits are the ones where you delete code as it's less code to maintain.

These so-called harmless features can reduce the malleability of your product because every time someone wants to change code they might have a dozen tests fail for a feature no one cares about.

Additionally, developers might think that generalising code to fit a number of different features could be worthwhile effort; but what if the dev could just delete them instead?

More to learn and understand

By having lots of features in a product, it simply becomes harder to understand; this again makes it more difficult for your team to deliver. In particular when making larger changes.

Demotivating

Knowing that you have to work with code which isn't actually useful, is a frustrating and demotivating thing for developers to face.

On occasion we have measured some feature's success and it was really exciting to see when a feature we made was really successful.

Every story should be like that.

Performance

A number of features we know intuitively (or with analytics) that are not used, are slowing down the delivery of features which are actually useful because they are on the same web page and happen to be backed by slow queries.

UX

Simple is good right? Why are you cluttering your search page with features no one uses? Unused features make your product harder to use and distract users from what you actually want them to do.

Moving on

There are plenty of tools now to validate learning. Metrics are trivial to assign to features and A/B testing frameworks can help you compare features and how a certain configuration can be more beneficial than another.

Rapid prototyping is an excellent tool to quickly test a business's hypothesis before investing too much development effort and as I said, every failed hypothesis is still a positive thing for the business as it improves it's understanding of it's customers to help it make more informed decisions later down the line.

I feel with the advent of agile development, teams took on more of a responsibility for delivery in exchange for empowerment. I think the next step in the maturity of an organisation is for the people responsible for picking features to work closer with the development team; which have the tools and expertise to help them learn more about their customers and make better decisions.

If you can create a learning culture within your business you can improve the motivation of your organisation, learn more about your customers and be more efficient.

Intangibles

Things become more difficult when you are unable to measure the success of a feature reliably.

This might be because of a salesman promising X sales if feature Y is implemented on the website. The development team has little choice and makes the feature but then sometimes this "vital" feature isn't used.

This usually comes about by customers not knowing their own needs, thinking they want a feature and demanding it from a salesperson; but they don't need it.

Even though the feature is unused, it still technically has given value to the business; at the customer's expense.

But eventually, the customer's perception as to how valuable your product is, may diminish. When you base your business on these intangible things, you are running a risk.

In these cases it would be nice to try and work with the customer to try and find features that they want and that they will actually use, as chances are other customers might find them useful which could then lead to more sales than if you just left the customer with their pile of unused features.

It would be exceptionally brave to contact a customer and say:

"You demanded and paid for these features but we notice you haven't used them, is there any way we can make them useful to you?"

but it could lead to some valuable insights about your customers and open up new opportunities.

 Other examples of intangibles

• "It'll improve SEO"
• The person purchasing is not the end user, but is buying on behalf of the users.

Conclusions

Software development has almost always been trying to become more efficient. Whether it is with different programming languages, new development techniques and different styles of project management.

Producing only what is valuable is vitally important but in many domains trying to define what is valuable can be hard, but still very important. Without this understanding the business will find it hard to find new ways to appeal to customers; which is too short-term of a viewpoint.

Thankfully these techniques are widely known these days and many companies can attribute their successes to them. In Lean Startup, it discusses how Facebook really understood their users and that helped them become what they are today. I have been to talks where engineers talk about how they often experiment and hypothesise what their users will like and measure it's success.

It is up to development teams to evangelise this kind of approach upwards, to show how the business can get more out of it's development; if it is willing to work more with developers.