Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Percent of time spent developing internal tools?

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 47 posts

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

#21

Post by asher_ »

tinco wrote: post #18
asher_ wrote: post #12

I see I need to add more specifics about my situation. I work at a university developing research software (primarily - some is also external customer facing). My customers are internal customers, thus profitability and other business measures are not directly my concern. The biggest issue I face with this is that my customers are non-technical people, so if I were to tell them that our infrastructure is now software…

In my opinion, you should not tell people who do not understand how analytics will improve your caching optimization that you are working on analytics. You should tell them you are working on improving the caching layer. If you sound confident that implementing analytics is required for this job to be done properly they will have to trust you in this, _you_ are the programmer. You are correct in your assertion that w…

I appreciate this reply a lot. This type of situation is a new one for me, I guess I should just bring up the subject as a whole and see how it goes. I hope I don't run into too much resistance since it will result in a short term decrease in deliverables.

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

#22

Post by gbog »

I'd leave the short term to short sighted people. In chess, in wars, in business, in software, the world belong to those who see far away.

As Napoleon said: l'intendance suivra, which means that short term and ancillary problems will be solved anyway.

Another way to say this is that if you keep the general long term direction, it will be ok to use dirty hacks to fix in fee minutes the short term problems, you will know how to do it in a way that we'll not hinder the long term path.

But make sure your tools and automation are really in line with the long term direction.

For example, building a chrome plugin to speed manual testing of a web app would be wrong, architecting it to be fully unit testable would be right.

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

#23

Post by dmgrow »

asher_ wrote: post #13
JangoSteve wrote: post #11

Of course it all depends on your actual business, income (i.e. how much time can you afford to spend on internal tools), needs, etc. Since you're talking about client-facing software, I'm going to assume you're in a software development company, which narrows it down a little. For our company, we don't develop internal tools for any given problem until it's a real pain. You'll know when it's an actual pain (as oppose…

Thanks! I'm in agreement with you, I don't like spending a lot of time on tooling if it isn't needed. I like only very simple tools, as I find complex ones inevitably add friction in the workflow and thus end up unused.

I would suggest that it depends a lot on the stage of the company. Early on, only build enough that you can legitimately track the key metrics. Other than that, focus on building the product.

As the product and business matures, it's likely that you will need to spend more time to ensure that the business can keep up with the product.

As a PM, I make sure that we've had to do the same thing manually a number of times before we spend any engineering time on automating it, or setting up the tools so that a non-engineer can do it.

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

#24

Post by btilly »

tinco wrote: post #19
6ren wrote: post #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

There are three cases for a task that takes a regular human 5 minutes and a computer programmer 5 hours to automate: 1 The task is very complex, this means that there's a lot of room for human error. A well-tested and specified program will reduce this fragility and improve predictability. 2 The programmer is inexperienced, the programmer either is not a very good programmer (yet) or is using tools that he is not fam…

You miss the most common issue:

4 The task requires interacting with a system that was not designed with automation in mind.

For instance you have a third party GUI which you don't have source to that you have to push a button on based on what it is showing you. So you wind up having to research this, work around it, etc. Often you can use a GUI test kit to solve it temporarily, but that is going to be fragile - on the next upgrade it will likely break.

In this case automation may not be worthwhile. What you're learning is not connected with what you do. The automated solution is more fragile than the human one. The time saved is not that important.

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

#25

Post by mixmastamyk »

duquesne wrote: post #15
6ren wrote: post #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

Even that 5 hours / 5 minutes is worth it if you're going to be doing it enough.

Or a dozen people are doing it dozens of times a day.

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

#27

Post by rhizome »

meaty wrote: post #20

I have actually automated myself out of a job before so be careful! Fortunately the company saw the value of this and contracted me on an adhoc basis. I wad the unfortunate administrator for a large virtual mail system in the uk which was run off exim and flat files across 50 machines (one per client). This took 3 guys full time to manage as the machines were all over the uk and needed regular maintenance. I centrali…

Why they didn't promote you for re-architecting their systems like that is a failure on their part. I hope your contract fee made up for that!

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

#28

Post by rhizome »

btilly wrote: post #24
tinco wrote: post #19

Earlier quoted context omitted.

There are three cases for a task that takes a regular human 5 minutes and a computer programmer 5 hours to automate: 1 The task is very complex, this means that there's a lot of room for human error. A well-tested and specified program will reduce this fragility and improve predictability. 2 The programmer is inexperienced, the programmer either is not a very good programmer (yet) or is using tools that he is not fam…

You miss the most common issue: 4 The task requires interacting with a system that was not designed with automation in mind. For instance you have a third party GUI which you don't have source to that you have to push a button on based on what it is showing you. So you wind up having to research this, work around it, etc. Often you can use a GUI test kit to solve it temporarily, but that is going to be fragile - on t…

The solution to that is to reimplement the functionality outside of the GUI. Write the GUI out of your life.

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

#29

Post by noduerme »

Irritation is a factor. If you sense you're going to be irritated by doing something a lot of times, and it's more fun to develop a tool than to do the tedious thing, then develop the tool.

My general rule of thumb is to tell the client you're going to charge 3x for the hours spent on tool development what you will for the tedious work, and let them decide which they think is in their best interests.

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

#30

Post by rhizome »

andrewf wrote: post #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…

You're generalizing too much. 1 and 2 are actually internal products and should be planned and budgeted out by higher-ups as projects. I have no idea what would constitute #4 the way you describe it, but it sounds like a business requirement that should also be dealt with as a project or internal feature. Lastly, #5 is business continuity and a primary function of IT in general.

This leaves #3 as a sector where the manual/automation see-saw can be improved by tooling. The others are more aspects of business that do not happen otherwise. Tooling is more concerned with easing the jobs of people who implement the thing being streamlined with the tool. In a sales context this would be something like switching to a shared address book or whiteboarding an in/out scheduling chart, both of which they can do for themselves. Interdepartmental deliverables are not tooling.

Post reply on HN