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.