6 ms·

Can’t say I agree. You should only build tools if the time saved on the task is greater than the time it takes to build the tool. And in a lot of cases, you don

Can’t say I agree. You should only build tools if the time saved on the task is greater than the time it takes to build the tool. And in a lot of cases, you don’t actually know in advance what the common and time consuming admin tasks will be. The absolute worst thing is to spend valuable time building an admin tool you don’t end up using. So wait until you see an actual need, and then build your tools.

subradios 4y ago
Admin tools, particularly federating admin actions in a distributed team - will never not happen. Their shape may change, but devoting time to building the first version will give you the harness you need. Source: I am writing three services at this point that are mostly Middleware to deal with the lack of native federation for certain services we use.
aargh_aargh 4y ago
Obligatory: https://xkcd.com/1205/ https://xkcd.com/1205/
- klodolph 4y ago
  I wonder if there's an admin tool someone can make that pattern-matches reposts of XKCD and deletes them.
  - vntok 4y ago
    From the linked xkcd, that seems like a tremendous waste of time..
    - klodolph 4y ago
      I'm not so sure. Multiply the number of "obligatory XKCD" comments made on Hacker News by the average number of minutes wasted by unfortunate souls reading them, and I think you could probably save an FTE or two.
  - mindcrime 4y ago
    That would be silly by https://xkcd.com/1053/ https://xkcd.com/1053/
- atoav 4y ago
  One thing not in the xkcd is "how much time it takes you to make the script". Let's say there is some weird service that you sometimes need to manually restart in a very specific order for maintenance. The hard (time intensive) task is figuring out the right incantations and the order to do it. It is however not time intesive at all to store those incantations in a shell script. So not saving that in a script risks you (or a co-worker) having to go through this again, potentially missing some important aspect and wasting time and energy.
  - bluepnume 4y ago
    Isn't that exactly what the xkcd covers?
    - atoav 4y ago
      Sure in a sense, but my feeling is that this is often taken too literally. Sometimes the work is "making the script beautiful and universal" and then you should indeed consult that xkcd. Sometimes the work is spitting the commands you had to figure out anyways into a shell script in 5 seconds. Then it is a no brainer to do it, because it will safe you time even if you use it only once.
- dceddia 4y ago
  I like this XKCD and I think about it a lot, in a “is it really worth my time to do this?” kind of way. One thing the time-based framework doesn’t account for is the mental energy you could save. A small example: I sell a software product, and every now and then someone would ask for an invoice. So I’d have to look up the order, copy an ID and an email, make a PDF, and email it over. Was it hard? No, it took 2 minutes. But I loathed doing it. So I wrote a little invoice page that looks up their order and let’s them put in whatever info they need, and generates a PDF. It took a day or two. I’m 99% sure this will never ever pay off in terms of time savings, but it gives me great joy to know that I will never have to do that energy-sapping task again.
  - agentwiggles 4y ago
    _Nothing_ takes 2 minutes, though! The context switching from whatever other thing you actually wanted to be focused on probably costs you at least 15-20 minutes. If it took you 16 hours of dev work to automate the process, it's only going to take you something like 50 invoices to recover your lost time when you account it that way. Seems like a great tradeoff to me. And reducing your own misery, is, of course, invaluable!
atoav 4y ago
Admin tools are not just time saved. They are also in itself documentation. If you just echo the one-liner you hammer into the terminal occasionaly into a shell script it could already provide worth just by being a file others (or the admin themselves) can see in the future. And this costs you nothing. Bonus points if it is something complicated that needs to be repeated occasionally. If it is something that needs half an hour reasearch and careful treading before getting the desired result and it costs you basically zero to save it in a script, just do it.
- ozim 4y ago
  For me it breaks when people try to make scripts/tools that are doing too much. Because at some point these break for variety of reasons. Then wrapping my head around monster script is additional work I need to do on top of understanding system that is changed. I argue that it might be quicker to understand system on its own and make changes manually than rely on someone else script. In the end if script works it works time money saved - when it breaks it is more work and now there are 2 things one has to figure out. That is why I'd rather have smaller scripts that do parts of bigger job instead of someone dropping "just run this and it will do everything for you" type of scripts.
- cramjabsyn 4y ago
  > They are also in itself documentation No, your in house scripts are not documentation, because they provide little context or rationale. In many cases they make the system more opaque by masking fundamental admin actions inside poorly commented wrappers. There is no substitute for well written documentation
twelvedogs 4y ago
at absolute minimum i would say when you have to do an admin task twice through messing with the database or something is when you should probably add an interface for it, guessing what tasks the user (or reality) will screw up is hit and miss at best. some of these tasks when caused by human error the better idea is to make it more difficult to break the system than just easier to fix it and allowing the user or admin to fix it on their own hides the issues away
koonsolo 4y ago
At my first job I wanted to automate the way a customer bought a product and got the license key. But the project manager said not to waste time on this, he was going to do all of that by hand. So my obvious response was "What are you going to do when we have a crazy amount of sales and you have to handle all of them by hand?". His response was "I would love to be overloaded with that work! That means we are selling and have money to develop an automated system". I learned a valuable lesson that day: Build it when you really need it. It's highly likely that you will never need it.
- pydry 4y ago
  And? Were you ever overloaded?
  - koonsolo 4y ago
    No :D. Good thing we had many products, not all using that system :D
hurril 4y ago
It isn't always clear what that timesaving would be, though. We have to factor in the marginal utility and alternative cost with every- and anything the resources in question thinks about doing (or does.) Not writing the admin tool might save time in the short term. But as I'm serving you with reports from the database and changes directly in it, I'm not doing other productive work. So you get the reports sooner and the time it takes to give you one is pretty quick. But that task could have been done by you if you knew SQL. Or a junior programmer. Or by the admin tool. And I could have spent that time developing customer features (or the admin tool.)
- jakelazaroff 4y ago
  That’s why I’m saying you should wait until you have an idea of how much time a task takes before automating it. If manually providing reports uses up a lot of your time, you can always build the admin tool. But if you build a tool that no one ends up needing, or if building it takes more time than you save, you can’t exactly un-build it and get your time back.
JohnCClarke 4y ago
It's important to keep in mind that automating tasks also improves quality. So even if it looks like time is wasted, preventing just a single mistake administering a customer's account can be worth a huge amount of earlier investment. Also the time spent building the first tool probably includes a quantity of "overhead" (auth, logging, etc.) which gets quickly amortised on subsequent tools.
thraxil 4y ago
I agree if you are only considering whether to automate your own tasks. The value of "admin tools" goes way up when they enable someone else to self-service on tasks that would otherwise require intervention from you or your team. Often in those cases, the value vastly exceeds what you might get out of it yourself in terms of speeding up work that you did manually.
gnutrino 4y ago
(author). I agree with your sentiment , and try to make this point in the article. This is why I suggest using out of the box admin frameworks and other ways to provide quick admin features. Only spend time adding custom functionality once a need arises. With this approach you already have the frameworks setup, tested, and you have been writing your code with support in mind.
- jakelazaroff 4y ago
  Thanks for writing the article! It definitely helped me crystallize some of my thoughts around this. I think the point at which we differ is that I actually prefer the "Oh #&@$ Solution". Part of it is to avoid building tools that I never end up using. But even if I do use a tool a lot, I would still rather slow development later rather than sooner. For example, I'm the only engineer, building an admin tool means product development stops, whereas if I wait until we've hired another engineer it means it only slows down by 50%. Or, if we only have a few months of runway, it's much more valuable for me to work on things that increase revenue or decrease costs in terms of actual dollars than things that make the company more efficient. Obviously these are contrived examples, but the general theme here is that time now is more valuable than time later. So the further into the future something is expected to pay off, the more suspicious of it you should be.
123pie123 4y ago
It depends... I loved building tools and did it to get better/ faster at writing scripts and/or for fun eg trying to solve puzzles. I would try and write tools/ scripts for anything This helped me to get faster at writing tools - to the point where I automated a large porportion of my job - allowing me to spend more time on working on the stuff I liked - leading to me moving away from Admin
simonw 4y ago
This is why it's great to have a loose framework for admin tools from the very start - I usually use Django so I almost get this for free. Building an authenticated admin UI for something is a lot of work. Adding a "see most recent orders" page to an existing admin UI can take just a few minutes, once that framework is in place.
- jakelazaroff 4y ago
  Yeah, I tend to work mostly within the JS ecosystem, but I’ve used Django before and its admin panel definitely makes me jealous. That said — if I’m just looking at data, it usually takes me a pretty long time to outgrow poking around the database with a read-only user.
  - simonw 4y ago
    I built a Django extension for that! Lets me poke around with a read-only user and then bookmark the results to share with others: https://django-sql-dashboard.datasette.io https://django-sql-dashboard.datasette.io
kwhinnery 4y ago
(disclaimer - I work for Retool) This take is correct IMO - it's only worth building a tool if it saves you more time than it takes to develop. This is why Retool exists - if building/changing an admin tool takes about as much time as assembling a Keynote presentation, then the economics of using custom software to solve small problems start to work out in your favor.
syngrog66 4y ago
"Pave the Paths" my own name for this rule of thumb. based on the story about the MIT campus where they put in grass but no sidewalks, and then waited to see what kind of natural trails formed from natural walking and biking. then put sidewalks there

subradios 4y ago

Admin tools, particularly federating admin actions in a distributed team - will never not happen. Their shape may change, but devoting time to building the first version will give you the harness you need. Source: I am writing three services at this point that are mostly Middleware to deal with the lack of native federation for certain services we use.

aargh_aargh 4y ago

Obligatory: https://xkcd.com/1205/ https://xkcd.com/1205/

klodolph 4y ago
I wonder if there's an admin tool someone can make that pattern-matches reposts of XKCD and deletes them.
- vntok 4y ago
  From the linked xkcd, that seems like a tremendous waste of time..
  - klodolph 4y ago
    I'm not so sure. Multiply the number of "obligatory XKCD" comments made on Hacker News by the average number of minutes wasted by unfortunate souls reading them, and I think you could probably save an FTE or two.
- mindcrime 4y ago
  That would be silly by https://xkcd.com/1053/ https://xkcd.com/1053/
atoav 4y ago
One thing not in the xkcd is "how much time it takes you to make the script". Let's say there is some weird service that you sometimes need to manually restart in a very specific order for maintenance. The hard (time intensive) task is figuring out the right incantations and the order to do it. It is however not time intesive at all to store those incantations in a shell script. So not saving that in a script risks you (or a co-worker) having to go through this again, potentially missing some important aspect and wasting time and energy.
- bluepnume 4y ago
  Isn't that exactly what the xkcd covers?
  - atoav 4y ago
    Sure in a sense, but my feeling is that this is often taken too literally. Sometimes the work is "making the script beautiful and universal" and then you should indeed consult that xkcd. Sometimes the work is spitting the commands you had to figure out anyways into a shell script in 5 seconds. Then it is a no brainer to do it, because it will safe you time even if you use it only once.
dceddia 4y ago
I like this XKCD and I think about it a lot, in a “is it really worth my time to do this?” kind of way. One thing the time-based framework doesn’t account for is the mental energy you could save. A small example: I sell a software product, and every now and then someone would ask for an invoice. So I’d have to look up the order, copy an ID and an email, make a PDF, and email it over. Was it hard? No, it took 2 minutes. But I loathed doing it. So I wrote a little invoice page that looks up their order and let’s them put in whatever info they need, and generates a PDF. It took a day or two. I’m 99% sure this will never ever pay off in terms of time savings, but it gives me great joy to know that I will never have to do that energy-sapping task again.
- agentwiggles 4y ago
  _Nothing_ takes 2 minutes, though! The context switching from whatever other thing you actually wanted to be focused on probably costs you at least 15-20 minutes. If it took you 16 hours of dev work to automate the process, it's only going to take you something like 50 invoices to recover your lost time when you account it that way. Seems like a great tradeoff to me. And reducing your own misery, is, of course, invaluable!

atoav 4y ago

Admin tools are not just time saved. They are also in itself documentation. If you just echo the one-liner you hammer into the terminal occasionaly into a shell script it could already provide worth just by being a file others (or the admin themselves) can see in the future. And this costs you nothing. Bonus points if it is something complicated that needs to be repeated occasionally. If it is something that needs half an hour reasearch and careful treading before getting the desired result and it costs you basically zero to save it in a script, just do it.

ozim 4y ago
For me it breaks when people try to make scripts/tools that are doing too much. Because at some point these break for variety of reasons. Then wrapping my head around monster script is additional work I need to do on top of understanding system that is changed. I argue that it might be quicker to understand system on its own and make changes manually than rely on someone else script. In the end if script works it works time money saved - when it breaks it is more work and now there are 2 things one has to figure out. That is why I'd rather have smaller scripts that do parts of bigger job instead of someone dropping "just run this and it will do everything for you" type of scripts.
cramjabsyn 4y ago
> They are also in itself documentation No, your in house scripts are not documentation, because they provide little context or rationale. In many cases they make the system more opaque by masking fundamental admin actions inside poorly commented wrappers. There is no substitute for well written documentation

twelvedogs 4y ago

at absolute minimum i would say when you have to do an admin task twice through messing with the database or something is when you should probably add an interface for it, guessing what tasks the user (or reality) will screw up is hit and miss at best. some of these tasks when caused by human error the better idea is to make it more difficult to break the system than just easier to fix it and allowing the user or admin to fix it on their own hides the issues away

koonsolo 4y ago

At my first job I wanted to automate the way a customer bought a product and got the license key. But the project manager said not to waste time on this, he was going to do all of that by hand. So my obvious response was "What are you going to do when we have a crazy amount of sales and you have to handle all of them by hand?". His response was "I would love to be overloaded with that work! That means we are selling and have money to develop an automated system". I learned a valuable lesson that day: Build it when you really need it. It's highly likely that you will never need it.

pydry 4y ago
And? Were you ever overloaded?
- koonsolo 4y ago
  No :D. Good thing we had many products, not all using that system :D

hurril 4y ago

It isn't always clear what that timesaving would be, though. We have to factor in the marginal utility and alternative cost with every- and anything the resources in question thinks about doing (or does.) Not writing the admin tool might save time in the short term. But as I'm serving you with reports from the database and changes directly in it, I'm not doing other productive work. So you get the reports sooner and the time it takes to give you one is pretty quick. But that task could have been done by you if you knew SQL. Or a junior programmer. Or by the admin tool. And I could have spent that time developing customer features (or the admin tool.)

jakelazaroff 4y ago
That’s why I’m saying you should wait until you have an idea of how much time a task takes before automating it. If manually providing reports uses up a lot of your time, you can always build the admin tool. But if you build a tool that no one ends up needing, or if building it takes more time than you save, you can’t exactly un-build it and get your time back.

JohnCClarke 4y ago

It's important to keep in mind that automating tasks also improves quality. So even if it looks like time is wasted, preventing just a single mistake administering a customer's account can be worth a huge amount of earlier investment. Also the time spent building the first tool probably includes a quantity of "overhead" (auth, logging, etc.) which gets quickly amortised on subsequent tools.

thraxil 4y ago

I agree if you are only considering whether to automate your own tasks. The value of "admin tools" goes way up when they enable someone else to self-service on tasks that would otherwise require intervention from you or your team. Often in those cases, the value vastly exceeds what you might get out of it yourself in terms of speeding up work that you did manually.

gnutrino 4y ago

(author). I agree with your sentiment , and try to make this point in the article. This is why I suggest using out of the box admin frameworks and other ways to provide quick admin features. Only spend time adding custom functionality once a need arises. With this approach you already have the frameworks setup, tested, and you have been writing your code with support in mind.

jakelazaroff 4y ago
Thanks for writing the article! It definitely helped me crystallize some of my thoughts around this. I think the point at which we differ is that I actually prefer the "Oh #&@$ Solution". Part of it is to avoid building tools that I never end up using. But even if I do use a tool a lot, I would still rather slow development later rather than sooner. For example, I'm the only engineer, building an admin tool means product development stops, whereas if I wait until we've hired another engineer it means it only slows down by 50%. Or, if we only have a few months of runway, it's much more valuable for me to work on things that increase revenue or decrease costs in terms of actual dollars than things that make the company more efficient. Obviously these are contrived examples, but the general theme here is that time now is more valuable than time later. So the further into the future something is expected to pay off, the more suspicious of it you should be.

123pie123 4y ago

It depends... I loved building tools and did it to get better/ faster at writing scripts and/or for fun eg trying to solve puzzles. I would try and write tools/ scripts for anything This helped me to get faster at writing tools - to the point where I automated a large porportion of my job - allowing me to spend more time on working on the stuff I liked - leading to me moving away from Admin

simonw 4y ago

This is why it's great to have a loose framework for admin tools from the very start - I usually use Django so I almost get this for free. Building an authenticated admin UI for something is a lot of work. Adding a "see most recent orders" page to an existing admin UI can take just a few minutes, once that framework is in place.

jakelazaroff 4y ago
Yeah, I tend to work mostly within the JS ecosystem, but I’ve used Django before and its admin panel definitely makes me jealous. That said — if I’m just looking at data, it usually takes me a pretty long time to outgrow poking around the database with a read-only user.
- simonw 4y ago
  I built a Django extension for that! Lets me poke around with a read-only user and then bookmark the results to share with others: https://django-sql-dashboard.datasette.io https://django-sql-dashboard.datasette.io

kwhinnery 4y ago

(disclaimer - I work for Retool) This take is correct IMO - it's only worth building a tool if it saves you more time than it takes to develop. This is why Retool exists - if building/changing an admin tool takes about as much time as assembling a Keynote presentation, then the economics of using custom software to solve small problems start to work out in your favor.

syngrog66 4y ago

"Pave the Paths" my own name for this rule of thumb. based on the story about the MIT campus where they put in grass but no sidewalks, and then waited to see what kind of natural trails formed from natural walking and biking. then put sidewalks there