If you read the promo for this it seems to disagree with the book somewhat. This is not a book about just process like CMMI or other process oriented themes to make software development reproducible and well documented. In fact the promo text seems to contradict the book's premise that they illustrate in something called the broken window, where one programmer breaks the rules, the standards that the team depends on for consistent quality, and others follow that lead and do the same. The book is more about supporting the development team with the right things to help them succeed as a group. Training for instance to bring the less experienced programmers to work more like the senior programmers your team counts on. To that end I've seen where one guy can cause a lot of damage, a team we had on a program a few years ago, liked to interpret the functional requirements a little differently. He was Asian, I believe he has a bit of a language barrier, very smart mathematically, but stubborn to a fault after months of driving the code architect crazy, he was transferred to a different project, by his contract firm. I was a tester and I tried to show him where he was going wrong, but I had to explicitly show him what and where every time. While not a bad practice overall, not to the detail I had to go to, and he'd argue the point to the end.
One of the chapters is about automated testing, and while the discussion is great, about the need and value, this is often a value added concern. The process is often difficult to develop with some new projects. If it is an typical application, a word processor, database, financial program, web application, maybe automation works up front. In the automotive industry working on embedded software inside hardware devices like engine controllers, body controllers, gauge clusters, shifters, transmission controllers, powertrain controllers etc., you need a lot of hardware in loop, or virtual devices to do automated testing. This typically calls for an investment in a Labview array, or some other capture device for CAN or discrete controls, and then fairly high level process in C++ or C # or linking with products like test stand. The problem is you need talented programmers and test engineers to put that together, and often it's tough to stay ahead of the verification needed for the products release. This means most of the automated testing may be put in place after the first product release, and then you get the time savings and bug finding ability for future releases and updates.
This book is short, and I might recommend it for most development teams to have and maybe even use it as a training tool. It can be read completely in a day or two, and it will help put developers on the same page as long as you apply your own projects details to the mix. Not just for management this book would be recommended to many development teams. Good information and does not beat it to death like more comprehensive texts.
Enjoy fast, free delivery, exclusive deals, and award-winning movies & TV shows with Prime
Try Prime
and start saving today with fast, free delivery
Loading your book clubs
There was a problem loading your book clubs. Please try again.
Not in a club? Learn more
Join or create book clubs
Choose books together
Track your books
Bring your club to Amazon Book Clubs, start a new book club and invite your friends to join, or find a club that’s right for you for free.
Download the free Kindle app and start reading Kindle books instantly on your smartphone, tablet, or computer - no Kindle device required.
Read instantly on your browser with Kindle for Web.
Using your mobile phone camera - scan the code below and download the Kindle app.
Customers who bought this item also bought
Page 1 of 1 Start overPage 1 of 1
From the brand
-
-
Sharing the knowledge of experts
O'Reilly's mission is to change the world by sharing the knowledge of innovators. For over 40 years, we've inspired companies and individuals to do new things (and do them better) by providing the skills and understanding that are necessary for success.
Our customers are hungry to build the innovations that propel the world forward. And we help them do just that.
From the Publisher
Who Should Read This Book
This book is aimed at those involved in managing and steering the software development process. You may be a team lead, a senior developer, a software architect, or a leader of IT projects or software development (such as a Scrum Master). You may have management responsibilities of your own, or perhaps you are advising/reporting to management.
This book will help you and your team adopt our ten best practices for effectively producing high-quality software.
Why You Should Read This Book
Taken in isolation, each of the best practices in the following chapters are wellknown. What is not so well-known, however, is which ones are most important and how to determine whether they are being done in the right way. That is what this book aims to do, setting it apart from other books on software best practices in two ways:
We have selected the ten most important best practices from experience. From our experience with advising software teams and managers, we know what works in software development and what does not. We also measure and benchmark software maintainability for hundreds of software systems each year, so the effects of specific practices such as Continuous Integration or test automation are very visible to us. We explain the most important best practices in a short and simple manner.
We explain how to measure success toward using these ten best practices. Knowing a best practice is only the first step toward getting it right. We provide ways to measure how effectively each practice is being applied, and thus to manage its consistent use.
The Topic of This Book
This book lays out ten best practices for facilitating a team of software developers and enabling them to develop high-quality code. Having high quality code is a great asset: it means lower costs for testing and software maintenance, and faster delivery of functionality. Conversely, software that is insecure, unreliable, or difficult to maintain is a source of developer frustration, delays, and software defects.
The practices address shared ways of working in the team, together with the technologies they employ, the processes they have followed, and the work environment they share. Think, for instance, of using Continuous Integration together with its required technology (see Chapter 7). Another example is standardization of code style guidelines (see Chapter 9). The best practices in this book are well-known, and many programmers may have heard about them during their education or earlier experience. This book puts those best practices in an overall, lightweight approach to manage software quality. The best practices presented in the following chapters are independent of the choice of programming language and the type of software that is being built.
