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.

Design Patterns by Gamma Helm Johnson Vlissides

I've finally got around to reading Design Patterns after all these years. I've known about the book for some time. I remember back at Core Networks in the early 2000s we switched to Java and kickstarted it by hiring in a Java team from the local market. They would have these what seemed like eerie stand up meetings each day filled with all these pattens they all knew about and constantly referred to.

Maybe, like Java, since that initial burst of excitement it's all just settled in and we just find it handy in our everyday software lives to get things done. It's pretty much expected that anyone in software is familiar with it and I was a bit remiss leaving it this long. I wish I read it 10 or 5 years ago. Well now I have and I'm glad I did.

The book is well written. 23 patterns is just the right size grouped into creational, structural and behavioral areas. The authors favor composition over subclassing. Still they also like abstract classes. A common theme is that introducing one level of indirection can open up powerful design possibilities. In the final pattern, Visitor, they permit themselves to show off a bit with double dispatching, taking the abstract class concept to the next level in an elegant and understandable way.

It's remarkable really this book was published in 1994. The era of DOS and Windows95. Still it's as useful and relevant today to use in C# and Java and iOS as it was then with developing for Win3.1. It shows how well written the book is and the skill of the authors. The authors are truly top notch designers.