Don't Automate Technical Administrivia in a Startup(devblog.ailon.org)
devblog.ailon.org
Don't Automate Technical Administrivia in a Startup
http://devblog.ailon.org/devblog/post/2011/08/12/Done28099t-Automate-a-Startup.aspx
2 comments
Also, anything that failing to do will cause problems should be automated. If failure to roll your logs could cause hard drive space to fill crashing your server, it is a strong candidate for automation.
I do agree that any code that gets written should be decided based on business needs and not some sense of alphageekdom.
I do agree that any code that gets written should be decided based on business needs and not some sense of alphageekdom.
There's certainly a plus side to doing administrivia, if it can provide you with implicit feedback in how your doing.
With your logs, if you fully automated everything, you might not spot a problem with the server that you otherwise may not have noticed for weeks.
Let's say you have one task to complete upon each signup to your product - at least you get a real sense of the rate of signups.
(Although in discussing these thing I get the feeling of being pedantic, as I don't know how important they really are - a feeling I get a lot while reading HN.)
With your logs, if you fully automated everything, you might not spot a problem with the server that you otherwise may not have noticed for weeks.
Let's say you have one task to complete upon each signup to your product - at least you get a real sense of the rate of signups.
(Although in discussing these thing I get the feeling of being pedantic, as I don't know how important they really are - a feeling I get a lot while reading HN.)
Of course, it makes sense to know your tool chain as well. This is a problem that could have been solved in 5 minutes with log rotate. Know your tools!
Any time you do math, automate. There are great business-focused tools out there ranging from spreadsheets to CLI stuff like bc, ledger, or R.
Also, automating forces you think through the business process in an analytical way. This will be very helpful if you need to refactor your process in the future.
What I'd argue for is writing a few small tools that do the mechanical, easy to screw up portions of the job (the math, any complex manipulations) and then reevaluate automation as needed.