The key sections of the article that will interest the software change and configuration management professionals amongst us are in the Processes section. The author clearly identifies that the Process to their software development is the key, not the developers or the code.
1. The product is only as good as the plan for the product.
This section discusses why the "plan" is so important. The design and specification must be done properly to ensure the proper result is achieved with the software development process. When you have an important application, you can't have developers going off and developing code without knowing what the rest of the team is doing or what their end goal actually is.
2. The best teamwork is a healthy rivalry.
This section is about peer reviews and why it is so important to institute this process in your development organization to ensure that the quality of the code is as high as possible at release time to decrease the number of bugs, improve performance and minimize maintenance.
3. The database is the software base.
Ahh, this section is near and dear to my heart. As a very long-time Oracle DBA (yes, I have worked with Oracle since version 5!) my premise is that the database is the most important part of an application. Application tools come and go (VB, .NET, C, C++, Java, etc.) but the database and the data residing in the database is there to stay for a very long time. Most databases will see multiple generations of application types connecting to them, but will remain in place in a similar way to how they started. If you get the database design wrong, you will have nothing but problems; forever. And, the application procedures should be as close to the data as possible (read; "in the database") to ensure data and application integrity no matter which "language du jour" you are currently using.
4. Don't just fix the mistakes -- fix whatever permitted the mistake in the first place.
This is Problem Management defined. There are too many teams that spend time fixing the bugs through a Defect or Incident Management process and not enough teams that spend the time required to properly implement a Problem Management process. Fix the problem/root cause and you won't have to spend as much time fixing the bugs! It is an investment that will pay of 5 to 10 fold over time, but requires a longer term thought process than the short term "fix it now" mentality many shops are forced into.
Conclusion
I think the key item that hit home was this one:
"The most important things the shuttle group does -- carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code -- are not expensive. The process isn't even rocket science. Its standard practice in almost every engineering discipline except software engineering."
I spend at least 50% of my professional life trying to drill this concept home to development teams. Unfortunately, proper design seems not only to be not taught in Computer Science classes, but is actually scorned. "Ahh, don't worry about design, it just slows you down!" seems to be the credo for many development shops these days. I'm glad houses, bridges, medical equipment, etc. aren't built this way!
