It appears that I disagree about architecture with a fair bit of my industry. I'm enjoying the though exercise of trying to find a middle ground on my views. It's this post, Mort and the Economics of Unmaintainable Code, that highlights this most effectively.
If I've got it right the idea expressed here is that smart enough people can create frameworks that limit the damage that the "Mort's" of the world can do.
I completely disagree with that, because I've never seen it work. The code that Mort used to write when all we had was plain old CGI and you manually had to parse all your form fields out of the request was just as bad as the code Mort writes today with the web client software factory, or Rails, or any other tool that's out there.
The problem is that programming is not a constrained space. You can hand someone a perfectly simple and reasonable abstraction, and they can completely misunderstand and obliterate it. And it's not free to fix. Because all that work Mort did with the client to figure out what they were building and get it into the code gets intermixed with Mort's terrible abstractions.
Mort will not constrain him or herself to directly use the framework. Let's say Mort is consuming a magical service that works perfectly for his application. (We'll leave aside the question of how an organization that hires Morts so freely to build applications manages to avoid hiring them to build the service). All that code that interacts with the services, while it may be just a tiny, constrained chunk in the grand architectual scheme, will expand to dominate the system.
Because remember human nature. Mort doesn't know he/she is a Mort. The less skilled don't realize they are less skilled. [pdf]. Yes, that very much includes me. :-) Mort will ignore your carefully crafted architecture because he/she thinks they can do better. Or just don't care.
Scaling software is a fabulously hard problem. Unsolveable in the whole I believe, so every solution has to be tailored for the people, the situation, and the organization. Until there's a major technological breakthrough (like artificial intelligence, assuming it's possible), there is not going to be a silver bullet.
Which is why in the end I don't find much value in tools that try to solve it for everyone. The whole simplification of "Mort" doesn't even hold. There are a million sub-varieties of Mort. A talented lead/architect can judge them all individually, and figure out how to put them to best use.
Again, this doesn't mean you just cast aside Mort, they build a lot of (sort of) working software the business depend on, in ways that aren't even obvious. So it's good that people build tools targeted towards them. While ASP.net 2.0 code for a web app from Mort is just as bad as hand-rolled CGI's in Perl from a Mort, there's a lot more value in it.
But code is not now, and has never been "free". Quite the opposite in my experience; the most business value is wrapped up in the worst code. Extracting it takes tons of time and careful effort. I've seen maybe 20-30 examples of reasonably sized systems that tried to constrain the damage that Morts could do, and all failed miserably. I'll need to see a pretty wild streak of successes before my opinion changes.
This is Rob Meyer's weblog, a weblog focused on software development and system administration based on 10 years of experience. Want to explore further? You can find out more me or see the rest of my website.
Wondering if I've written on something in particular? Try searching:
You might want to take a look at some of the more requested postings (as judged by incoming traffic):
Want more? Subscribe to this site
or contact me at rob at big dis dot com.
See my writings on: