Live data from Hacker News

Ask HN: Percent of time spent developing internal tools?

news.ycombinator.com

1–10 of 47 posts

Ask HN: Percent of time spent developing internal tools?

#1
An issue I am facing at work at the moment is determining how much of my time I should spend developing internal tools (automation etc) that allow me to be more efficient in my job versus developing client-facing software.

How do you make a determination of how much investment you should make in this area? I need to keep value flowing to the customers in the short term but obviously internal tools allow me to do this better in the long term.

Re: Ask HN: Percent of time spent developing internal tools?

#4
Tools are automation.

Rule of thumb: do it manually three times before automating it. That way, you'll have a fair idea of what it is supposed to do (which is the hardest part); you know whether it's predictable enough to be automated; and an how often it will come up.

A programmer is someone who takes 5 hours to automate something that takes 5 minutes

Re: Ask HN: Percent of time spent developing internal tools?

#5
Very little. A lot of people automate waaaay to early (it's the engineer in you). Of course this is very dependent on your situation (startup vs agency/shop).

I always suggest a digital assistant first. Pay $4-10 an hour and let someone else do it. Wait until that cost becomes a thorn in your side.

Re: Ask HN: Percent of time spent developing internal tools?

#6
I can think of many things that could qualify at "internal tools." The question is broad and the answers depend on what your business is, who works there, and what they do (yourself included!)

Possible "internal tools" that come to mind are: (1) Analytics (2) CRM-y stuff for the sales and support people (3) Deployment and testing stuff for technical people (4) CMS-y stuff to enable non-technical people to experiment with, or even implement, things that are client-visible. And for technical people to do so more efficiently. (5) Backup, redundancy, disaster recovery etc

If none of these seem more important than others, I guess you need to ask: where is the business now? Where will it need to be in months? How are we getting there? What are the pain points? How can the above improve this (versus implementing new features)?

One cherry-picked example: should technical staff time be spent on improving sales? If sales are your company's limiting factor and you don't have enough salespeople, making them more efficient is really important. If you're still in a soft launch-ish place, then it's not. If you have enough salespeople but not enough leads, maybe mining your own data, or public data, could produce some.

Re: Ask HN: Percent of time spent developing internal tools?

#7
For new projects or existing projects that desperately need tools, %80-%90 percent is good. The rest can be used for small changes that have visually large results to keep the uppers happy. After you have a basic tools stated %20 or one day of the week to work on tools is good.

Re: Ask HN: Percent of time spent developing internal tools?

#8

How is this different from any other business decision that you'd make? Estimate the costs, estimate the benefits, estimate the rate of return, and proceed if the rate of return exceeds that of the alternatives.

I agree. Do the math. If you don't have the man power and the math makes sense, contract it out.

Re: Ask HN: Percent of time spent developing internal tools?

#9
Easy! If this is your company, dedicate as many resources as possible to get you to profitability the fastest.

Would adding better analytics allow you to convert more prospects? Sounds pretty important for getting business, despite it being an internal tool.

If you're pre-revenue, or pre-sustainability, all your efforts need to depend on becoming sustainable. Otherwise, you're making a great product for nobody.

Re: Ask HN: Percent of time spent developing internal tools?

#10
I think before you start automating you business and processes you first need to know if your product will get any traction. Spending the time on making sure you have the best possible MVP is the most important thing, IMO. You may be launching a lot of tasks manually and modifying the database directly from the console at first but so be it. The fact is that creating internal tools is very expensive and only indirectly provides benefits to your product.

You'll know when you'll need to build better automation to your product; there won't be enough time to get everything done in a day.

That said, there's a downside to following this approach. When you will need to build automation tools you'll be conflicted with spending your time on automation or on improving your product. Improving your product directly provides benefits, tools indirectly provides benefits. It can be sometimes hard to convince yourself or others that you need to spend x% of your time on internal tools.

Where I work we're at a point where automation is very important. As the CTO of the company I constantly have to challenge the CEO and others that spending money on tools will give us some benefit in long term. The rule (or high level design pattern) that we are trying to implement is for every module of our product, there is a tool to understand the data better for debugging purposes (e.g. a UI to see what step in the workflow the process is in and/or what errors happened, etc), and if data is generated, there's an API/Service to get the data out easily.

Post reply on HN