Write the Features That are Used Everyday

One of the things I learned during these years is that I should prioritise my work based on the possibility of that piece of work getting used by users. The more likely users use it (directly or indirectly), the more value and less maintenance burden there is.

The temptation of adding things we think is useful but without actually validating the idea first is dangerous. Each line of code is one line of liability. Code gets inevitably bit-rotten when nobody uses it. I've seen several examples myself, starting with the very feature I wrote.

Having no direct input from project managers and end users, it's a bit hard to imagine what would be useful or not. True, there are features that everyone thinks important, but many more are on the boarder line that we can't see immediate return of investment.

This is not to downplay features that are unclear whether users actually want but have strategic importance. Software needs to evolve. Users would like to see shiny new things. And sometimes we have to weight this factor in.

The experience of maintaining a piece of software helps me to become a better developer in that regard. When having a new project idea, I no long rush to write the code. I spend more time weighting the usefulness and the maintenance burden. I think long and hard about the design. My goal, in the end, is to maximise the return value of my work -- to write features that get used everyday.

Tweet