Tag: QA

Fear and Software

Several years ago, as a consultant, I had the opportunity to work with a client on modernizing their Quality Assurance processes. At the time, I was at the phase of my career where I viewed QA as just ‘testers’. They were sort of secondary characters in a play that starred programmers. Like the ponies in the Lord of the Rings. Important, sure, but they didn’t get their own swords or anything.

So I took a deep dive in to Quality and started at (close to) the beginning, with W.E. Demming. He was one of the first Quality gurus, and became known for his work in Japan following WWII (he has a wikipedia page). The one thing that really resonated with me from researching him was his idea that you had to drive out fear from engineering. At the time, I was still in the ‘bugs are bad’ phase, and because of that, made all the classic mistakes in programming. I wasn’t good at testing my own work, and wasn’t particularly good at telling our testers where to look for bugs. I also viewed testers more as impediments to my amazing software being released than as allies. Continue reading “Fear and Software”

The Incident Pit

I’ve been reading Alastair Reynolds‘ work since I stumbled upon his short story ‘Galactic North’ in an anthology in 2000. His work is awesome and interesting, and one thing that has stuck with me as an engineer is the idea of an ‘Incident Pit’ from Pushing Ice.

When I went back and googled it, it turns out that this concept has a whole wikipedia page about it (albeit a short one). It’s worth checking out. TL;DR: it’s when a project or scenario’s incidence of errors begins to rise faster than they can be handled. It’s based in diving, where there are constant errors, and if an inflection point occurs, and error rates grow too fast, fatal mistakes can happen. Continue reading “The Incident Pit”

Vertical Integration

One of the coolest things about Tesla’s business, apart from its success and all that, is the use of vertical integration. Elon Musk does this as well with SpaceX. I think software engineers have a lot to learn from this. We have a tendency to specialize, and it leads to inefficiencies in what we do.

One area of interest here is Development Operations. A common case with DevOps is that the DevOps technicians are shared resources, and developers sort of shrug and assume someone else will set up the Web server, security, load balancers, etc., and DevOps in turn assumes that the developer has taken these same things into account as they wrote their software.

Increasingly granular models of SDLC, which have moved to digestible ‘stories’, have further moved the developer away from the infrastructure and servers. Continue reading “Vertical Integration”