Features you shouldn’t build
As a developer if someone comes to me with a problem my brain starts working on a solution. It’s not a conscious decision and it’s not something I can stop. It’s that developers are compelled to fix problems, it’s how our brains are wired. To fix a problem you use the tools at hand and as a developer the tool closest to hand for us is to build software.
But for a lot of problems writing more code is the wrong solution.
Remember every line of code you spend on solving this problem is a line of code you can’t spend somewhere else.
You’re going to have to test, roll-out and maintain it. And new developers are going to have to get up to speed on it. You normally think of product managers as the ones weighing the costs and benefits of new features but the developer needs to be weighing the technical costs and looking out for features whose costs outweigh the benefits.
A lot of proposed internal features fall into this category. You’re eating lunch with the sales guys and they are complaining about how with all the steps they have to do it takes 2 hours to onboard customers. They ‘need’ a better tool to make onboarding the customer go faster. If you work in a high touch sales business and each salesman is only onboarding 10 clients a month then that’s only 20 hours a month they are spending onboarding. How much time is that new tool going to save them? As a rule of thumb for coding process improvements, if it doesn’t cut a tasks time in half it’s probably not worth doing.
Internal tools that aren’t just speeding up an existing process but are actually something new should be evaluated differently. They should be evaluated like any new product, is there a market for them? Since people aren’t actually paying the questions is “Will people use this?” People will only use a new tool if it makes their job easier. A good practice is to build an MVP and see if people actually use it. If the MVP doesn’t actually get adoption it’s unlikely there is demand for the full solution
A lot of internal tools get built because you hear about your coworkers problems a lot more than you hear about your customers problems.
If most internal tools are a bad idea because they might not be valuable enough business analytics are a bad idea because they are valuable. I’m defining business analytics as when you take all that raw data you have and crunch it to get information out of it. Pretty much everybody on the the business side wants this data because it helps them make better decisions and make more money.
So why shouldn’t you code up a solution for that? The problem is that business analytics are never done. The business side is going to be constantly looking at those numbers and wanting to tweak the analysis to get more information. Needing a developer for every minor tweak is going to frustrate them and the developer. In addition the business world has it’s own edge cases that you need to keep in mind. Why were sales down last month? Because it was February, which has fewer days. Why were sales up last month? Because it was December and customers needed to spend the rest of their budget.
A better solution is to give the raw data to the business side and let them do the analytics in Excel. If the business side doesn’t know how to use Excel you should start looking for a new job because your company is probably doomed.
The common thread between projects you shouldn’t do is that they aren’t using developer time on things that scale. A tool that only makes people marginally more effective only scales across a very large number of users. A tool that isn’t used doesn’t have the chance to scale. And a tool that requires constant developer input doesn’t scale at all.
