BTIM - Rapid Development

 Books that Influenced Me

Rapid Development by Steve McConnell

This book changed my life. After struggling with the software portion of my project (and watching it continue to flounder after I left), reading this made it all clear. It's available thru Amazon for cheap, especially if you can tolerate used books. This is one of those books every manager with a software-containing project needs to have on their bookshelf. 

Yes, I know, it's a big book, and it has 650 pages. The good news is that you only need to read the first hundred pages of it: Chapters 1 thru 5. The rest of the book is supporting material that explains in detail what the first part talks about. If you read a chapter each month, you will be done before you know it, and will be a lot smarter.

Don't let the book's title fool you. It's not about some trendy new way of doing things faster. It's about doing things the right way, which is the faster way to successful software-related projects, embedded or otherwise.

Chapter 1: Welcome to Rapid Development is a four-page intro to the book.

Chapter 2: Rapid Development Strategy outlines how rapid development works.

Chapter 3: Classic Mistakes talks about mistakes everyone will make if they are not paying attention. It outlines a list of 36 classic mistakes that can/will kill a project. If you want your project to be successful, you need to avoid these mistakes. If you don't have time to consider this, you're going to fail. 

Chapter 4: Software Development Fundamentals walks the reader thru the world of Software Development. One of the most important figures in the book is Fig. 4.3: Quality Assurance Fundamentals.

It's not intuitive at first; conventional wisdom would say that it should take more effort/time to remove more defects. After all, it takes some finite amount of time to remove each defect, so removing more should take longer, right?

The reality is that when you have a good process (and follow it), you will avoid, detect, and eliminate errors and flaws earlier in the process, which has a very significant time savings because defects found early do not continue to generate/propagate more defects. The better your process is, the faster you can develop software! 

This is hard for non-believers to swallow, as a good process might have more overhead than they are used to, such as requiring static code analysis and unit testing before code is merged. This is no different from what small businesses complain about when they have to put an engineering change management system in place. Who has time to keep drawings or bills of material up to date?

I consider Chapters 1-5 a must read for anyone in the management/leadership team that will be over a project involving software. Having the knowledge in this book will enable you to ask the right questions and keep your projects on the path to success.