Quite frankly all the reach out (or around) in the world won’t change this. All of these listed Architectural Disasters should really be called Management Techniques. In the world of shrink-wrap they should never happen and presumably the market would limit their occurrence naturally but for the great unwashed developing business applications we seldom have the chance to decide these issues. At this point however I can assure all of you young and frustrated programmers that with age comes the wisdom to no longer give a damn. You fight the battles you think you might win and let the Devil take the rest.
So let me ask you this.
If 99% of commercial and in-house software development projects in varying degrees of mudball-itis. Isnt’ there room for competition (in any and all industries) from very well designed codebases? Ultimately won’t well designed #5s truly rise to the top in the marketplace long term? My guess is that no one is really truly doing #5 in very large, commercial products, and so competiors can just “mudball a little better” to gain competitive advantage.
MY gut feel is 10-20 years from now the mudballs will succumb to better competing #5s. But maybe that’s really 100-200 years from now.
My ideal utopian brain is thinking that there is room to really do #5 right on a major project and blow away the compitition who won’t be able to keep up with your ability to adapt an inovate because your layers give you infinite malliability at very little cost compared to competitors. Ah to Dream. /segue And that leads right to Mitch Kapor’s Outlook killing “Dreaming in Code” [insert amazon link here] where you put together a “dream team” and massive open ended budget, and try to draw in the open source community, and 5 years and millions later you’ve got nada.
Maybe it’s not possible.
Yet.
And maybe I should get back to fixing bug #9812 now.
-AP
Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software
"At this point however I can assure all of you young and frustrated programmers that with age comes the wisdom to no longer give a damn. You fight the battles you think you might win and let the Devil take the rest."
Why do so many people confuse “Wisdom” with “Apathy”. Always try and fight exactly one battle you “can’t” win. When you make any achievement there, not only is it satisfying, but it looks impressive too. But if you try to fix everything, you’ll end up exhausted.
The 10 Step Programme for improving Internal Software.
- Find the balls of mud that’ve been around for 40 years.
- Pick one. No more than one. One will be enough.
- Work out exactly what needs to be done, and what’ll be affected.
- Start work.
- Find out what really needs to be done, and what’ll be affected.
- Finish the replacement.
- Cause the original BoM to fail, and then replace.
- Congratulate team
- Take holiday
- Find a new ball of mud.
This will be hard, but the alternative’s “Let the Devil take the rest”. And who wants to be that apathetic?
Thanks, Tom for proving my point. All the steps you outlined are management functions (except for parts of 4 and 6.) If you ARE a manager I encourage you to fight those battles you might win. If you are the coder - learn patience and improve your skill.
There are some interesting parallels here to Jared Diamond’s book Guns, Germs, and Steel(didn’t read the book; saw the movie), particularly about specialization. Shantytowns and their residents are something like modern day hunter-gatherers, in that there is almost no specialization.
Diamond proposes that the reasons that some people end up as “haves” and some people end up as “have-nots” are largely due to the particular geography in which they live. I wonder if there are particular aspects of the corporate environment, like the hunter-gatherer’s physical environment, that lead to specialization and thus further up the ladder of software development evolution.
Maybe you’d be interested in my book of software horror stories that I personally experienced. I am hoping to do a second book that includes everyone else’s worst projects; this particular story seems like a good candidate.
Hi all
After reading the IE blog post, I almost feel sorry for the IE team. They have soooo much baggage now associated with the product! There are thousands of badly-written sites out there (mostly corporate) that work because the users use IE. “Stirct mode” and “non-strict mode”? What the hell are they thinking? But then, how do you improve a browser without breaking all these sites?
The only way forward I can see is to scrap it, start a new product, change the name - disassociate it from IE - make it properly standards based from the start. Just stop developing IE, IT team! Then, after a few years, all those badly-written sites would hopefully have disappeared, MS will dominate the market as usual and they will have happy developers. It’ll be hard to get all those people to adapt to the new product but hey, no pain, no gain. estetik
estetik
estetik
Andrew, cheap materials have NOTHING to do with open source. What a non sense! Cheap and expensive relate to the fact to hire unskilled cheap personel, who doesn’t know what to do with the tools well, instead of having a seasoned architect. Keep the fury for better moments and read carefully next time
If you are in a situation where your peers convince the management to use bad/quick architecture in software, then that is bad. If you can’t convince the management otherwise, you should leave the company, but not the whole information technology business. There are lot of people who believe in good practises, and if they get into same company, then you create good momentum for better times.
We have a ball of mud. We never seriously tested it (our customer did, but their management was seriously whacked about what results were important). A few rollouts turned into several hundred.
New management came in (customer side) who had two pennies to rub together and said “these numbers are whacked - make it work accurately” (fortunately they didn’t say perfectly).
The major problem is that this is an open looped design that attempts to track queued up customers using two points. However, at any time a customer can leave the queue. We get a mostly unique key from the first point, but only “customer here/isn’t here” from the second point. The rest is guesswork, innuendo, and “what if’s”. I’ve tried to point out that without a way to resync our internal queue with real life, we can only have an EPIC FAIL. I’ve been told (in so many words) I’m depressing and we can do it… we just have to figure out how.
The text in this blog MOSTLY is a result of poor planning or design. It doesn’t even address the case where the initial idea was flawed from the start. Many times I have seen clean, elegant code turn into balls of mud because people at the last minute have decided to a) make huge changes in the project or b) keep tacking on more and more crap that exceeds the original design goals.
Chernobyl was NOT an EPIC FAIL because of design - it was best practices AT THE TIME. It was an EPIC FAIL because even when it was determined it was a bad design they continued to use it (much like the reactors we have on fault lines in the U.S. or the Fukushima Daiichi reactors). When we set the parameters to meet the device or the code, not the other way around, THEN you are set for disaster.
You’ve got some mojibake in quoted section number 7;
“suites that the spreadsheets of ‘90s sporting economics demanded.”
Don’t know if this was the case when you wrote it, or when all these nice people replied, but I saw it so I’m pointing it out.
2 Likes