While some may argue that TDD, BDD, SRP, ahderence to SOLID, use of Patterns, and many other development practices and principles are critical to achieving great software, these all seem to miss some core truths.
Most Software Has Not Been Developed This Way
Yep, sorry to disappoint, but the vast majority of software in production in the world today has had none of these principles and practices applied. Some of the software may have had some of these practices applied - but it is (I would guesstimate) an incredibly small percentage.
And despite that (feel free to tell me I'm wrong) fact, most software works and continues to work. It processes your taxes correctly, makes sure your airplane doesn't blow up on take off, scans your body for cancer, lets you bill your customers, tells you what you are doing tomorrow, and lets you keep in touch with friends and family.
Most Software "Mistakes" Are Not Development Practices
Steve McConnell, he of Code Complete and Rapid Development fame (books everyone in development or management should read) has just published his "Software's Classic Mistakes" list for 2008, and none of these things we developer's like to refer to as "best practice" or "the right way" feature on the list - not in their specific forms, mnor even in their general forms.
In fact - all of the classic mistakes (which cause software projects to be delayed or fail) are process mistakes, they are failures of people, not of coding constructs and practices.
- Unrealistic Expectations
- Overly Optimistic Schedules
- Shortchanged Quality Assurance
- Wishful Thinking
- Confusing Estimates With Targets
- Excessive Multi Tasking
- Feature Creep
- Noisy Crowded Offices
- Abandoning Planning Under Pressure
- Insufficient Risk management
We can certainly look at this list and see how Agile, Lean and similar processes can help alleviate many of these, but where do you see "TDD", "BDD", "SOLID" or even "Automated Testing" resolving any of them? The closest we will come is to see "Shortchanged Quality Assurance" as being ticked off the list, but this still doesn't remove the need for real QA on a project, and real QA people.
While as developer's we see great value in many of these practices, we need to admit that we are actually a very small part of the equation, and sometimes developer myopia sneaks in - we think that what we do at a code level matters, substantially more than it does in the grand scheme of things.
By all means, apply and practice these things that create "quality" software, but bear in mind, there are much bigger and more important problems to resolve too.
Or to paraphrase (and bastardize) the Agile manifesto: While we see value in software patterns and practices, there is more value in solving process problems first
10-05-2009 1:07 PM