Live data from Hacker News

Ask HN: Percent of time spent developing internal tools?

news.ycombinator.com

41–47 of 47 posts

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

#41
post #30
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 m…

I think he was actually fair spot on, I work on an "Internal Tools" team, and we do #1 - #4, in addition to maintaining the bug tracker, finance and audit tools, and a translation/review product. #5 is definitely DevOps though.

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

#42
Everyone on this thread focus on business decisions should something be automated based on perceived monetary value.

However, there is another important aspect in developing internal tools. In a lot of setups, developers rarely have a chance to investigate new technology, new development approach, different architecture, even different programming language on a day to day basis. Work is mostly done using predefined set of technologies.

For tools, the technology requirements are almost always much more relaxed, so the developers themselves gets to choose and try different approaches. While not every tool might end up being success in strictly measured time/money saved sense, in the long run it will help developers stay up to date with the technology, and even apply lessons learned in the real/product development.

As a bonus, employee retention might improve as people won't get bored so soon if they have a chance to try doing something new from time to time.

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

#43
post #30

Earlier quoted context omitted.

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 m…

I think he was actually fair spot on, I work on an "Internal Tools" team, and we do #1 - #4, in addition to maintaining the bug tracker, finance and audit tools, and a translation/review product. #5 is definitely DevOps though.

You both may be right in terms of the semantics and divisions of labor in your respective companies/experiences, but they are more general than the historical sense of tooling in a systems context.

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

#44
As a client-oriented business, I am a proud disciple of the Gospel of Tools.

1. Tools are one of the few institutional advantages that are in the domain of the programmer (rather than the MBA or the sales force). There are many shops out there that suffer from a lack of technical leadership and compete on the basis of (absolutely incredible!) strength of the sales force. Software developers don't win at that game.

They can, however, win at having the best tools. You have to have some unfair advantage, and in most developer-run studios, tools are easier to cultivate than sales methodologies.

2. Customer-facing tools provide customer-visible value. If you're writing error-reporting software that helps debug issues on customer systems, that's providing visible value. If you have client dashboards that show the status of their project and predict ship dates, that's visible value. If your network protocol is faster than REST for your vertical, that means faster software, and that's visible value.

It's all about giving your customers something to hang their hat on to select your shop. If they are getting "good vibes" from the other sales guys, but your software automatically builds them a Powerpoint deck of the project status to present at the weekly update meeting, then there's some class of customers who will prefer working with you, and you are better insulated from competition.

3. If you and your competitors don't do tool investment, then all the boats will rise at the same speed. But if you are doing tool investment, your boat will rise faster. At some point you can do the same job and provide better value than anyone else. When people figure that out, your competitors are forced to first, cut prices to remain competitive, and second, raise expenses to try and achieve tool parity. But you've already got a long head start, so they will either run out of money, license the tools from you, or just focus on the more sales/MBA-receptive customer base, and shrink to a niche offering.

4. As I've hinted at, tools can be valuable and can be licensed to other shops. The only way to really get out of the client "rat race" is to become a product company. Tools are an easy way to make that transition; you have a built-in customer base and an intimate knowledge of the problem domain.

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

#45
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…

It looks like you're trying to do the right thing here, even though there is no boss or peer who understands exactly what you're doing and can appreciate that fact. Kudos for that :)

To echo tinco's comment, do not try to explain the intricacies of what you're doing to your customers. Put yourself in their shoes and think about what is important to them. Explain just the "end results" of your tooling, emphasizing the points that are important to them and leaving out everything else.

For example, you could say that the caching rework will improve the performance of the system, software-defined infrastructure will ensure minimal downtime in case there's a hardware failure, etc. These are all benefits your customers will understand, even though they may not care or understand how exactly you will achieve them.

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

#46
post #27
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!

a) they were assholes, b) yes - daily rate was previously my weekly rate :)
Post reply on HN