[zaroth]

I think the sad thing here is the idea that code is so expensive and rigid that it's better to slog through something manually, just to avoid the potential of being locked in by code.

I get that sometimes automation sets you on a course of infinite refinement, and you end up investing more money that you should have making some tool cover 100% of all possible use cases. But that doesn't mean you never should have started building the tool, just that you went way too damn far once the "bugs" and "feature requests" came rolling in.

What about the relative costs and risks associated with hiring a workforce for all the manual labor? There's a certain net weight in work that needs to be done, you can shovel it by hand or you can build a machine to help you. How is it not a winning move to hire fewer, smarter people, and empower them with a great software stack?

The goal isn't to build a machine which can do 100% of the work. But whatever the product you sell, you may find you can spend $1 in engineering to reduce the variable cost of delivering that product by more than $1. That's printing money. But to identify these opportunities, and more importantly to prioritize these opportunities and stop working on the BS never-pay-you-back feature, I think you need a project manager who can understand software complexity as well as the business case.

[smoyer]

"code is so expensive and rigid"

For a former embedded systems engineer, this is a hilarious sentiment ... if code you can deploy to your web server two minutes after you've written it is "rigid", I'd hate to see what the current generation of software engineers would think about not being able to "reROM" an embedded device once it was shipped. Even remote-FLASH capabilities are a pretty recent invention.

I think the main problem the article describes is that if you prematurely write software for a perceived problem, you will often be wrong. Writing software will always be more expensive than some number of manual operations, but those manual operations, in the absence of a clear specification and solution, will help you understand the problem domain in ways you wouldn't have otherwise.

[zaroth]

I said 'the sad thing is the idea that code is so expensive and rigid'. I personally don't think that code is particularly expensive or rigid at all, perhaps least of all this type of specialized task automation code.

I guess there are two ways that you "will often be wrong" when automating a specific task. 1) You could improperly or so incoherently automate the task that it actually is harder to for your users to accomplish the task with the tool -- failure to improve productivity of the stated task, or 2) you could successfully automate the task at hand, but either the improvement is too minimal, the task is too rare, or the code cannot be well leveraged when the task needs to change, meaning you never get to break-even on the investment. Both failure modes can be well defended against by a good PM.

Are you saying, that by shipping some automation code, now just by nature of having the tool in the workforce's hands, they are actually less able to understand the problem domain and come up with better ways of doing things in the future?

I think of it a bit differently; the automation of a given approach gets so good that a competing idea that could actually produce a better outcome, but must be done completely manually, is so inefficient compared to the automated workflow as to result in a negative effect, and so it's dismissed. (E.g. you earned an extra $10k on this client doing it your way, but if you used the automated fast-path, you could have just closed 5 more clients at $10k each in the same time).

One way I see this often manifest is the idea that sales always wants to be able to say YES to the prospect / client. If you have a large software automation toolset, you only say YES when the needs match the capabilities, because you lose money every time you work on the special-case clients. I think basically you sacrifice growth rate in this case in order to be a jack-of-all-trades.

[smoyer]

I totally missed "the idea" - it seems like we're in violent agreement!

[greghinch]

A lot of times you are going into existing, older markets where there isn't just a "set of requirements" to be defined by a good PM. Commercial real estate is a great example. The existing processes in renting are extremely case-by-case and specific. You need to go in and first define how you will start to standardize things, and get buy-in from the industry around that process. So you start with the manual, and then automate as you find fit.

This is different from creating enterprise software as a vendor. When you go to one large corporate and they want software automation added around their process, they usually have a process to be standardized. So then you can just figure out and write up the requirements. When you are building a more generalized, SaaS-type product for an industry as a whole, no one yet even has a vague idea of what the process and requirements are.