Learning from Painful Experience
- My Perspective
- About the Book
- A Note on Terminology
- Your Opportunity
This chapter is from the book
This chapter is from the book
This chapter is from the book
I’ve never known anyone who could truthfully say, “I am building software today as well as software could ever be built.” Anyone who can’t say that would benefit from learning better ways to work. This book offers some shortcuts for that quest.
Experience is the form of learning that sticks with us the best. It’s also the most painful way to learn. Our initial attempts to try new approaches often stumble and sometimes fail. We all must climb learning curves, accepting short-term productivity hits as we struggle to master new methods and understand when and how to use them adeptly.
Fortunately, an alternative learning mechanism is available. We can compress our learning curves by absorbing lessons, tips, and tricks from people who have already acquired and applied the knowledge. This book is a collection of such pearls of wisdom about software engineering and project management—useful insights I’ve gained through my personal experiences and observed from other people’s work. Your own experiences and lessons might differ, and you might not agree with everything I present. That’s fine; everyone’s experience is unique. These are all things I’ve found valuable in my software career, though.
My Perspective
Let me start with a bit of my background to show how I accumulated these lessons. I took my first computer programming class in college in 1970—FORTRAN, of course. My very first job—the next summer—involved automating some operations of the financial aid office at my college, all on my own. I’d had two credits of programming, so I was a software engineer, right? The project was surprisingly successful, considering my limited background. I took two more programming courses in college. Everything else I’ve learned about software engineering I’ve picked up on my own from reading, training courses, experience, and colleagues. That unofficial career path wasn’t unusual some time ago, as people were drawn to software development from many backgrounds but had little formal education in computing.
Since that early start, I spent a lot of time doing a diverse range of software work: requirements development, application design, user interface design, programming, testing, project management, writing documentation, quality engineering, and process improvement leadership. I took some side trips along the way, like getting a PhD in organic chemistry. Even then, one-third of my doctoral thesis consisted of software code for analyzing experimental data and simulating chemical reactions.
Early in my career as a research scientist at Eastman Kodak Company, then a huge and highly successful corporation, I used computers to design and analyze experiments. I soon transitioned into full-time software development, building applications for use in the Kodak Research Laboratories and managing a small software group for a few years. I found that my scientific background and inclination guided me to take a more systematic approach to software development than I might have otherwise.
I wrote my first article about software in 1983. Since then, I’ve written many articles and eight books on numerous aspects of the discipline. As an independent consultant and trainer since 1997, I have provided services to nearly 150 companies and government agencies in many business domains. These interactions let me observe techniques that work effectively on software projects—and techniques that don’t.
Many of my insights about software development and management came from my personal project experiences, some rewarding, but also some disappointing. I gained other knowledge from my consulting clients’ experiences, generally on projects that did not go well. No one calls a consultant when everything is going swimmingly. I wrote this book so that you don’t need to accumulate all those same lessons slowly and painfully through your personal project struggles. One highly experienced software engineer who read this list of lessons commented, “Every one of those items has a scar (or several) associated with it.”