|
|
|
|
|
|
by smoyer
4416 days ago
|
|
|
"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. |
|
|
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.