Talk About Quality

Tom Harris

Posts Tagged ‘developer

Software Developer

leave a comment »

That’s right, not “development” but “developer”.

The latest issue of The Embedded Muse newsletter—#179 (pdf)—has a reference to an interesting and very different kind of book about C. It’s about the business pressures and the thought processes of C software developers. And a lot more. It’s also long—1600 pages! So download a copy and skim for what interests you:

The New C Standard: An Economic and Cultural Commentary

Some lines that caught my eye, just in the first 100 pages, skimming with the “Page Down” key:

“Software developer interaction with source code occurs over a variety of timescales [for example, those] whose timescale are measured in seconds.”

“The act of reading and writing software has an immediate personal cost.”

“Source code faults are nearly always clichés; that is, developers tend to repeat the mistakes of others and their own previous mistakes.”

“A list of possible deviations should be an integral part of any coding guideline.”

“The following are different ways of reading source code, as it might be applied during code reviews …”

Other related references from the book’s author Derek M. Jones (http://www.knosof.co.uk/):

And somehow related, from another author, Les Hatton (http://www.leshatton.org/):

Advertisements

Written by Tom Harris

May 7, 2009 at 10:07 am

Posted in Technology and Society, Work

Tagged with ,

The Practicing Developer

leave a comment »

I’ve often thought about the advantage that athletes and musicians have over software developers: time to practice—lots of it. Most time is spent in exercises and rehearsals, to produce the best peformance.

In software, everyone spends most of the time producing, with a bit of “time off” for learning new technologies. No wonder perfection seems so far off.

A friend pointed out that Dave Thomas has proposed CodeKata as a way of doing that practice. I read it, and while the ideas look good, I felt there was something missing. The “katas” (formal patterns in karate, and here, in design and coding) seemed somehow schoolwork-like and disconnected from real work. I could only imagine myself “practicing” on assignments where I needed the result, even if for something trivial like importing a bunch of e-mails into SharePoint (more about that another time).

I don’t have an answer today, but the question is much bigger than just finding time to practice in software development. So instead, have a look at these posts and presentations where people are discussing the issue, and see what you think.

Level 5 means never having to say you’re sorry (Jeff Atwood)

Big Macs vs. The Naked Chef (Joel Spolsky)

No Best Practices (James Bach)

Herding Racehorses and Racing Sheep (.ppt) (The Pragmatic Programmer)

Competence is a Habit (.ppt) (David Leach)

Written by Tom Harris

February 13, 2007 at 12:03 pm

Learning for Standards Compliance

leave a comment »

Standards compliance is the unsung hero of modern product usability. It’s how every appliance plugs into any outlet in your house. How gas from any gas station works in your car. There are even standards for the size of the spout so that you don’t put diesel in your gasoline-powered car.

So it comes as no surprise that where that most popular consumer appliance, the car, meets the most modern one, the computer, someone has made a big effort to define a standard. Specifically, the (British) Motor Industry Software Reliability Association has set as its mission, “To provide assistance to the automotive industry in the application and creation within vehicle systems of safe and reliable software.”

But what does that mean to the individual software developer?

Your company buys the standard (it’s becoming popular with many embedded software manufacturers, well beyond the car industry). Developers read it. Maybe there are a few lectures on the benefits and the details. But is that enough?

Fast-forward to a typical work day …

Scenario
 
Developer is in the middle of coding for an urgent delivery or bug-fix, and is confronted with a compiler warning, Lint-type warning, item in a coding standard, or code review comment. (If the company has done its deployment job well, all of these different types of warnings will ultimately be connected to the coding standard.)

What’s really going on for the developer
 
The developer has to understand the warning, standards item, or comment, and then decide:

  1. How to change the code to comply, while not breaking anything else
  2. When to make the change, in order to meet the deadline for the rest of the features/fixes in the delivery

The coding standard is no help for either of these decisions.

Both decisions are context-sensitive, and require guidance (or mentoring — call it what you want) to decide correctly.
 
Implication
 
For the producer, standards compliance includes a learning effort. And in software development, that learning effort can be significant and ongoing. The learning program must not only provide the understanding, but also the people to accompany developers as they confront these two decisions over and over.
 
The first step is participants’ acknowledging this reality. Second is identifying the mentors and allocating their time to read code and provide guidance. Then you can plan a learning program for code quality improvement through standards compliance— a program that works.

Written by Tom Harris

October 15, 2006 at 1:51 pm

Posted in Learning

Tagged with , ,