Flylib.com

Books Software

 
 
 

The Importance of Good Software


The Importance of Good Software

This example goes right to the heart of why software development is important. For me and thousands of others, this is a "mission-critical" application. In most embedded applications we can really ignore the details. If software in a microwave oven occasionally malfunctions, at worst we might overcook something. But we really want the software that manages the ABS braking in our cars to work all the time, along with all the other software systems in our vehicles to control engine performance, traction, ventilation , instrumentation, and so on. Getting interdependent systems like these to function properly isn't easy. And as the number of interacting, distributed software systems increases , the probability of unforeseen error rises.

We want to trust the software that increasingly runs the world we live in, but unless you work within the software development industry, you probably know little about how software is created, tested , or fielded. Software quality varies widely. We hope that higher-quality software resides in the more mission-critical applications; otherwise , disaster awaits.

During the past 20 years , software professionals have made considerable progress toward getting "engineering discipline" into software development. Usually this means a better, more consistently practiced "process." This is a good thing, but it is far from the total solution. While lack of process can often derail a project, good process never created good software.

To make good software, you need good people. And, just as important, you have to manage them intelligently. Software developers, or programmers as we used to call them, get a bum rap: Everything that goes wrong is assumed to be their fault. In fact, most bad software results from less-than -inspired programming coupled with sloppy management. That combination causes software that works most of the time but not always, and that's not good enough.



Hard Rocks in the Swamp

I draw on an experience base that spans a 30-year career in software development management, and 10 years in the trenches before that. During that time, almost everything in our industry has seen pervasive change: hardware, operating systems, networking, languages, tools, and so on. It might legitimately be claimed that software development is the most rapidly changing technical field in existence today. It is for this reason that I have tried to identify the things that have not changed in the past 40 years. For, if some things have remained constant during the past 40 years of tumult, it is likely that these same things will remain constant for the next 40. Knowing where these "hard rocks in the swamp" are located can help us navigate forward, keeping in mind that our field will continue to grow, evolve , and be subject to periodic fads and fashions . The good managers will continue to be successful by integrating the "eternal verities" with the best of the new technology, always seeking balance between the conservatism of proven practice and the risk and reward of innovation.

Fully half my management career was spent at Rational Software, which is now one of the five brands at IBM. Its influence on my thinking was profound, and I profited greatly in three regards.

First, I got to interact with many sophisticated customers all over the world, customers who were attempting some of the largest and most difficult software development projects in a variety of different application domains. These customers gave me insight into key determinants of project success and failure; it was an invaluable database.

Second, I got to manage some of the finest teams of people in my experience, and any success I may have had as a software development manager needs to be ascribed in large part to the talent of the teams I got to manage. A good manager can enhance the performance of a great team, but as a savvy horse player once said to me, "I've never yet seen a jockey carry a horse across the finish line."

And third, I got to interact with some truly great thinkers, people who not only under stood what was working and not working, but who took the time to carefully integrate and articulate their experience. There was a constant buzz within the company, a whirlpool of sometimes competing philosophies as the theoreticians, methodologists, and practical, pragmatic managers engaged in a real marketplace of ideas. I have to admit that never once did one of my colleagues say, "Well, Joe, that may work in practice, but what does the theory have to say?" No, rather I like to believe that we got to the right place by successfully tempering new theoretical approaches with hard-earned field experience.

That is not to say that I was a novice when I first came to Rational in 1986. I had already accumulated lots of scar tissue from the software development wars. I had opinions based on seeing the good, the bad, and the ugly. Rational held out the promise of a bunch of talented individuals who had formed a true team and were dedicated to making things better for their customers. It was very exciting to be part of that adventure for more than 16 years.