4 ms·

I'm going to go out on a limb here and say that startups should be investing spare cycles in automation moreso than documentation. Do you want a 100 page instal

I'm going to go out on a limb here and say that startups should be investing spare cycles in automation moreso than documentation. Do you want a 100 page install guide or a fully automated install script? Which one is more likely to be kept up to date? Which one is more likelybto have people notice it's out of date and fix it? Documentation is helpful, but automation is a force multiplier.

0x445442 3y ago
It’s not just startups. I’ve been working in “The Enterprise” for 28 years and with one or two exceptions, my time would have been better spent automating internal processes that were documented than working on the actual product. And by better spent I mean the money saved in person hours manually and many times errantly repeating tasks that could have been done by software, exceeded any revenue generated from the product software I was working on.
Maxburn 3y ago
Excellent point. Even as a non developer we are automating things like deploying databases for a application and complete system backups. We pay for that app to be developed but it pays off 200x once it's deployed and realized across all the like systems we manage.
Multicomp 3y ago
I write automation constantly as my full time job. Documentation of how to do processes manually is definitely ripe to be automated. But what parameters are available for the automation? Where does the automation live? How do you diagnose and improve when the automation breaks? Why did we even make this automation in the first place? These sorts of questions are ripe for documentation. Most How style questions can be automated in one form or another. But the business process behind the automation, the context and domain knowledge around the autmation, for the humans who did not personally code it, documentation has major benefits that I think we as an industry don't value enough.
- marcosdumay 3y ago
  > But what parameters are available for the automation? A case of non-automatic automation :) Actually, there's nothing wrong with that. Many things are best left that way. It's just an interesting oxymoron. And it's also interesting the fact that yours (and I'm sure many other's) mind jumped directly into it. Automatic automations also exist. And those require a complete different set of documents. But anyway, they are important because the "how do they work", "how do we fix (or improve) it", and "what can they do" are trivial to deduce from a working artifact. Those are not questions you usually want to answer with text.
Groxx 3y ago
When the automation breaks, and it always breaks: gimme that 100 page doc please
dimal 3y ago
Having just experienced a startup that attempted to do what you suggest, I will say that in this case, it did not work. First of all, there is so much more institutional knowledge to document than just installing something. Second of all, the first step in automating something complex is to document what it is to document. If there is no documentation for the system architecture or how to solve common problems, everyone on the team wastes cycles solving problems that others already have, and doing it in different ways, so the codebase becomes an inconsistent pile. Documentation is truly a force multiplier. It allows an entire team to learn from the experience of a single person, and that person can help the others passively and asynchronously.
Capricorn2481 3y ago
> Do you want a 100 page install guide or a fully automated install script Is there an example that actually happens? A system requiring 100 pages of documentation just for installing is not getting done in a single script

0x445442 3y ago

It’s not just startups. I’ve been working in “The Enterprise” for 28 years and with one or two exceptions, my time would have been better spent automating internal processes that were documented than working on the actual product. And by better spent I mean the money saved in person hours manually and many times errantly repeating tasks that could have been done by software, exceeded any revenue generated from the product software I was working on.

Maxburn 3y ago

Excellent point. Even as a non developer we are automating things like deploying databases for a application and complete system backups. We pay for that app to be developed but it pays off 200x once it's deployed and realized across all the like systems we manage.

Multicomp 3y ago

I write automation constantly as my full time job. Documentation of how to do processes manually is definitely ripe to be automated. But what parameters are available for the automation? Where does the automation live? How do you diagnose and improve when the automation breaks? Why did we even make this automation in the first place? These sorts of questions are ripe for documentation. Most How style questions can be automated in one form or another. But the business process behind the automation, the context and domain knowledge around the autmation, for the humans who did not personally code it, documentation has major benefits that I think we as an industry don't value enough.

marcosdumay 3y ago
> But what parameters are available for the automation? A case of non-automatic automation :) Actually, there's nothing wrong with that. Many things are best left that way. It's just an interesting oxymoron. And it's also interesting the fact that yours (and I'm sure many other's) mind jumped directly into it. Automatic automations also exist. And those require a complete different set of documents. But anyway, they are important because the "how do they work", "how do we fix (or improve) it", and "what can they do" are trivial to deduce from a working artifact. Those are not questions you usually want to answer with text.

Groxx 3y ago

When the automation breaks, and it always breaks: gimme that 100 page doc please

dimal 3y ago

Having just experienced a startup that attempted to do what you suggest, I will say that in this case, it did not work. First of all, there is so much more institutional knowledge to document than just installing something. Second of all, the first step in automating something complex is to document what it is to document. If there is no documentation for the system architecture or how to solve common problems, everyone on the team wastes cycles solving problems that others already have, and doing it in different ways, so the codebase becomes an inconsistent pile. Documentation is truly a force multiplier. It allows an entire team to learn from the experience of a single person, and that person can help the others passively and asynchronously.

Capricorn2481 3y ago

> Do you want a 100 page install guide or a fully automated install script Is there an example that actually happens? A system requiring 100 pages of documentation just for installing is not getting done in a single script