Quality through the lens of Astrophysics

This presentation started out as something I was to show my boss’s boss about my plans for Quality of the company. It’s higher-level than I think it was supposed to be as it is rather hand-wavy and heavily implies that ‘in order to address quality in the company, there are some major cultural issues that need to be fixed first’ so I’ll likely need to come up with a new deck for that task.

But I like how this turned out so rather than toss it away, here it basically a quick peek into my current thinking on stuff.

Wikipedia defines astrophysics as the branch of astronomy that deals with the physics of the universe, including the physical properties (luminosity, density, temperature, and chemical composition) of celestial objects such as galaxies, stars, planets, exoplanets, and the interstellar medium, as well as their interactions.. The parts of that definition I’m choosing to pay attention to are the properties and interactions.

And since we’re on the topic of definitions, the one I am using for Quality these days is value to some person that matters through their relationship with our software or service. Notice how this too has an interaction. This time between people and our product.

A couple thousand years ago, the other celestial bodies were thought to have revolved around Earth (geocentric). A little arrogant, yes, but given what they had to work with it wasn’t too bad a theory I suppose. Only later did we figure out that Earth actually revolved around the Sun (heliocentric). What I propose is that we need a new realignment of how we view the (software development) universe; one where Quality drives the relationships and interactions. A Quality-centric view as it were.

So what are the Major celestial bodies in the quality-centric view? Let’s overlay it with something familiar; our own solar system. Obviously, Quality takes the place of the Sun, and then going out from there we have:

  • The Golden CopyEVERYTHING of value is version controlled. This translates down to versioning everything as something should not be done if not adding to the value of the system? And this means a real version control system. NOT email. Email never has been, nor never will be, a document management system.
  • Developer Tests – The development group needs to do high-volume unit testing. But not just volume for volume sake, but high quality as well. Unit tests written after the fact provide a regression security blanket, but lose some of the benefits of tests written in a TDD manner. The chief ones of which are Evolutionary Design and High Testability. These tests, because they are so close to the Quality gravity well are fast; no disk, no network, no database.
  • Continuous Integration – The CI server is the System of Record. Nothing can proceed on its journey towards release without traveling through here. Both Dynamic (unit, functional) tests are run in this server as well as Static ones (bug patterns, conventions). One of the chief commandments of this new world view is Thou shalt not break the build lest the wrath of something bad befall upon you.
  • Functional Tests – Functional testing is the next body of interest. Manual testing is done through use of mindmaps, checklists and exploration. Manual testing can also be enhanced through use of automation tools like Selenium. Special attention is paid to the Integration points as the tests run via CI by definition are isolated.
  • Monitoring – Once things have been send out, probes need to be installed so that log files are monitored intelligently as well as the general health of the application though use of heartbeats. The physical host hardware and OS cannot be neglected either. They play an important, if silent, part of the quality relationship.
  • Support – It is important to recognize at a very deep level that client relationships to not end at launch time. Support needs to be Proactive, Ongoing and Timely.

Those are the major bodies, but there are also smaller ones that we need to be concerned about. These ones are not in fixed orbit and tend to cross through the paths of the major ones. Comets for instance.

  • Be Awesome – Being a Good organization isn’t really a worthwhile goal, or achievement. What you should be aiming for is an Awesome organization. And how do you do that? You start by doing one thing really well. By doing that, you will care. Trustworthiness and joyfulness will fall out of these two as those who don’t care or are not on-mission will leave. (One way or another.)
  • People – Everyone in our solar system: has the the right skills, that are kept up to date and are working on the right things. Software development is not a career for people who don’t want to learn every day.

But what about the Physics of our Quality-centric view of the universe? The actual glue that keeps all the Major bodies in their orbit, and the smaller bodies circling their way around those?

  • Communication – Without Honest, Open communication, both within the organization and to the world outside it, then the whole thing devolves. Planets fall out of orbit, comets explode in the atmosphere scorching all life, etc.
  • Timeboxes – Time-travel has not been invented (so far as I know) and so we can’t predict the future. We can make a pretty good guess at what the next couple weeks hold though so short gambles are perfectly acceptable. These gambles need to have a fixed expiration though and have a clear definition of what Done looks like. By having short, defined gambles we can deliver quickly and deliver often, incurring only minimal pain when our gamble was incorrect.
  • Technical Debt – The currency of software development is technology. This means that we can leverage it (incur debt). But like regular debt, technical debt needs to be used wisely as you eventually have to pay it back. Sometimes with interest.
  • Reality – Repeat after me: Bug free software is a myth. Aiming for such a thing is unrealistic, but that doesn’t mean we should not try to do our best. But. Just because all the tests pass, doesn’t mean all the bugs have been found. Nor does 100% code coverage mean we are 100% tested.
  • Data – Code is easy to replicate. The underlying data is hard. Data needs to be Accurate, Timely and of course, Relevant.

So there it is. A 20 slide (Ignite length…) summary of my views on how Quality is Achievable in an organization.

Post a Comment

Your email is never published nor shared. Required fields are marked *