How to Improve Software Quality: Tips for Improving Your Development Process and Outcomes
Be Realistic About Your Team, Your Company Culture, and Your Development Needs
Software is long-lived and widgets have effectively infinite lifespans. Broken things tend to stay broken for years, so if our goal is to improve our processes and develop better software we must optimize tactics with our specific organizations in mind.
Much has been written about Software Process Improvement (SPI) Best Practices, but sometimes more can be achieved by avoiding known mistakes than by trying to emulate other successful organizations and their best practices. In this piece, I will look at why it can be more effective to look at what not to do rather than to focus on best practices. To start, instead of trying to copy Google’s best practices, let’s look at the idea that better outcomes might actually be achieved by copying what successful companies like Google ARE NOT doing.
Why? You don’t work at Google.
And, neither do I.
For 99.7% of developers out there, this is an accurate statement (18 million vs 40,000). And for me, it is a 100% accurate statement. By proxy, your colleagues are also not Googlers. And, although everyone at your company is surely above average, it is highly unlikely that the majority of your developers could successfully navigate the complex and often frustrating Google interview process.
So, we don’t work at Google. Does that mean we are relegated to a life of mediocrity?
We may not work at Google (or even one of these “talent magnets”), but we do know a fair amount about how top-tier companies, like Google, develop software. Their methods are considered “state of the art” and as an industry, we often set the bar high by hoping to implement their practices and achieve their success as our goal.
Development Teams around the country dream of being Googlers.
Of course, this is in many ways comparable to your softball league trying to implement the Yankees’ training regimen and expecting to end up at the World Series or at least in the playoffs. If you think this sounds ludicrous then you are correct, it is ludicrous.
Just because it works at Google doesn’t mean it will work for you…
Why then, do we set the bar ridiculously high, despite knowing that the goals we are setting are ludicrous? We want to emulate Google because we see that what they do works. From the sidelines, we have watched their success over the years. Sometimes we catch a glimpse of what it takes, not just at the level of the players, but at the level of the organization, for Google to innovate, lead, and succeed.
Google doesn’t host open spring training or publish a “spring training guide.”
We can observe Google from the outside, but most companies and their business analysts, quality assurance teams, and software developers don’t actually get to see inside Google. For those of us that are not Googlers, we never truly get to see how the machine works from inside of Google. We are not in their meetings and we don’t get to watch how the support structures put in place play out.
All we see is the final score, which generally looks pretty good.
People like to study Google and give presentations on their successes, encouraging us to try to replicate Google’s success. And let’s be fair, on one hand, this is a great idea. At the same time, what if we try to implement these “best practices” and they don’t work? Do we keep trying and devolve into insanity.dev? No. What I advise is that instead of looking at Google’s best practices, we should instead look at what not to do. Learn from development team failures.
The Pragmatic Solution
The pragmatic solution is actually to start looking at successful companies that also do software but that are not software companies. We should then look not only at these companies’ successes, but we should also identify what we can learn from their failures.
Working with the People we Have
Your company’s real path to success is to figure out how to work with the people already on board in the organization. We can’t work like Google when we are not Google. And we shouldn’t necessarily borrow ideas from the companies that have their pick of the talent pool when we work at companies made up of everyone else. This doesn’t mean our people are inferior, but it does mean that they are our unique to our company.
We need development and project management plans that work for REAL people, for OUR people.
Brooks and the Surgical Team
This brings us to one idea that has been around for a few years, but that is often overlooked. In The Mythical Man-Month, Brooks talked about the surgical team approach. This approach takes finding a good developer or tester and then supporting this individual with a team of other staff. Brooks bases this technique on the idea that out of a set of semi-random set of developers a few of them will be 10 times more efficient and effective than the others. Given the fact that the average company has not developed Google hiring practices, it quite likely that your company will align with Brook’s numbers and a handful of your developers will have a work history demonstrating that they are more effective than their peers.
The surgical team is inherently a non-egalitarian system…
Should the few developers that have proven track records, lead “surgical teams” and how would this create an opportunity for your company to improve outcomes? For better or worse, the surgical team is inherently a non-egalitarian system that embraces the view that developers are not created equal. Instead, it focusses on building a team around your best contributors and then supporting it with the rest of the staff.
Chances are that some people will not be willing (or able) to play second fiddle to a coworker they used to be equal with, and eventually, they may need to be replaced or given a different role. In general, however, management is never easy and this is a structure that exploits and plays the hand you’ve been dealt.
Playing the hand you’ve been dealt
The reality is that most of us don’t work at Google, but instead with your average little league aka small or medium sized company. Most of us don’t have our pick of staff, we don’t work necessarily with the best and brightest. And to be honest, you and I may not fall into the category of the best and brightest ourselves. However, this reality does not mean that we won’t be successful. There is still much we can do to develop effective procedures and processes, and develop our talent to maximize the skills and the resources that we have at hand. What we can learn from Google may indeed be of value to our teams, especially if we are able to avoid the same mistakes and pitfalls that Google has learned to avoid.