The 5 whys and escaped software defects

At training recently there was some discussion about using the Toyota "5 whys" line to get closer to the root cause of problems. Though Toyota wasn't mentioned. There was a bit of context around software defects and trying to trace back "further", so that in addition to fixing the immediate problem, find and fix more systemic issues that cause some categories of defects to recur.

it got me thinking a bit. In the past such as at SupportSoft there would be discussion and even tracking and measurement of "escapes", that is defects that made it into the field and were first reported by end users. So the error was missed by all of developer testing, code review, test automation, and the QA test team. I'd always found it strange that all of the focus and serious face talk about escapes was on the test team. The escaped defects were always blamed on QA for "missing" them in their test plans.

We never did further analysis to trace defects back further into the development team or individual programmer who checked in code that didn't work. I wondered why was the "blame" always on QA for escapes. They didn't write the code that didn't work. Oh well. I'd say the "pinning" of escapes on QA is from a mentality where quality is something that a test team either adds or fails to add as the final step in a software development process.

With 5 whys, things change in a more positive way. QA becomes a link in the chain, however if there are escapes then the entire team is accountable including original developers who checked in code that ultimately errored in the field. There was a chain of events that led to a runtime error in the field and QA is one link in the chain.

It's a new mentality, different than other places I've worked. Before it was understood and accepted that defects are a natural, unavoidable byproduct of advancing a software program. Development delivers code with defects, QA identifies the most important defects, development fixes them, dev/QA iterations occur, and everything moves forward and code ships to production.

With 5 whys we implicitly reject this silo model that code thrown over the wall out of development is expected to also include defects for testers to identify. With 5 whys and root cause the expectation becomes far higher initial quality out of development, with few or no defects, and far fewer iterations where software is "sent back" from QA to development for rework. Also there's more of a team approach to responsibility for quality of code delivered into production. Defects are owned by the entire team, they aren't something that testers either find or fail to find as the final step. Quality becomes more pervasive and end to end.

Five year plans

I've just done a training session. It was pretty good. The instructor made one point that was interesting. He felt that making a personal where will you be in 5 years plan was pretty pointless.

Thinking about it he's basically right. There's no way to project what will happen that far out and things we have no control over.

I thought back 5 years to September 2011. At that time I was with an UCCDI team as part of the blackberry platform group. The platform was about 1200 people total. since then this is stuff that happened that would have blown any 5 year plan out of the water

One day in fall 2011 we came to work and platform had been dissolved and UCCDI was no more.

Sorry after UCCDI was assigned to some existing team called Devops. It was quite a different culture and I was a misfit on that team despite working extremely long hours during the BB10 death march.

Luckily I escaped Devops and was able to switch to BlackBerry ID server at the end of 2012. That was a pretty good run with bbid server.

By the end of 2013 the Halifax bbid server team was attritioned down from 5 people to 2 and the team was dissolved. Me and the other Halifax guy were assiged as lone remote members to Ottawa sprint teams. In June 2014 there was another reorg and I was laid off from rim. That sure wasn't in the 2011 plan.

Luckily, shortly after rim ended I caught on at CGI and had a successful year and a half run there. Nearshore offshoring for a global European investment bank. It was good to be a senior again and have some status and actually write features.

Then late 2015 I caught on at ResMed where I am finishing up my first year. I also switched from Java to .net. I hope this can continue long enough to review what actually happened in the next 4 years here. It's good here.

Still to my point. from September 2011 to now a number of major things happened any of which would have blown out any 5 year plan. The same is true of a 2006 plan at SupportSoft when the future was to leave for RIM. A 2001 5 year plan at PRIOR could not have accounted for the xwave takeover, going to Core, the SupportSoft takeover of Core Networks.


So I agree in tech 5 years is too long and too much will happen. You just have to be able to adjust and deal with and advance yourself in whatever will unfold.