Unfamiliar

Hello again

I didn’t write all weekend or yesterday; Monday for those of you on the other side of the dateline. It’s not that I didn’t have thoughts of writing, it’s just that my thoughts didn’t become something I felt was good enough for this blog. Again, quality exists everywhere.

Anyway, today I want to talk about the milk in the fridge here at DWS. “Milk?” I hear you say; yes, milk.

Here at Quality in Software, anything can inspire a talk about quality, even milk. Anyway, enough of this ranting and on with today’s post…

Last week, I think it was on Thursday (5 days ago), a 1 litre carton of milk appeared in the upstairs fridge. What is odd about this is that we always have either a 2 litre or a 3 litre milk bottle. So what does it mean to software quality?

You see, no one has opened this poor carton of milk. It has been left there while bottles after it have been opened, emptied and replaced. So why has this poor carton of milk that sits faithfully in the fridge not been opened and used?

It reminds me of how people often don’t use great features in software. Often, great features in software can sit faithfully unused in our products while some common-place feature gets used again and again, even if it does mean more effort on the part of the person using the software. The question is why?

People are habitual beings. They tend towards the familiar and often avoid the unfamiliar. So does that mean this poor carton of milk in the fridge and the great features in software all go unused largely because they’re unfamiliar to their habitual human users? Yup! It does.

Now, I know not everyone is so habitual as this but I only comment on the results I see. And yes, I am one of these habitual users, which is why I can say that when I look at that poor carton of milk, I think, “Someone must have bought it for themselves and simply haven’t taken it home yet.”

One of two things will happen. Either people will continue to avoid the unfamiliar until the unopened milk goes bad and the great features of software get removed, or, just their constant “being there” will provoke a certain level of expectation, of familiarization. Either way, the milk won’t always be there: it will get consumed or thrown away. Now, while you’re thinking of how much of a waste this is while children go hungry in other lands, remember this is a software quality blog, not a human rights blog but I can understand your thoughts on this line.

Anyway, the idea from this is to be careful when adding fantastic features that will change the world. If they aren’t familiar to people or use basic principles that people already know, they will avoid it. It’s not because it’s bad or it doesn’t work, it’s just because it’s unfamiliar. When you do your designs and review quality, try considering the 1 litre carton of milk in the upstairs DWS fridge and present your feature in a way that is familiar to people.

Kind Regards
Glenn

p.s. no cartons of milk were wasted in the writing of this blog.

Retaining Quality on an Easy Friday

Ah, it’s Friday, the end of the working week! It’s always fun coming up to a Friday as it means a great opportunity to take my fiancee Jenna out on a date and not have to worry about going home in time to get up the next morning.

Tonight, DWS is having a social party. It’s to celebrate the recent coming together of DWS and SDM. For those of you who don’t know, DWS is the company I work for (http://www.dws.com.au).

Anyway, if you know me, you know that everyday events make me think of software industry topics; quality, good design, concepts, etc. Fridays are no exception.

Most Fridays, I tend to take it easy. It’s casual day at DWS and many other places too. I’ve been working hard all week, trying to get things done and now is a time for me to sit back and relax as I finish off all the things I’ve been doing throughout the week. Many times, however, the tiredness I have felt through the week affects the effort I can put in to things. Although I’m tired, it doesn’t have to affect the quality of my work.

Being aware that I’m tired allows me to take things slower, add more checks, and follow a personal process more rigorously. That way, I ensure that my work remains at a very high level. It’s often handy to look at other things around the office and in our lives that add to our stress levels. For instance, if traffic is pretty bad, you’re likely not in the right frame of mind when you first walk in the door, etc.

It’s often helpful to remember these kinds of things too when in groups. Everyone experiences the world differently and may end up not being at their best. Often, these can be reasonably predicted: it’s Monday morning, it’s Friday afternoon, the company just had a big launch of a product the night before, or someone simply says they’re not at their best. This is when our software engineering processes are most useful.

Consider what your software engineering processes are, not only at a corporate level but also at a personal level. Remember, don’t stress yourself with mindless process just for the sake of having process but make sure it works and adds significant value.

If you already have processes in place, either corporately or personally, take the time today to see if they’re working for you. Things to think about are:

• Is the process more work than its worth?
• Is it flexible enough for my work life?
• Can I do this a better way?
• Could more learning replace this process?
• Are there other areas that I could focus on?
• Has the work I’ve been doing changed since these processes were invented?
• Am I or are we, taking in to account all those times we’re not at our best such as the tired Friday afternoons of our week?

Kind Regards
Glenn

Reviewing Your Documents

Being in the software industry, I often have to write documents. Often, the documents I write are requirements documents or test plans but other times, they’re just for passing on information.

When I was still learning the art and science of software, I read an interesting book called “Introduction to the Personal Software Process”. It introduced me to a whole selection of great ways to increase quality.

Now, I don’t know if you have any formal method of review for your documents. Maybe you do, maybe you don’t. I don’t want to go in to the details of why you should review documents; it’s important to review your documents! Instead, I want to talk about how to improve those reviews.

Back to the book, Introduction to the Personal Software Process: one thing it taught me was to examine my mistakes and look for them in any new work. The idea here is that we’re all different and we all make mistakes but not the same mistakes!

The way it works is that as you do your review, you keep count of each type of mistake you make. Once you’ve finished, just count the number of mistakes of each type. Then, choose two or three types of mistakes and look for those in the next document you write. After a while, you’ll improve and find there are other types of mistakes that you can work on.

So, try it yourself. Take a look at your next document, whether it’s a document under change control or just for informational purposes, and look for your common mistakes. Try building it in to a checklist; I found it helped me!

Anyway, as usual, your millage may vary but have a think and give it a go. Let me know how it works for you, I’d be interested to hear about your experiences.

Kind Regards
Glenn