Follow the Road to Quality - a #PNSQC Live Blog

Greetings friends! It's been way too long since I've done a live blog series, so you are either lucky or unfortunate but nevertheless, I'm here for you these next couple of days ;).

Let's start with a few personal logistics. I'm excited to be presenting twice at PNSQC this year. First, I will be presenting today around lunchtime about "Future Proofing Your Software". The topic is a misnomer of sorts, as I'm not talking about technologically future proofing your code, but anthropologically so. I'm talking specifically about software and aging, as if we are lucky enough, all of us will grow older and get to deal with all that entails. What makes this talk special this year was that PNSQC invited me to speak on this topic. As I've been focused on this topic for a number of years I am really happy to be presenting it.

My second contribution is a workshop I will be giving on Wednesday called "Building a Testing Framework from Scratch". This is a co-presentation with my friend Bill Opsal (cute side note: Bill and I both live in the Bay Area but to date, with the exception of one day, we have only met up with each other at this conference). Hence we decided we should do something together and this workshop is it. I won't be live blogging about it specifically but I will be talking about it in the days following the conference.

Let's get started with the first talk. Michael Mah is the first speaker and true to form it starts out with a technical difficulty (really, what testing conference would be complete without at least one of these happening. Maybe with it happening at the beginning of the program it's a good omen ;) ). One of the factors that we often miss when we are talking about software delivery is how the business itself actually delivers. We spend a lot of time and attention (deservedly so) to make sure that the software we develop works and that we can deliver it on time with the best quality that we can. Do our businesses do the same Often the answer is "no".  Michael points out that when organizations scale up, they expect that there will be an increase in bugs. Double the people, double the bugs. Seems logical, right? Truth is, what really happens is the bug count goes up exponentially (if you double your team, you often increase your bug count by four times).

Additionally, what often happens is we believe that senior developers are smart, efficient and are "the better developers" as compared to junior programmers. Data shows otherwise. Senior developers often have a higher bug count than their junior collaborators. To bastardize a line from The Eagles, "Did they get tired or did they just get lazy?" In truth, it's a bit of both. There's a corollary with pilots. The incidence of plane crashes goes up with more experienced pilots. Again, it seems we tend to get complacent at a certain point and that is when we are at our most dangerous.

Michael is describing a number of companies that have tried to bring Agile up to a scale that is larger than many smaller Agile teams ever experience. To succeed in those larger environments, planning and execution is critical. You need a roadmap and you need to be aggressive with your backlog. Additionally, you have to know your limitations as an organization and be realistic about those limitations. I've gone through this process with a small company becoming part of a larger company and that larger company itself becoming part of an even bigger company. That adjustment has not always been comfortable and it has taken a different way of thinking and executing to get to the point where we can reliably deliver on sprint goals. At the same time, the more often we do meet those goals, the better we get at determining what is real and sustainable. The key to realize is that it's definitely not a one size fits all option but with time and practice, you get better at achieving your goals and objectives.

Speed is great and if you can do it with high quality, that's also great. The bigger question is "do the desired outcomes of your business also match this speed and quality?" In short, it's great we are making stuff the right way but are we making the right thing? Are the features we are developing providing the maximum value for our organization?