Errors in Data and Fail Safe Systems

I recently watched a very funny TV show where "the IT guy" said the thing about making the system so fail safe is what if you can't shut it down? It was a funny bit, as the particular system had errors in logic that caused publication of ridiculous name selection, but they couldn't correct them because they never could shut the system down to do proper maintenance. How do we make sure that the data itself is correct and consistent across all of its storage?

Back in the day, to say you were going to test the software before it was released was pretty simple. And I do mean "back in the day".  The first programs had simple instructions to run on computers with limited computing power. Usually, the programs were not sold, but consumed by the same people who were building them.

It is different now. In order to have the power that our current applications and systems have, different groups of people create different pieces that all need to work together. We are in the era of "big data". "Data" can contain instructions that tell the application how to function. The same information can and often is stored in multiple locations, backed up in pieces to ensure it is not lost, at a minute by minute rate, and all of this really should be tested to ensure that it is correct and working.

And we need to consider, as comedy often contains kernels of truth, that in our efforts to be fail safe, we do not ensure that we cannot correct inevitable errors when they arise.

Data Sharing

We hear a lot about "big data". Well, that can just mean lots of organizations have big databases. The reason we need to care about it is data sharing. And that matters no matter how big the data is. When data was first gathered in computers in databases, it was to enhance customer service. You could find things easier when relational databases came along. You had to backup your data in case the computer crashed. Now. Data is a commodity. And we both expect and are fearful of the data sharing between entities. Sometimes on purpose, sometimes by accident. And that data sharing isn't without its mistakes. Because big data doesn't just mean a large database. At this point, companies have lots of databases. Often with similar data, that share.
Here is where quality software comes in. Data sharing involves asking important questions - who owns the data? who is responsible for the data? who cares for the data? When you share something, you have joint ownership. Though in the sense of sharing a cup of tea or sugar or a tool, you may give something to someone, and it is their business what they do with it.
I worry less about big data. That is just hoarding. From a quality perspective, I want the data to be shared only when it should be, in the safest manner possible, as little as possible. Sharing data doesn't necessarily make things easier for good customer service. Only when the right questions are asked, and the sharing is based on understanding the answers.

A New Year - Where is Software in 2017

 In 2017, software in the car is going to expand. Car manufacturers are trying to create the self driving car. It seems pretty important, then, that the software is top quality. What does that mean? Well, it means that when Elon Musk declares that he will have a real self driving car soon, his engineers are probably pretty stressed. Because one of the contributions to poor software is software that is sold with a deadline before it is built. I just watched a show talking about Ford (the person) and Ferrari (the person), engaged in a battle 50 years ago to have their cars win the LeMond 24 hour race. Now Ferrari (the company) had been dominating the race for years, but Ford was determined to best them. The first year, the Ford cars were terribly unstable, crashed and burned (literally). The second year, Ford entered many more cars, put his best engineers on the case, including the famous Shelby, and still, Ford failed. In year 3, however, the cars were finally ready.  And they won. Ferrari, in fact, did not place.

Without a challenge, the best software might not be built. And the self driving car is a very interesting idea. It fits my view that software should serve a purpose. We pin our hopes on a self driving car for less crashes, less congestion, and many other things. So, I look forward to this application of software.

The first self driving cars may fail, and do so spectacularly. But from those failures will come successes. And given time, the best engineers will work out the dangers. It may never be the case that there isn't a 'driver' (see the airlines and the auto-pilot), but that's ok. Software should serve, not eliminate, humanity.

What does 'collaboration' really mean?

Before I left my most recent post, I was working on a cheat sheet to help the internal employees determine which tool to use to collaborate. I was reminded of this effort when I heard this NPR discussion: Online is a puzzle of picking platforms.

Whenever there is a new technology, new software, there will be several different versions, with devotees of one or the other. What is interesting in the current environment, is that typically people are using more than one technology - Twitter and Facebook and Instagram, etc. Companies may use Wiki and SharePoint and different types of instant messaging. Project Management tools build messaging into their tools for ease of use.

At some point, to get to Quality Software, we need to consider whether all these different methods are helping us collaborate, or merely increasing the level of learning required before we can get to collaboration.

And before we can consider that, we need to answer the question: what does collaboration really mean? Is it sharing knowledge? Building something together? Open communication? Because it is becoming a buzzword, it is losing clarity of meaning.

Let me propose what it means, and I'd be interested in your thoughts on it: Collaboration is building something together, whether that be a shared knowledgebase or a piece of software or a team. It requires that each member collaborating, bring something for mutual benefit.

An Application should serve one purpose

Just as in software projects, there is scope creep, so too in applications themselves. And I think that's not useful. Imagine, if you will, back to the early days of Microsoft Word. What was it meant to be? A piece of software to make it easier to create documents. Even more finely, it was replacing the typewriter. What does the typewriter have on it - lowercase, caps, space bar. We create paragraphs, and bullet points. We may change the font.

So, if Word did that successfully, why are there so many versions of Word? Some of it, certainly, is keeping up with Operating Systems, which are refining how we store files, and taking advantage of better hardware. But also - you can add art, it comes with default styles, you can create web pages. As each new version comes along, the menu changes, things move from tab to tab. There are smart keys. And I have to learn a new program. Also, it now links into something called "Microsoft Office". And Microsoft Office, the product, has its own rules, which are imposed on Word. Some of them are fine, but some don't make sense for a document processor.

This trend towards packaged software is especially true for software development, but everyday apps as well. If one more store asks me if I want cash back, to donate to some cause, and any number of another set of questions before I can complete my purchase... well, I guess I'll just carry on, because what else to do?

What these extras do is stop the flow of your activity. As a reminder, we don't HAVE to use software. It is a tool meant to make our lives work better. And that should mean flowing along nicely.

So, when I recently purchased a piece of software specifically designed for a writer - and it is specifically designed for a writer - I was pretty excited. And I get to flow along.

So here's an appeal for Quality Software. It should serve one purpose.

End of a Long Year

I don't know about you, but its been a long year. I have been fortunate to be employed, and like most, trying to do the work of several people. I haven't posted much since I got my job on September 15, 2008, but I've been forever grateful for it.

As the year closes, I thought I'd reflect on what I've learned about Quality Software over the past year, what 'software' means these days, and what I learned while looking for a job in the better years - and whether it even applies to those looking for a job now.

So, what have I learned about Quality Software? Well, I believe more than ever that software is considered quality if the core functionality works well. To achieve that, you've got to have patience in the process. As more and more work is done in software by distributed teams - around the world - in different time zones... as individuals with deep knowledge are 'laid off' or quit or take on so much extra work that they don't have time for answers... patience has become a key to ending up with Quality Software. Patience when we can't buy the extra equipment for that test lab I'd really like to have. Patience when I need to learn about India holidays, Chinese holidays, and just as important when those developers or testers in other countries must wait for us to wake up, wait to go home until quite late at night to get the information they need to do their job. A lot of patience and confidence that everyone wants to do a good job. Without patience, I have found that the design is wrong, the development throws it over the wall (I thought we were past that), testing is spotty, no one documents, and customers are frustrated and unsatisfied. I've learned how important patience is.

So how do we, today, answer the question 'what is software'? Three answers come to mind:
1. I believe my experience at the gas station last year was important. Who is the customer? is not just a question about different people. 'Software' is what controls so many devices and machinery in our world. The phone, the car, the appliances. We need a better understanding of how the software needs to understand what hardware does... did you get that? Anyway..
2. Conversely it is also more than ever, about data. As Wikileaks has shown, we are storing lots and lots of things as data, to the point that in some ways the data could be considered the software.
3. Even customer service on the phone is software. And sometimes the inability of the software to allow intelligent conversations to happen for phone support is extremely frustrating to all of us. If I could fix one thing about software, I'd LOVE to fix that. More later.

Finally, there are several entries in this blog from when I was, somewhat passively in better economic times, looking for a job. Are they relevant now? I think so, if only to remind you of what kind of work you'd like to do and bring that with you to the interview. I was lucky enough to start a job on the very day it all fell apart. I got that job because I understood what I needed to be successful, and so did those who were interviewing me at the time. For those of you searching, I wish you the same luck.

Software at the Gas Pump

It started so simply. If I wanted to avoid going inside, I could use my Debit or Credit card and pump my gas. I usually choose Debit. They ask for the PIN number, it is approved, and I can then select the gas I wish to pump. Only this time, I decided to use my Credit card.

The pump asked for my zip code. I'm in the habit of not giving out my zip code at the various stores that ask for them, so I followed my habit. What followed next surprised and annoyed me. The pump locked. Huh?

And once locked, it didn't matter if you tried to put in a different card or to (metaphorically) say, "I didn't realize, oh software, how important my zip code was to you." No. It was locked. And the only way to get it unlocked was to go into the store and talk to the attendant.

It got me to thinking -- who is the customer? I mean, its obvious the customer for the gas is me. But am I the customer for the software? The software was designed to lock the pump if the proper steps were not followed. I suspect this was in response to earlier software that had a loophole where someone could get gas without paying for it. But it seemed an awfully strong reaction to being bereft of my zip code.

They don't have a signature pad at the gas pump, as they do at the grocery store with its unattended check out lines. But at the grocery store, if I come to a required action, it is clear that it is required.

So, who REALLY is the customer? The gas station and me. Both of us. And this isn't like Microsoft Office where they need to create virtual customers because there are so many different ways to use their products. This is two different, but simple viewpoints with but one function. More and more of our software will be this type of software. And those creating it will only have successfully created quality software if they design software that will satisfy both.

My grocery store is on their third software for the unattended checkout line. I give them credit. The grocery store is aware of this dual viewpoint software, and each change has been made to accommodate one or both. It is clear they will not be satisfied until they find software that supports us all.

It is time for the Gas Pump software to do the same.