Shared publicly  - 
The impetus for my question the other day about 'automation skeptics'. Automating is all about reducing the amount of tasks that don't involve making decisions. Sometimes it's just 'pulling levers', sometimes it's redesigning the entire assembly line, but the goal is the same. People are valuable when they make decisions, and I want my coworkers to be as valuable as possible.
Eric Heimburg's profile photoRob Galanakis's profile photo
I think the best counter-argument to automation is fluidity -- both of the product and of the task. On three separate occasions I started to write automation tools for my MMO, only to discover that everything had to change and the tools became completely obsolete, or to discover that the data format needed to expand dramatically and managing the tools became more and more cumbersome until they had to be rewritten.

Programmers have a tendency to automate anything as soon as automation is viable, but you have to weigh the cost based on the likelihood of your automation tools breaking in the next iteration cycle/scrum/version/whatever you want to call it! Automate things you know are very stable? Not a hard call: do it! Automate the new pipeline/format/database you just invented? Much trickier call.
If you build your tools properly, it shouldn't be a big deal. If your automation tools know low-level details about what they're automating, that's a problem- abstract that shit! Then when the data formats and specs change, you have to touch the automation tools little if at all.

Automation of a task shouldn't be treated as a first class system in and of itself. The automation system may be its own system, but otherwise it should always be using other systems.
Completely disagree. You just doubled or tripled dev time of your tool chain by requiring excess abstraction that wouldn't be necessary if you waited a bit. And there is nothing more torturous than maintaining shitty tools with too much abstraction. "Why does this GUI tool write to an XML file that is then converted to a database table?" "Because somebody wanted to double the maintenance costs of adding new fields!"

Excess abstraction is the killer of maintainability, NOT its savior. You have to know what's "excess" and what isn't, of course, but in my experience tools need to be lean and low. Otherwise they won't stand the test of time: maintainers aren't going to bother punching an extra interface through your useless abstraction layer. That will look like too much effort as soon as your abstraction deviates too much from reality.

Bottom line is of you don't understand the problem well enough, and you're automating it, you're wasting time. And it is the norm for programmers to do that very thing rather than just use a damned text editor for a few extra weeks while the details are hammered out. I do it too. Doesn't mean it's laudable.
(These days my work around is temp tooling: usually something like a spreadsheet that can be converted to CSV and processed, as opposed to a full GUI tool. The difference is that the temp tools aren't robust enough for non-devs to use, and are intentionally disposable! But the point is I'm not literally advocating programmers spend extra hours doing manual labor, just advocating that they don't waste time over-tooling prematurely.)
"Why does this GUI tool write to an XML file that is then converted to a database table?" No, the answer is because the person who designed that did a bad job. The right thing would have been going through an abstraction that's responsible for data serialization, not writing directly to the DB, or to some XML file.

Excess abstraction isn't the killer of maintainability- shitty code is, and excess abstraction is one manifestation of shitty code. Good abstraction is how you create both maintainable code and automated systems.

Honestly I'm not sure what you're arguing- people shouldn't program against interfaces that are still under initial development? No kidding- that has nothing to do with automation, it has to do with shoddy programming practices.

That you shouldn't automate something if you don't understand the problem? No kidding- that has nothing to do with automation, it has to do with shoddy coding practices.
The xml->database example is just trying to put it in more concrete terms. But it's a very real, very common example: it's the traditional unix workflow, where you separate tasks into individual small tools and interconnect them via text files. This is the equivalent of adding extra C# interfaces or whatever that connect steps of your pipeline. Calling it shoddy might be fair, but that goes into a completely separate debate about toolchain-step modularity, which is an interesting topic, but not this topic. :) 

But my point is that it's very common to write tools too soon, and over-abstracting those tools just makes the problem more tragic. In the MMO tools I was referring to, I made a GUI editor for game items. The underlying format was, indeed, abstracted, and it could write to a database or JSON or whatever. But a month later I realized I was never going to use it again: nobody should be hand-editing game items; they all need to be generated by a higher-level tool that munges their attributes across multiple categories. I wasted a week making a really cool, robust, GUI tool for a problem that I didn't understand at a high enough level. I certainly understood what was involved in making game items. That turned out not to be enough; I needed to better understand where game items fit in the bigger picture. 

Premature tooling is not atypical of any large project, in my experience, and it can't be fully avoided in an iterative development process. But it can and should be in the back of your head. Premature automation wastes time.
Premature anything (in coding) wastes time :)
Add a comment...