- Paperback: 136 pages
- Publisher: O'Reilly Media; 1 edition (December 24, 2016)
- Language: English
- ISBN-10: 149195177X
- ISBN-13: 978-1491951774
- Product Dimensions: 7 x 0.3 x 9.2 inches
- Shipping Weight: 9.1 ounces (View shipping rates and policies)
- Average Customer Review: 7 customer reviews
- Amazon Best Sellers Rank: #217,860 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Building Software Teams: Ten Best Practices for Effective Software Development 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
The Amazon Book Review
Author interviews, book reviews, editors picks, and more. Read it now
Customers who bought this item also bought
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.
About the Author
Joost Visser is Head of Research at the Software Improvement Group (SIG). In this role, he is responsible for the science behind the methods and tools that SIG offers to measure and master software. Joost also holds a position as professor of Large Scale Software Systems at Radboud University Nijmegen. He has obtained his PhD in Computer Science from the University of Amsterdam and has published over 100 papers on topics such as generic programming, program transformation, green computing, software quality, and software evolution. Joost considers software engineering as a sociotechnical discipline and he is convinced that software measurement is essential for development teams and product owners to thrive.
Sylvan Rigal works as a software quality consultant at SIG since 2011 and is advising clients on managing their IT since 2008. He helps clients achieve lower software maintenance costs and enhanced security by prioritizing improvements in software ix design and development processes. He holds a MSc in international business from Maastricht University, The Netherlands (2006). As an active member of SIG’s software security team, Sylvan trains consultants on analyzing software security risks. When he is not assessing technical health of software, he is training Brazilian jiu jitsu, enjoying Amsterdam’s restaurants or traveling Asia.
Gijs Wijnholds joined the Software Improvement Group in 2015 as a software quality consultant in public administration. He helps clients get in control of their software projects by advising them on development processes and translating technical risks into strategic decisions. Gijs holds a BSc in AI from Utrecht University and a MSc degree in Logic from University of Amsterdam. He is an expert on Haskell and mathematical linguistics.
An all-round expert in software engineering and software quality, Zeeger Lubsen started as consultant with SIG in 2008. Having worked as a web developer during his MSc-study at Delft University of Technology he found great revelation in learning about how to build high-quality software. In his role as consultant he now helps both non-technical managers and development teams to understand and grasp software. He finds that developing software is a creative and cultural activity, but also one that needs clear and objective guardrails to achieve realistic goals.
Top customer reviews
There was a problem filtering reviews right now. Please try again later.
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.
BACKGROUND: I've been in the IT industry for 30+ years, half as a software developer and half as a project manager (more recently Scrum Master). My interest in this book was to learn what were the ten best practices that the author asserts will lead to better software. This isn't a book on 'teaming' or interpersonal development between team members. It focuses squarely on the engineering practices of software development, and the thought goes if you're building high-quality software, you've built a team.
I'm in an influencer position in my organization, so I can only influence teams and organizational leaders to aspire to some of these best practices. I'm generally very metric-averse, though, and it's a little overwhelming to read through dozens of metrics to measure how well or poorly an organization is following the ten best practices that the book covers (no one is suggesting that all these metrics need to be used - use just the ones you need to see if you've reached a specific goal).
The book uses a simple GQM model: Goal, Question, Metric. Have a goal, create questions about the goal, use metrics to answer the questions and find out whether you've reached your goal. This is a very memorable technique.
The test best practices are:
1) Derive metrics from your measurement goals
2) Make definition of Done explicit
3) Control code versions and development branches
4) Control development, test, acceptance and production environments
5) Automate tests
6) Use continuous integration
7) Automate deployment
8) Standardize the development environment
9) Manage usage of 3rd party software
10) Document just enough
In my situation, it's difficult for me to immediately put this book to work. If an organization isn't, say, using a continuous integration server, it's a big deal to add that to the development cycle. Same with, say, automate test cases or automate deployment. For me, it's nice to know what are the author's ten best practices, and there may be times where I'll reference this book for ideas on goals, questions and metrics related to one of those best practices, but it's not a book I can really use right now. Seems like the best audience for this book would be people who have an immediate ability to change the development cycle -- a CTO, for example, or an organization's lead architect or better yet a technical steering committee that decides on engineering practices for the firm.
This book does what it sets out to do. That I only gave this book 3-stars says more about my context for using this book than it does about the author's success about doing what he aspired to do.
In a nutshell, this book presents Agile software management principles along with the software quality best practices in ISO Standard 25010. So rather than focusing on subjective "quality in use" standards this text focuses exclusively on "software product quality", which the authors claim is objective. These quality characteristics revolve around maintainability, functional suitability, performance efficiency, compatibility, usability, reliability, security, and portability.
And while borrowing heavily from Agile and ISO 25010, the authors present their own 10 best practices throughout the 13 chapters: Metrics, Definition of Done, Development Branches, Production Environments, Automation, Integration, Deployment, Standardization, Third-party Code, and Documentation. They wrap with a "What's Next?" chapter that gives the reader a final motivation to apply the knowledge.
I recommend this book for anyone involved in the software industry. It's a very quick read and presents a lot of solid knowledge without the loquacious descriptions. The world has no shortage of insufficient software quality, so perhaps this text will help prevent you from adding to it. Good luck.