In 1991 when I started my career, kick-ass machines had 286-processors with 1MB of RAM, state-of-the-art monitors implemented the new VGA standard, and the most prevalent PC database development languages were dBase III Plus, Clipper Summer ‘87, and FoxBase+. Windows 3.0 had just shipped and it possessed a radically improved interface. Developers used standard methodology called structured development that employed software tools known as Computer Aided Software Engineering or CASE. Books by authors like Yourdon and Martin were the Bible of development. My toolset consisted of a dog-eared copy of Meiler Page Jones’ book, The Practical Guide to Structured Systems Design and a copy of EasyCASE from Evergreen Software. I learned about coupling and cohesion. I learned how to decompose problems using data flow diagrams and how to properly create programs and document them with procedure charts. I loved dataflow diagrams because you could tell a complete software story with just four symbols. Procedure charts seemed too similar to the useless flow charts I learned about in high school on my Apple II.
I'm still creating programs in 2007. A lot has changed in the last 16 years. dBase and Clipper have vanished from the landscape. FoxBase+ morphed into the object-oriented programming (OOP) tool known as Visual FoxPro. (Yes, Microsoft still produces this product in case you were wondering.) Most programmers use OOP principles and techniques by default. Procedural is pass�. Many developers who write applications for the Windows platform use languages like Visual Basic, C#, Java, Ruby, Python, Perl, XML, SQL, and the list goes on. Class diagrams, state transition diagrams, and use cases have replaced data flow and procedure charts. CASE has lost its mindshare (although Visio supports the diagrams created in the era of CASE) and is being replaced by the Unified Modeling Language (UML).
The design and development tools that developers use to write software have changed radically. I see the biggest changes in the methods that developers use to actually build the software. Extreme Programming (XP), agile development, Scrum, Test-Driven Development, and open source software have all entered the landscape and are here to stay. Developers use these software development techniques because the process of software development is intermittently flawed. These methodologies attempt to improve the quality and speed with which individuals and teams develop software. The waterfall method of development has shown time and time again that it does not work. It fails miserably when it comes to delivering quality software in a timely manner while meeting the requirements of users.
If I was a betting man (which I am), I would bet that your software development process is broken. Most development shops are in one way or another. In November 2006, I attended a great session at DevConnections in Las Vegas by Travis McElfresh, Vice President of Technology for MSNBC.com and co-presented with his senior architect. They gave a presentation about how the development team at MSNBC.com was having tons of difficulties. They had organized the development team as a pool of resources where all requests received priority based mainly on revenue creation. The result: frustrated departments because some items never received priority as well as frustrated developers because their customers were never happy. Overall it sounded kind of depressing. When MSNBC.com reorganized their development teams they chose to focus on quality and assigned developers to each department. Their focus on quality made sure that all software delivered met high standards. Assigning developers to a department allowed each department to set their own priorities. Departments had control of their own destinies. It took quite a bit of introspection to recognize the shortcomings of their newly formed development team. The corrective actions they made resulted in a total win for the company. I challenge you to have the same introspection with your development team and process. All processes have room for improvement. Manufacturing (which has a better understood process than software development) has to do this all the time. Toyota Motor Corporation makes hundreds of changes to their manufacturing processes annually. They also focus on quality. Toyota's focus on process improvement results in wins for both the company and their customers.
If companies like MSNBC.com and Toyota spend their days focusing on process improvement and quality, why aren't you? Take a look at how well your development process works. If it requires a radical overhaul like MSNBC.com's did, execute the changes sooner rather than wait-you might recognize changes immediately while some changes will take some time. If your process works pretty well, use the Toyota approach and look for ways to improve it.
Rod Paddock
