Okay maybe that was mean. But perhaps you have some advice about strategies to avoid these patterns from emerging? Certainly it’s not as easy as “now that you know how to do it, don’t!”
These are all very natural ways for software projects to evolve (“natural” meaning “following the path of least resistance”). After all, every programmer worth his pocket protector should be able to tell that you don’t sell architecture, you sell a product. Clients (in general) don’t give a crap if you spent time perfecting your design, they just want something that works. And in our capitalist system where the money goes to the lowest bidder, there is a powerful incentive to nix the designing and the refactoring and just spin out code until you’ve got something you can hand off.
Now you and I know that time invested in design and test driven development and prototyping and rewriting and so on can save time and money in the long run (“a stitch in time saves nine”), but to an accountant an expenditure NOW isn’t the same as a possible expenditure, oh, somewhere in the future. So how do you strike the balance between “design it perfect” and “git 'er dun”? What methods do you use to keep a project from going down a dark road, or save one that has started that way?
Yeah I guess that’s a tall order for a mere blog post, but that’s what I’d like to read.