Dan Creswell on learning from others...
Notice how the monolithic single database architecture hasn’t just confined scalability and performance but the speed with which new features could be added. As an enterprise one might certainly argue that the level of scale of amazon is irrelevant to them but the ability to add features or change? That sounds like something we should all be interested in.This is the number one problem (and yet often the least recognized) in software organizations I am familiar with: the inability to change as desired because of unnecessary dependencies among components.
Software tends to "accrete" (in the worst way) rather than change, because we developers tend not to pay attention to the limitations we are imposing on our systems. The ability to change has to be deliberately designed-in and maintained with extreme attention.
Surprising me, Bill de hÓra apparently disagrees.
That's much too convenient. It's tedious to incessantly see developers or "IT", as groups, get the rap for shortsighted upstream decisions. Plenty of developers understand exactly the limitations they're imposing, but imposed schedule pressures dictate they have little or no choice. This notion that the "business" is the set of stakeholders that are not technical is something to be questioned. Non-technical stakeholders are often worst placed to make decisions about what software should and should not do.If you build bad stuff it is *your* fault. Period.
I've run into too many developers who've not taken the steps they could've to maintain some ease of change. Even in the most difficult of schedule pressures, or whatever, I often find it's the lack of attention on the developers' part that could still make a significant difference.
Related to this is that developers (and especially development managers) tend to be pushovers. I believe this to be so to a large extent because they don't have a high enough regard for the principles of their craft. If you are a developer working with an overbearing "business" person, it's your responsibility to stand up for the system and make the case for the consequences of bad decisions (past and present).
I'm not saying there aren't other problems in the software business. But bad development decisions leading to exorbitant "cost of change" down the road is a huge problem from what I've seen.
3 comments:
"Related to this is that developers (and especially development managers) tend to be pushovers."
Yes indeed, the business pushes hard to do the impossible and these guys push back not at all. I appreciate there's a certain need for job security etc but to not try at all and justify it with "that's the way it is" etc is simply not on.
Dan.
http://www.dancres.org/blitzblog
As Dave Smith commented on the other half of the conversation, it's a slippery slope.
Business should be able to make some decisions that deliberately compromise quality and maintenance in the short term -- there are times when this makes perfect sense.
The problem is, it's a slippery slope in both directions, and it can be tricky to extricate a project from a few "short-term decisions" that last longer than anyone wanted, and getting the balance right between the two ends is the difference between working software, a pile of steaming code, and pristine code that fails utterly to meet the business needs.
"Business should be able to make some decisions that deliberately compromise quality and maintenance in the short term..."
I agree that ultimately its the one with the money that is "the decider".
That is fine as long as the developers clearly explain what they believe to be the cost/benefits of the choices.
Post a Comment