Worse is better!
30 March 2020
If you are working on a product that involves software, you may realize a considerable number of the features you build are never utilized by your users. And while some of those may be there due to legal reasons, the fact that you spent resources with little to no return of your investment does not change. To make matters worse, these features increase the system’s complexity and make the remaining ones less discoverable. Combined with the understanding that the majority of the work which goes into a product is not in functionality that sets it apart from the competition, I have become a firm proponent of data-driven decisions.
Unfortunately, reaching the blissful stage where your organization can acquire and make sense of data as well as use them for decision making, requires a considerable investment. Investment in both the relevant technical infrastructure and product features as well as peoples’ mentality. For example, functionality that allows data gathering, quick feedback loops and experiments needs to be implemented. Moreover, individuals have to accept that navigating the market based on opinions or, worse, a “hunch”, is tremendously costly and risky. To be honest, such a transition will not happen overnight and it is ultimately a matter of culture. Before anything else, the change will never occur unless the status quo is questioned.
You can begin changing mindsets towards a data-driven approach by making the need for it (more) obvious.
When someone proposes a new requirement, feature or change, the usefulness of which is not
beyond the obvious, you simply ask “Why? What value does this bring and to whom?”.
This question will force the requester to contemplate the potential return of investment and argue
logically for it. Additionally, this may commence a conversation on the ways the change will affect
performance, complexity or architecture.
Once the proposal has been reasonably defended and the requester has not changed their mind, the next question
is “OK, can you prove it?”.
It is unlikely you will get a response citing facts and data. If you are lucky, a particular use case of one
or more customers may be mentioned. This may be good enough if you are working for the particular customer(s),
e.g. you are their supplier. However, if you are aiming at a broader market segment then this simply should not be
sufficient. You are not consulting for the specific subset of your consumer audience, therefore the benefits
of satisfying their demand do not necessarily justify the change.
You may eventually have to grant the request since you also lack data and do not want to come out as someone
unreasonably negative. Nevertheless, with this negotiation, you have hopefully planned the seed. Keep reminding
it is better to make happy customers than making customers happy. In other words, you should prefer to be
proactive than reactive. Do this enough and your organization members may start shifting away from the current
opinion-driven approach.
Steering clear of features that do not adequately increase the value of the product is not only about saving money. They affect the user experience, the maintainability of your software and more often than not, technical debt. The more features you add, the more cluttered your product is likely to become. Simultaneously, the complexity is bound to be raised which adversely influences maintainability. This realization sold me on the oxymoronic correctness of Worse is better.
Worse is better or the “New Jersey style” is an approach that
values simplicity most, in software design. Furthermore, it favors being simple than correct. Next, it
tolerates the sacrifice of consistency and completeness in favor of other quality attributes, especially when
complexity is inflated on their behalf. I have grown very fond of this statement, not just because it is
provocatively amusing. What it lacks in straight-forwardness, it makes up for the truth it entails.
“Worse” is indeed better when a project gets bombarded by feature requests, stemming from arbitrary hypotheses
with dubious marketability. The desire of salespersons to satisfy a couple of new leads is not a good enough
reason for R&D to cram new functionality into the product. Succumb and you will find yourself in a downward spiral
that results in tilting the balance of power between the company and its customers towards the latter. Consequently,
if this relationship gets abused, your organization may end up pampering few “loud” customers ignoring the needs
of a much larger user base.
Instead of a conclusion, I strongly encourage you to have a look at several excellent reads by the Software Engineering professor at Chalmers, Jan Bosch. They have been a fantastic source of inspiration for many of the thoughts illustrated in this article:
