How much engineering is too much?
Jared sent me this blog post which I found quite interesting. The article itself I feel is worded kind of poorly, even right from the title (I dont think anyone really argues about data access any more) but the core concept of “how much engineering is too much?” is discussed with more riguer in the comments.
As an employer who is both supportive and encouraging of the ALT.NET patterns and processes (though there’s little agreement on exactly what those are), I have my own perspective on this issue. While it can sometimes be tempting to think about good software development principles in a vacuum, its also important as developers to remember why we are employed: to build software.
As an employee, we are a cost (the input) that is subtracted from the revenue our employer gains from the software we make (the output). Since for most employees their salary does not vary according to output, the most valuable employees are those that create the most software per unit of time. However, many of us have rightfully rallied against RAD tools as creating unmaintainable solutions that are hard to alter as requirements change.
If you want to be a valuable employee (and chances are you do, since a valuable employee is a well-paid employee) it is still your primary responsible to figure out how you can develop as much software as you can per unit of time. There are really three parts to this:
- Time to market: how long does it take to get the each version ready for deployment, given a predictable incremental approach to requirements?
- Defect rate: defects have two costs: the time to fix them, and the negative impact they have on customer satisfaction.
- Malleability: how long does it take to get successive versions ready for deployment as requirements change?
RAD tools focus too heavily on the first criteria while ignoring the others. Over-engineering focuses too much on the third criteria while ignoring the first one. Conery summarises this as “Simplicity is beautiful”; the best developers will adapt an approach that satisfies all three criteria.