Tag Archives: Software Quality

There’s a Fly in the Milk (and a Bug in the Software)

Where “software bugs” got their name — the dead moth stuck in a relay in Harvard’s Mark II in 1947. From https://en.wikipedia.org/wiki/Software_bug

As one does, I spent a good part of this weekend reading the Annual Report of the Michigan Dairymen’s Association. It provides an interesting glimpse into the processes that have to be managed to source raw materials from suppliers, to produce milk and cream and butter, and to cultivate an engaged and productive workforce.

You might be yelling at your screen right now. DairyMEN’s? Aren’t we beyond that now? What’s wrong with them? The answer is: nothing. This is an annual report from 1915. Your next question is probably what could the dairymen be doing in 1915 that would possibly be interesting for production and operations managers in 2019?  The answer here, surprisingly, is a lot. Except for the overly formal and old-timey word choices, the challenges and concerns encountered in the dairy industry are remarkably consistent over time.

It turns out that flies were a particular concern in 1915 — and they remain a huge threat to quality and safety in food and beverage production today:

  • “…an endless war should be waged against the fly.”
  • “[avoid] the undue exposure of the milk cooler to dust and flies.”
  • “The same cows that freshen in July and August will give more milk in December it seems to me… because at that time of year the dairyman has flies to contend with…”
  • “Flies are known to be great carriers of bacteria, and coming from these feeding places to the creamery may carry thousands of undesirable bacteria direct to the milk-cans or vats.”

In a December 2018 column in Food Safety Tech, Chelle Hartzer describes not one but three (!!!) different types of flies that can wreak havoc in a food production facility. There are house flies that deposit pathogens and contaminants on every surface they land, moth flies that grow in the film inside drains until they start flying too, and fruit flies that can directly contaminate food. All flies need food, making your food or beverage processing facility a potential utopia for them.

In the controls she presented to manage fly-related hazards, I noticed parallels to controls for preventing and catching bugs in software:

  • Make sanitation a priority. Clean up messes, take out the trash on a daily basis, and clean the insides of trash bins. In software development, don’t leave your messes to other people — or your future self!  Bake time into your development schedule to refactor on a regular basis. And remember to maintain your test tools! If you’re doing test-driven development with old tools, even your trash bins may be harboring additional risks.
  • Swap outdoor lighting. In food production facilities, it’s important to use lighting that doesn’t bring the flies to you (particularly at night). Similarly, in software, examine your environment to make sure there are no “bug attractors” like lack of communication or effective version control, dependencies on buggy packages or third party tools, or lack of structured and systematic development processes.
  • Install automatic doors to limit the amount of time and space available for flies to get in to the facility. In software, this relates to limiting the complexity of your code and strategically implementing testing, e.g. test-driven development or an emphasis on hardening the most critical and/or frequently used parts of your system.
  • Inspect loading and unloading areas and seal cracks and crevices. Keep tight seals around critical areas. The “tight seals” in software development are the structured, systematic processes related to verifying and validating your code. This includes design reviews, pair programming, sign-offs, integration and regression testing, and user acceptable testing.
  • Clean drains on a regular basis. The message here is that flies can start their lives in any location that’s suitable for their growth, and you should look for those places and keep them sanitized too. In software, this suggests an ongoing examination of technical debt. Where are the drains that could harbor new issues? Find them, monitor them, and manage them.

Although clearly there’s a huge difference between pest management in food and beverage production and managing code quality, process-related pests have been an issue for at least a century — and likely throughout history. What are the flies in your industry, and what are you doing to make sure they don’t contaminate your systems and bring you down?

Data Quality is Key for Asset Management in Data Science

This post was motivated by two recent tweets by Dr. Diego Kuonen, Principal of Statoo Consulting in Switzerland (who you should definitely follow if you don’t already – he’s one of the only other people in the world who thinks about data science and quality). First, he shared a slide show from CIO Insight with this clickbaity title, bound to capture the attention of any manager who cares about their bottom line (yeah, they’re unicorns):

“The Best Way to Use Data to Cut Costs? Delete It.”

I’m so happy this message is starting to enter corporate consciousness, because I lived it throughout the decade of the 2000’s — working on data management for the National Radio Astronomy Observatory (NRAO). I published several papers during that time that present the following position on this theme (links to the full text articles are at the bottom of this post):

  • First, storing data means you’ve saved it to physical media; archiving data implies that you are storing data over a longer (and possibly very long) time horizon.
  • Even though storage is cheap, don’t store (or archive) everything. Inventories have holding costs, and data warehouses are no different (even though those electrons are so, so tiny).
  • Archiving data that is of dubious quality is never advised. (It’s like piling your garage full of all those early drafts of every paper you’ve ever written… and having done this, I strongly recommend against it.)
  • Sometimes it can be hard to tell whether the raw data we’re collecting is fundamentally good or bad — but we have to try.
  • Data science provides fantastic techniques for learning what is meant by data quality, and then automating the classification process.
  • The intent of whoever collects the data is bound to be different than whoever uses the data in the future.
  • If we do not capture intent, we are significantly suppressing the potential that the data asset will have in the future.

Although I hadn’t seen this when I was deeply enmeshed in the problem long ago, it totally warmed my heart when Diego followed up with this quote from Deming in 1942:

dont-archive-it

 

In my opinion, the need for a dedicated focus on understanding what we mean by data quality (for our particular contexts) and then working to make sure we don’t load up our Big Data opportunities with Bad Data liabilities will be the difference between competitive and combustible in the future. Mind your data quality before your data science. It will also positively impact the sustainability of your data archive.

Papers where I talked about why NOT to archive all your data are here:

  1. Radziwill, N. M., 2006: Foundations for Quality Management of Scientific Data Products. Quality Management Journal, v13 Issue 2 (April), p. 7-21.
  2. Radziwill, N. M., 2006: Valuation, Policy and Software Strategy. SPIE, Orlando FL, May 25-31.
  3. Radziwill, N.M. and R. DuPlain, 2005: A Framework for Telescope Data Quality Management. Proc. SPIE, Madrid, Spain, October 2-5, 2005.
  4. DuPlain, R. F. and N.M. Radziwill, 2006: Autonomous Quality Assurance and Troubleshooting. SPIE, Orlando FL, May 25-31.
  5. DuPlain, R., Radziwill, N.M., & Shelton, A., 2007: A Rule-Based Data Quality Startup Using PyCLIPS. ADASS XVII, London UK, September 2007.

 

Innovation Without Maintenance is (Potentially) Cyberterrorism

Image Credit: Lucy Glover Photography (http://lucyglover.com/)

Image Credit: Lucy Glover Photography (http://lucyglover.com/)

On July 8th, Wall Street’s software failed (and the WSJ web site went down). United’s planes were grounded for two hours across the entire US. And this all happened only shortly after China’s stocks mysteriously plummeted. Odd coincidence, or carefully planned coordinated cyberattack? Bloggers say don’t worry… don’t panic. Probably not a big deal overall:

Heck, the whole United fleet was grounded last month too… NYSE is one stock exchange among many. The website of a newspaper isn’t important, and the Chinese stocks are volatile… we should not worry that this is a coordinated attack, especially of the dreaded “cyber-terrorist” kind…

The big problem we face isn’t coordinated cyber-terrorism, it’s that software sucks. Software sucks for many reasons, all of which go deep, are entangled, and expensive to fix. (Or, everything is broken, eventually). This is a major headache, and a real worry as software eats more and more of the world.

In a large and complex system, something will ALWAYS be broken. Our job is to make sure we don’t let the wrong pieces get broken and stay broken… and we need to make sure our funding, our policies, and our quality systems reflect this priority.

Once upon a time in the early 2000’s, I worked as a technology manager at a great big telescope called the GBT (not an acronym for great big, but rather Green Bank… where it’s located in West Virginia).

It cost a lot to maintain and operate that telescope… nearly $10M every year. About 10-15% of this budget was spent on software development. Behind all great hardware and instrumentation, there’s great (or at least functional) software that helps you accomplish whatever goals and objectives you have that require the hardware. Even though we had to push forward and work on new capabilities to keep our telescope relevant to the scientists who used it to uncover new knowledge about the universe, we had to continue maintaining the old software… or the whole telescope might malfunction.

It’s not popular to keep putting money into maintenance at the expense of funding innovation. But it’s necessary:

  • Without spending time and money to continuously firm up our legacy systems, we’re increasing the likelihood that they will crash (all on their own), producing devastating impacts (either individually or collectively).
  • Without spending time and money to continuously firm up our legacy systems, we’re also increasing the possibility that some rogue hacker (or completely legitimate domestic or foreign enemy) will be able to trigger some form of devastation that impacts the safety, security, or well-being of many people.

When we choose to support innovation at the expense of regular maintenance and continuous improvement, we’re terrorizing our future selves. Especially if our work involves maintaining software that connects or influences people and their devices. Isn’t that right, Amtrak?

Your Password as a Mantra to Improve Quality Consciousness

How many times a day do you type in your password? Is it a good password? Is it a password that’s helping you focus the attention of your unconscious on the stuff you want to attract into your business or your life?

A password is essentially a mantra – a “word or sound repeated to aid concentration” – according to the Merriam-Webster dictionary. Typically, it’s just a word or string of characters repeated so that we can access the computing resources we need. People often pick passwords or pass phrases that are already memorable – your dog’s name, your kid’s birthday, a secret inside joke – but since the password is already technically a mantra, I think it can be much better used to create something memorable for your future, or to take advantage of an upcoming opportunity! And if you’re required to change your password so frequently at work (like me, every 90 days) this technique helps you remember your password more easily too.

ISO 9000 p. 3.1.5 (formerly ISO 8402:1994) defines quality as “the totality of characteristics of an entity that bear upon its ability to satisfy stated and implied needs.” In industry, we usually think of a product or a process as the entity, and then we work on improving the product’s quality or improving the effectiveness or efficiency of the process. So why don’t we turn it inside out and think of ourselves as the entity?

That’s exactly what I wanted to accomplish by proposing the notion of quality consciousness, which asks the question: “What are the totality of characteristics of YOU that bear upon your ability to satisfy the stated and implied needs of yourself, your communities, and the organizations where you contribute your talent?”

The three aspects of quality consciousness are AWARENESS of what quality means in a particular context, ALIGNMENT of you and your talents with the problem to be solved and the environment in which the problem and its solution are embedded, and the ability to focus your ATTENTION on the problem or situation that needs to be improved.

ATTENTION is a tricky one, though. Not only do you have to tame the distractions that are gnawing at your conscious mind, but your unconscious mind can grab your attention as well. There are plenty of techniques out there for getting your conscious mind to focus, such as David Allen’s “Getting Things Done” (GTD) methodology. But there aren’t that many techniques that help you focus the attention of your unconscious mind, which is why password-as-mantra is such a useful approach.

Choosing a password-as-mantra can help you focus your unconscious mind on the things you want to achieve in the near term. Why? Because after a while, you don’t even think about entering your password… it’s just part of you… and that’s when your unconscious is actively working with it.

(I’ve been using my password as a mantra for a few years with great results. Other people have apparently figured this out too and are doing it.  I brought the idea up in one of Jeannette Maw’s GVU discussion groups, and it turns out lots of other people are doing it – we just haven’t been talking about it!)

Inspiration Stimulates Productivity and Engagement

(Image Credit: Doug Buckley of http://hyperactive.to)

I saw this on Facebook earlier today:

Jeannette Maw loved this from Jason Fried’s Rework: “When you’re high on inspiration, you can get two weeks of work done in 24 hours. Inspiration is a time machine that way. Inspiration is a magical thing, a productivity multiplier, a motivator. But it won’t wait for you. Inspiration is a now thing. If it grabs you, grab it right back and put it to work.”

“Yeah, exactly!” echoed the little voice in my head. Inspiration is, hands down, the best way to increase productivity.

I know this because I have experienced it. For example, yesterday, I wasn’t inspired at all. I got about a quarter to a half of the work done that I ordinarily could expect to do in a day. The December before last, I was completely inspired and wrote a 200 page book in 10 days. When it catches you, your job is to identify what’s just happened, make use of it, and then enjoy the brilliant time warp it thrusts you into, allowing you to accomplish superhuman knowledge work in compressed amounts of time.

But inspiration is sensitive to environmental conditions. I can’t be inspired when I’m tired. I can’t be inspired when I’m distracted by other things, like reading blog posts on the web or checking for text messages or new tweets on my Droid. I can’t be inspired when I have a cold, and I just want to curl up under a comforter and read. I can’t be inspired when I’m too hot, too cold, or too irritated by a friend or coworker’s antics.

So why, I thought, aren’t we promoting inspiration more in our organizations? Why aren’t we providing programs and environments where people can tap into that natural inspiration and become ultimately productive? And then I realized – we are – sort of. But we call it engagement.

When we are engaged, we are inspired. We tap into that natural flow where we become focused, and directed, and amazingly productive. When we are not engaged, we harbor low productivity, high absenteeism, and contribute to high turnover in our organizations (see, for example, “Great Britain’s Workforce Lacks Inspiration”).

However, I’d also like to propose that engagement is a symptom – a consequence of feeling good and having a high quality consciousness!

Let’s work on the root causes, and focus less on the symptoms.  The root causes of quality consciousness – Awareness, Alignment and Attention – combined with the positive well-being that fuels them, can (and should) be used to cultivate greater engagement in our organizations.

Lessons Learned Must Be Actionable

I spent last week at the 2011 International Conference on Software Quality in San Diego. On Wednesday, I hosted a session of lightning talks, where anyone in the audience can volunteer to “have the stage” for 5 minutes. Some people give presentations with slides, some give presentations without slides, others present ideas or comment on other conference sessions, and yet others lead a short discussion or ask the audience a question they would like to have answered. The best part about lightning talks – and what makes them so fun – is that when the timer (that everyone can see) reaches 0:00 the audience is required to loudly and aggressively clap the speaker off the stage! It’s a great way to get (usually) introverted scientists, engineers and techno-geeks actively involved in discussion.

One of the guys who presented a lightning talk (I unfortunately can’t remember his name) was an ISO 9000 auditor. He shared a little nugget with us that really stuck with me, and I’d like to share it with the rest of the world. His insight came from many of the quality systems he’s reviewed and audited, and he said he noticed this with some of the conference presentations as well. I paraphrase:

Lessons learned must be actionable. So many times I see people present their lessons learned, but they’re not doing anything as a result, or they haven’t figured out how to do something in response to the lesson – they’re not changing their processes, attitudes, or strategies in response to what they’ve uncovered. If it’s merely an insight, it’s just a lesson… if it’s an insight that results in changing or adapting behavior, then it’s a lesson learned!

It struck me that since lessons learned are such an important component of Baldrige assessments as well (via ADLI), organizations that are currently working on an application might also benefit from this perspective.

If anyone remembers this guy’s name, please post it. He was tall and had lots of fluffy white hair.

Maker’s Meeting, Manager’s Meeting

In July, Paul Graham posted an article called “Maker’s Schedule, Manager’s Schedule“. He points out that people who make things, like software engineers and writers, are on a completely different schedule than managers – and that by imposing the manager’s schedule on the developers, there is an associated cost. Makers simply can’t be as productive on the manager’s schedule:

When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting. That’s no problem for someone on the manager’s schedule. There’s always something coming on the next hour; the only question is what. But when someone on the maker’s schedule has a meeting, they have to think about it.

For someone on the maker’s schedule, having a meeting is like throwing an exception. It doesn’t merely cause you to switch from one task to another; it changes the mode in which you work.

I find one meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon. But in addition there’s sometimes a cascading effect. If I know the afternoon is going to be broken up, I’m slightly less likely to start something ambitious in the morning.

This concept really resonated with us – we know about the costs of context switching, but this presented a nice concept for how a developer’s day can be segmented such that ample time is provided for getting things done. As a result, we attempted to apply the concept to achieve more effective communication between technical staff and managers. And in at least one case, it worked extremely well.

Case: Ron DuPlain (@rduplain) and I frequently work together on technical projects. I am the manager; he is the developer. More than we like, we run into problems communicating, but fortunately we are both always on the lookout for strategies to help us communicate better. We decided to apply the “makers vs. managers” concept to meetings, to see whether declaring whether we were having a maker’s meeting or a manager’s meeting prior to the session would improve our ability to communicate with one another.

And it did. We had a very effective maker’s meeting today, for example… explored some technical challenges, worked through a solution space, and talked about possible design options and background information. It was great. As a manager, I got to spend time thinking about a technical problem, but temporarily suspended my attachment to dates, milestones and artifacts. As a developer, Ron got the time and attention from me that he needed to explain his challenges, without the pressure of knowing that I was in a hurry and just needed the bottom line. As a result, Ron felt like I was able to understand the perspectives he was presenting more effectively, and get a better sense of the trade-offs he was exploring.

We had the opportunity to meet on the same terms, all because we declared the intent of our meeting up front in terms of “makers” and “managers”. Thanks Paul – this common language is proving to be a powerful concept for achieving a shared and immediate understanding of technical problems.

« Older Entries