Chapter 1. Learning from Painful Experience

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 two-credit 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 was 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, many 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.”

About the Book

This book presents sixty lessons about software development and management, grouped into six domains, with one chapter on each domain:

Chapter 2. Requirements

Chapter 3. Design

Chapter 4. Project Management

Chapter 5. Culture and Teamwork

Chapter 6. Quality

Chapter 7. Process Improvement

For easy reference, all sixty lessons are collected in the Appendix, grouped by domain.

I haven’t attempted to provide a complete list of lessons in those domains. There’s so much knowledge in each category that no one could create an exhaustive compilation. Nor do I address other essential aspects of software development, most obviously programming, testing, and configuration management. Other authors have compiled comprehensive wisdom in those areas in books like these:

Programming Pearls by Jon Bentley (2000)

Lessons Learned in Software Testing by Cem Kaner, James Bach, and Bret Pettichord (2002)

Code Complete by Steve McConnell (2004)

Software Engineering at Google by Titus Winters, Tom Manshreck, and Hyrum Wright (2020)

The topics and lessons in this book are largely independent, so you can read them in any order you like without any loss of continuity. Each chapter begins with a brief overview of the pertinent software domain. Then several First Steps encourage you to reflect on your previous experiences with that domain before you dive into the chapter’s lessons. The First Steps invite you to think about problems your teams have experienced in that area, the impacts of those problems, and possible contributing root causes.

Each lesson concisely states a core insight, followed by a discussion and suggested practices that teams can adopt based on the lesson. As you read through each chapter, think about how those practices might relate to your situation. A book icon in the margin, like the one to the right here, indicates a true story drawn from my personal experiences, interactions with my consulting clients, or experiences that colleagues have shared with me. All the stories are real, though names have been changed to preserve privacy. In addition to the true story icons, key points in each lesson description are flagged with a key icon in the margin, like the one shown here.

The Next Steps section at the end of each chapter will help you plan how to apply the chapter’s material to your project, team, or organization. No matter what sort of project you work on, what life cycle it follows, or what kind of product you build, look for the idea behind each lesson and see how you might adapt it to help your project be more successful.

Consider going through the First Steps and Next Steps with a group of your colleagues rather than doing them on your own. At the beginning of the hundreds of training courses I’ve taught, I have small groups discuss problems their teams have experienced related to the course topic (the First Steps). At the end of the course, the same groups explore solutions to those problems, brainstorming ways to apply the course contents right away (the Next Steps). My students find it valuable to include a variety of stakeholders in those discussion groups. Different stakeholders bring diverse perspectives on how certain aspects of the project are going. Combining their perspectives provides a rich understanding of their current practices and a creative opportunity to choose practical solutions.

I hope many of my lessons resonate with you and motivate you to try something different on your projects. However, you can’t change everything you do at once. Individuals, teams, and organizations can absorb change only at a certain rate as they strive to get their project work done concurrently. The final chapter in the book, “What to Do Next,” will help you chart a path to translate the lessons into actions. That chapter offers suggestions about prioritizing the changes you want to put into motion and crafting an action plan to help you get from where you are today to where you want to be.

A Note on Terminology

I will use the terms system, product, solution, and application more or less interchangeably in this book. In each instance, I’m simply referring to whatever ultimate deliverable your project creates, so please don’t read any significance into whichever term I use in a particular place. Whether you work on corporate or government information systems, websites, commercial software applications, or hardware devices with embedded software, the lessons and their associated practices will be broadly applicable.

Your Opportunity

Unless you are indeed among that rare class of practitioners who are already building software as well as software could ever be built, you have some improvement opportunities. We all need to continuously enhance our capabilities: as individual practitioners. We all want fewer scars.

A junior developer named Zachary Minott (2020) made some thoughtful observations about how he outperformed more experienced developers. Minott described an ethic of acknowledging what he didn’t know, systematically going about learning, and putting the new knowledge into practice. He said, “If there is any superpower that I do have, it’s the ability to learn fast and immediately apply what I learn to what I’m doing.” Minott discovered the critical mechanism for continuously wending his way toward mastery of his discipline.

Perhaps you decide to take a class to learn a new skill or enhance your current way of working. While you take the class, the work continues to pile up. It’s easy to ignore what you’ve learned and continue to work as you always have in the rush to get caught up. That’s comfortable, as your current approach has sufficed so far. But that’s not the way to improve.

I adopted the approach of identifying two areas on each project to get better at. I would set aside some time to learn about those topics and try to apply my new understanding. Not every technique worked out, but that way I gradually accumulated skills that served me well.

I encourage you to do the same. Don’t merely read the book; take the next step. Decide how you and your colleagues can apply the practices you read about and what you hope they’ll do for you. Build a list of practices that you want to learn more about and then put them into use. That way, you’ll come out ahead in the long run.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.