<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
Write the Features That are Used Everyday
上一篇: Python代码片段:抓取手机归属地信息
下一篇: 没有了
网友评论已有0条评论, 我也要评论