I read at least one quote a week like this one from the July 2005 issue of Software Development:
Finding precise and repeatable ways to make design decisions is the Holy Grail or software development productivity. Most tedious taks, such as converting high-level instructions into low-level byte code, are already automated through compilers. What haunt us today are the softer design decisions. If we could only encode those in a tool, we’d save enormous amount of time and debate.
Are software engineers the only professionals continually trying to put themselves out of business? Talk like this undermines the value that software engineers provide. It is precisely these “softer design decisions” that you should be paying software engineers for. It takes years of skill to make these decisions and there is no way to automate them.
We recently hired an architect to draw up some designs for some changes and additions to our home. Never once do you hear architects talk about making house design decisions repeatable and automated. These decisions are exactly what you pay the architect for.
3 Trackbacks/Pingbacks
I wonder if this software engineer also has an MBA. The interesting thing about this quote is that “softer design decisions” seem to me to be something that remains out of the realm of “relevant range” with regard to software function.
Is this an example of trade language combination gone awry?
I don’t think so. But please elaborate on your thinking.
Software engineers are notoriously lazy. We place value in “DRY” – “Don’t repeat yourself” – as one of the guiding principles of software engineering.
Thus, software engineers are always thinking, “Hmm, this problem looks a lot like the same problem I solved last week. Which means I can use the same solution and automate the more general solution.” So when they see themselves making design decisions which seem similar, they often try to think of way to automate it and remove the software engineer from the loop.
The idea of relevant range is a managerial accounting 101 sort of notion. It’s the idea that costs are predictable within a certain range of activities. Measuring production costs in order to understand how it will affect sales revenues is the basic function of the range.
Going back to the original quote, it strikes me that the “softer design decisions” sit outside the realm of the primary function of the program, no? Trying to solve these “decisions” is less probable and may take a lot of resources to do so.
By automating these “decisions” the speaker is trying to bring them into the relevant range in terms of long range cost for a company.
This comment sounds more like good marketing for the individual’s services than anything else. This person is interested in convincing people that it’s all automatable, thus requiring a higher up front cost that can be spread out over many years of automated service.
Post a Comment