3 ms·
Surely it has nothing to do with the buyers of our goods and services insisting that the problem they need solving is unique, so trivial it should be done yeste
by kod 10y ago
Surely it has nothing to do with the buyers of our goods and services insisting that the problem they need solving is unique, so trivial it should be done yesterday, and so clear that they dont really need detailed written specifications? To say nothing of IP concerns making it difficult to actually reuse solutions.
- TeMPOraL 10y agoYou hit the nail on the head. If customers/bosses actually figured out what they want before coming to us, it would be simple to write a perfect solution and/or reuse some existing general product to fulfill their needs. As my experience says, however, the requirements keep changing in parallel to the code. In other domains this tends not to happen. When you're in the middle of constructing a beam bridge, you don't get an architect suddenly deciding it should be a suspension bridge instead. Now I'm not saying iterative development and discovery is bad - it's not. But, with iterative development, you treat steps as throwaway, and you don't commit to deadlines. Something the bosses / customers don't understand. You can't have it both ways.
- ArkyBeagle 10y agoArchitects wield cost for requirements changes like a razor sharp sword. "...you treat steps as throwaway, and you don't commit to deadlines." Just that. For cost reasons. Prototypes are like football practice. Production code is like a football game. There is a difference.