Talk About Quality

Tom Harris

Archive for the ‘Learning’ Category

A Path to Software Quality

leave a comment »

What will lead developers (and managers) to start practicing the best of what is known about software development? I don’t think that just being told will do it. People have to learn for themselves. But how? Where to start?

One answer is doing, and learning by trial and error. I’m all for learning by doing, but adding reading to that cycle helps too. The Web makes it a lot easier, if you know what you’re looking for. So I thought I’d share my reading path from this evening. Not just what I read, but the choices I made while getting there.

Google: Because it’s there
Google > more >> : I never clicked “more” before!
Blog Search: Vanity — look for my blog
Software Quality: My topic and profession
What Quantifies Good Software Design: Looked interesting
Quality With A Name: Recommended by first article

Other links I read from there though I came back to James Shore’s page:

What is Software Design?: Shore called it a “famous essay”
(later I found Reeves’ series of 3 articles with update)
Using PDL …: Articles mentioned “PDL”
Clean Code: Args …: Referenced in one of the articles
Design by Contract: Appeared in one of the articles

Does this mean that reading James Shore is the path to software quality?

Well, it’s a path.

More important is to search the web purposefully, find what means something to you, read it, and then try it out.


Written by Tom Harris

July 6, 2006 at 1:52 am

Posted in Learning

Tagged with ,

Work to Learn

with one comment

Maybe the answer for how to lead people — in order to get good products out on time — is simpler than we thought.

So much energy (some even in these pages) spent on figuring out how to fix defects, train people better, and improve quality.

How about this: focus all of your people’s energies on learning (as opposed to production) as the goal of their work, and high-quality production will follow by itself.

Just look around at your best people and ask if it isn’t so.

Written by Tom Harris

July 2, 2006 at 11:47 pm

Posted in Learning, Work

Struggling to Learn Together

with 3 comments

For better or worse, the educational model of the school, particularly of the university, serves as the basis for training and learning programs in the workplace. It is also the model familiar to many new workers, since they have recently come from that same school environment.

One of the burdens schools face is deciding when to attribute work to a given student, in order to use that work to give student a grade. They deal with this challenge through codes of academic integrity.

How do these codes prepare students for, or hinder workers in, exercising a crucial success behavior in the workplace: cooperative learning?

To find out, I searched Google with the phrase “working together academic integrity“.

There were some positive guidelines here and there such as:

  • It’s fine for the group to discuss problem sets, class topics, and so forth. It’s fine to ask others to explain methods and solutions you don’t understand. Together, you can go over the problems several times until you understand. (From University of Windsor.)

But the results also included restrictions such as:

  • You may not give or receive help on the programming assignments, except from the TA or the instructor.
  • You may not show your program to anyone else until after it has been graded.
  • Unless working together on an assignment has been specifically approved, it is not allowed.

Clearly, universities are struggling to say the right things on these issues, and do not speak with a single voice.

But what’s really so hard about the issue?

Time out for some skiing

I’ve only skied once or twice in my life, so each time I was back on the beginners’ slope, taking lessons. Imagine this set of rules posted on a snow-covered wooden sign next to the practice area:

Integrity on the Slopes

In order to ensure that each student is graded correctly and fairly in their skiing lessons, the following rules must be observed:

  • Watch only the ski instructor — no peeking at others on their practice runs.
  • No talking about how to ski, even on breaks.
  • Unless skiing together has been specifically approved, it is not allowed.

Who would pay for ski instruction under these conditions? Who would learn to ski?

A Simpler Idea

Back to academics, or rather, training in the hi-tech workplace, why not just say:

  • Cooperative learning is essential: work with others
  • All sources may be used; if not yours, credit the author

Is there anything more?

Written by Tom Harris

June 28, 2006 at 3:42 am

Posted in Agile, Learning, Teaching

Models of Work and Learning

leave a comment »

Code review has been shown to be 10 times more cost-effective than dynamic testing in finding defects and suggesting fixes. The reason: economies of timeliness — catch the problems earlier and they’re much easier to analyze and fix.

But still, when confronted with defects, what is your reaction: need to fix or need to learn?

If “need to fix” then choose Fagan Inspection for code reviews.

If “need to learn” then choose training.

If both, then choose mentoring and professional reviews.

On a related note, is learning separate from work?

If yes, then establish a good training program.

If no, then establish a good quality mentoring program.

Finally, in a company, who needs to learn?

If you believe that each individual needs to learn, then restrict information about individuals’ skill sets to individuals and their managers.

If you believe that teams need to learn, then make information about individuals’ skill sets available to everyone.

Whatever you do, think about the questions and your responses.

Make sure you choose the path that follows logically from your responses.

Written by Tom Harris

June 28, 2006 at 1:41 am

Posted in Code Review, Learning

Sharing Reflective Learning

leave a comment »

Chrishmorris talks about Reflective Practice and suggests keeping a diary of reflections on one’s work. Even better, perhaps, than writing it down in diary would be talking with others about it, while it’s still fresh in one’s mind.

I work in a multi-lingual environment though everyone understands and speaks English quite well. But worse than speaking different languages is speaking the same words while meaning totally different things.

This challenge is hardly limited to software development.

The problem, though, is that in communication-focused fields such as, say, peacemaking or family counseling, at least people realize that communication might not be happening.

In software development, and in the modern office in general, everyone thinks communication is happening when in fact it isn’t.

The beginning of a solution is regularly starting serious conversations with the goal of explaining (reflecting on) our own experience of a particular activity, and with the assumption that we probably start out using the same language to mean very different things.

When you are convinced, through feedback in such conversations, that the other person has understood you, and vice-versa, then some real learning has occurred.

Written by Tom Harris

June 20, 2006 at 10:28 pm

Posted in Agile, Learning

Don’t Do It Yourself

leave a comment »

"Do It Yourself" or "DIY" for short is a popular way to save money and get things done quicker at home. While few people remodel entire kitchens by DIY, I know I'm not the only one who regularly repairs faucets, or even assembles simple furniture.

But at work, DIY can turn out to be equivalent to another well-known "D" expression: Don't Reinvent the Wheel.

I recently returned to a bit of C programming, in order to familiarize myself with the daily challenges of developers I want to help and support. Developers who remain in C due to embedded platform constraints. I figured that if I wanted to offer this or that tool as a solution to some problem, I'd better try it myself first.

Getting back to C programming meant I needed two things: some source code and a compiler. I found some code I'd written a while back in C++, and decided to rewrite it in C. As for a compiler, why not cl – the command-line compiler from Visual Studio 2005? Not the key part of that comprehensive Microsoft product, but I figured it would do. And of course the Visual Studio editor looked fine too — I could use it to browse my code even if I didn't bother to remember how to set up an entire Visual Studio project.

Merrily I started on my way. Review my old C++ program. Relearn what isn't in C as opposed to C++. Redesign. Write function prototypes in an .h file with some stubs in the .c file. And … compile!

Lots of errors!

No big deal I thought. Just stare at the code, change something, go back to DOS, compile, pipe the error results into a text file, review them, try again. Tiring, and it didn't work.

Rule #1 is hard to follow, but usually helps: leave it 'til tomorrow when you're better rested. All that switching back and forth between windows was tiring. And frustrating when the errors refused to go away.

Next day, by coincidence, a co-worker gave me a copy of a professional source code browser called Source Insight, which he had shown me several months ago. I returned to my task, and was faced with a choice. Go back to looking for the cause of my errors, or take time out to install this new "toy". (Actually, I had known from the first time I had seen it that it was much more than a "toy", but I had never really tried it.)

I installed it. I learned that one could define one's own "compile" command and install it on the menus. Even that it could be told to parse the compiler output and hyperlink between it and the source code. It took me a good hour, especially without documentation for Microsoft's environment variables batch file required for cl to work. But I slowly remembered DOS batch file language, and got it working.

I compiled again, this time with a professional tool. The errors came up, each hyperlinked to the source code. I looked at the first error message, flipping back and forth between it and the source code. I looked up the error C2143 via Google, and got to Microsoft's succinct explanation. Didn't help much.

I stared at the line of code again. This time, though, each element in the line was marked in a different color according to its role in the statement. (Yes, Visual Studio does some color-coding, but Source Insight does much more.) After about two seconds I saw that what I had written was ridiculous: I had used const in place of a #define but had forgotten to use an equals sign to make the assignment.

I fixed it and the error went away.

I had known that Source Insight existed. I had known where to get a copy: from someone who had invested time in identifying an excellent source code browser and editor. But I had tried the wrong kind of DIY — reinventing the wheel — instead of just going and asking for one.

In such cases, don't do it yourself.

Written by Tom Harris

May 29, 2006 at 3:15 pm

Posted in Agile, Learning

Tagged with