Talk About Quality

Tom Harris

Posts Tagged ‘software

I’m in Software

with one comment

When somebody asks me what I do and I say, “I’m in software”, or “I’m in computers”, they usually give me a “Oh, that’s nice,” but it’s clear they aren’t any wiser than before they asked. Why is that such a conversation-stopper? If you’re a lawyer or a doctor, people think they know, and jump right in.

Maybe that’s because lawyers deal with people and justice, or at least arguing, which sounds familiar. And doctors — well, everyone’s been to the doctor. The drama of dealing with people is what gets lawyer and doctor shows on TV, and I’ll be the first to admit that my picture of what they do comes straight from there. Really that means I have no clue.

After a bit of thought, I realize that software is more like art, if that helps.

(Right — saying you’re an artist is like saying you’re in software, only poorer.)

But really, it can help.

The solution to explaining what “I’m in software” means is to realize that software, and software development, is really three very different things. To the software developer, it is code — lists of instructions to make a generic machine behave in a specific way. To people in general, it is invisible: as mobile phone users, airplane travelers, or just people turning on the faucet and getting water, the world is full of things made of plastic and metal that behave or respond more actively than a cup or a pair of scissors. And finally, software development, the activity that goes on in a hi-tech software office, includes a good deal of accounting, scheduling, and event planning.

This triple personality parallels art. When someone tells you they’re an artist, do you think of paints, chemicals, brushes, and canvas? Or paintings on the wall? Or the business of running an art gallery?

I’m pretty sure most people hear “artist” and think of paintings. But the “what the artist does all day”, whether it’s looking, thinking, or carefully mixing paints, is invisible in the painting. We see the painting and know nothing about the work life of the artist.

So being in software, like being an artist, means doing something unseen to materials and creating interactive things that everybody then takes for granted.

Probably the only way forward for more people to understand what’s “in software” is to take them into the studio — the hi-tech office — and let them try their own hand at coding a mobile phone app. Or on the other hand, attending a project meeting.

Say, why aren’t those kinds of experiences available at the local computer or science museum — not playing with the things, but making them come alive?

John Hollar and Grady Booch, are you listening?

Written by Tom Harris

October 29, 2012 at 8:35 pm

Posted in Technology and Society, Work

Tagged with

The Day they Broke the Lever

leave a comment »

We may never know all the details of the recent Toyota failures, because, unlike the Challenger and NASA, Toyota is a commercial entity rather than taxpayer-funded government. And it’s a bit early to be looking for definitive analysis. What we can do, as embedded software developers, is realize what we’re up against, and how it didn’t start yesterday.

When microprocessors first came out the buzz on the news was that soon they were going to be inside everything. I remember wondering what do we need them in everything for? My washer and my microwave oven, for example, worked just fine with a mechanical dial. But I was wrong and now they are in everything.

Much earlier on, complex systems were based on the Six Simple Machines. I can’t say which is simplest, but maybe it’s the lever. What’s important here is that the behavior of the lever is governed by physical properties of solids, which by now are pretty well understood. Push down on one end, and the other end goes up. Exceptions exist: solids can stretch under tension, deform under pressure, and if you push too hard, they can break. Apparently Toyota had problems with this too, in their gas pedal problem and fix.

Technical advances brought hydraulics — based on the properties of fluids and gases. I also remember replacing a brake line on an old car once, and getting to see how a leak in the line leads to spongy braking, and, if I hadn’t been refilling it weekly before the replacement, to brake failure.

In both of those technologies, the basic idea is that the system user (e.g. the driver) pushes on the control, force is transmitted immediately through a physical medium, and the desired effect occurs. Failure modes are well understood and (usually) are prevented.

Now replace the lever with software. No more physical properties: the behavior of the software transmission line is governed by the behavior of people — software developers writing lists of instructions which are translated several times before reaching the hardware. Now you push on the control, and a cacophony of instructions (okay, I’m being unfair — if the software is well-written, it’s a concert of instructions) rush down a wire to an actuating motor at the other end.

Let’s be clear about this: real-time software is a myth. The metal of the lever, or even the fluid of the hydraulic line, has been removed and replaced by your entire software development organization. Materials science out the door, organizational sociology in its place. If you want to know where that leaves us, read this short post about drive-by-wire, and the many comments there.

What’s the answer? In the code itself — perhaps it’s avoiding interrupts and multi-threading, and moving to synchronous programming where everything proceeds in lock-step. At least then a modern car would run like clockwork. Other than that, notice that many of the suggestions in the discussion talk about mechanical back-up systems, which are basically putting the lever back into the system.

But software development is not, as commonly believed, about technology. It is about writing, reading, and communication in ever-larger groups. Those who have said, “The pen is mightier than the sword” were thinking of politics. Now writing, in the form of software, interposes itself between every hand and hammer. We have broken the lever; do we know how to wield its replacement?

Written by Tom Harris

February 13, 2010 at 11:27 pm

Posted in Technology and Society

Tagged with

Software Comes of Age

leave a comment »

When software development has a Lives of the Greats book, a textbook that reads like a prime-time mystery series, and even a children’s picture book, we have finally come of age. Here are the books, and my reviews. Happy reading, and onward to the next age!

Written by Tom Harris

December 29, 2009 at 7:38 pm

Posted in Technology and Society

Tagged with

Software’s Unwelcome Advantage

with one comment

Software’s Unwelcome Advantage
You can do anything in software. That’s the mantra, and it’s true. It’s why hordes of
eager computer science graduates, not to mention brilliant open source coders, keep
joining the ranks of software development. It’s fast, it’s fun, and you can make a
machine that does anything.
The fact that software is instructions to a machine (the “hard” in “hardware”) seems
to have been the only thing John Tukey had in mind when he coined the word “software”
back in 1958. (Dr. Tukey, an accomplished statistician, was more focused on
computerizing the Fast-Fourier Transform, and criticizing the Kinsey Report for its
questionable sampling methods.)
While software attracts developers with its ease in creating things, it tempts all of
us with its other “softness”: amenability to change. Software can be endless fixed,
extended, improved. And that advantage demands something of developers which was
unexpected, and, well … hard.
Hardware must fit form to function so it’s easy to use. And come with good
documentation for maintenance and repair. But that’s all on the outside. Software,
always ready for change, has to be clear and readable on the inside too. In other
words, software developers have to be good writers, because the next developer will
have to read and quickly understand what’s going on in order to change it. And those
written changes have to leave the software again in a clear and readable state.
Good writers? In high school, I avoided English class like the plague (and got bad
marks for using cliches in my papers), preferring to go into school on snow days to
use the (one) computer. Good writing is not why people become programmers. But it’s
exactly what we need. Clear written communication. Now equal in impact to life-
changing books (pen mightier than sword and all that), software crucially affects our
lives — from cars, to food transport, to the electric grid.
That good writing is unwelcome requirement of sofware is why developers code quickly
and obscurely, hate documentation, and shun code review. And  why managers push for
features, delivery, and fixes, while devaluing internal quality.
Is there hope? The only one I can think of must exploit these other likes and
dislikes: managers want software changes fast, while developers like writing new code
more than fixing someone else’s (or their own) bugs. Good writing is the only way to
make code support that scenario, and reap the real advantages of software.

You can do anything in software. Hordes of eager computer science graduates, not to mention brilliant open source coders, keep joining the ranks of software development because it’s fast and fun.

The fact that software is instructions to a machine (the “hard” in “hardware”) seems to have been the only thing John Tukey had in mind when he coined the word “software” back in 1958. (Dr. Tukey, an accomplished statistician, was more focused on computerizing the Fast-Fourier Transform, and criticizing the Kinsey Report for its questionable sampling methods.)

While software attracts developers with its ease in creating things, it tempts us all with its other “softness”: amenability to change. Software can be endlessly fixed, extended, improved. And that advantage demands something of developers which was unexpected, and, well … hard.

Hardware must fit form to function so it’s easy to use. And come with good documentation for maintenance and repair. But that’s all on the outside. Software, always ready for change, has to be clear and readable on the inside too. In other words, software developers have to be good writers, because the next developer will have to read and quickly understand what’s going on in order to change it.  Written changes, again, have to leave the software in a clear and readable state.

In high school, I avoided English class like the plague (and got bad marks for using cliches in my papers), preferring to go into school on snow days to use the (one) computer. Good writing is not why people become programmers. But it’s exactly what we need. Clear written communication. Equal in impact to life-changing books (pen mightier than sword and all that), software crucially affects our lives — from cars, to food transport, to the electric grid.

That good writing is an unwelcome requirement of sofware is why developers code quickly and obscurely, hate documentation, and shun code review. And  why managers push for features, delivery, and fixes, while devaluing internal quality.

Is there hope? The only one I can think of must exploit other likes and dislikes: managers want software changes fast, while developers like writing new code more than fixing someone else’s (or their own) bugs. Good writing is the only way to make code support that scenario, and reap the advantages of software.

Written by Tom Harris

July 10, 2009 at 5:47 am

Posted in Technology and Society

Tagged with

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/):

Written by Tom Harris

May 7, 2009 at 10:07 am

Posted in Technology and Society, Work

Tagged with ,

Code Quality and the Machine

with one comment

I’m reading and excellent book Expert C Programming: Deep C Secrets, by Peter Van Der Linden. It’s the book all C programmers need, because it’s an explanation of why this ever-popular language works (or doesn’t work) the way it does. It also prompts me to review why “code quality” is necessary and what it is.

Code Quality

Ways of writing code that affect software maintenance time and correctness (the “people side”), and that affect computer execution performance and correctness (the “machine side”).

Naturally, it follows that good quality code is code which is written so that maintenance is easy and execution is fast, efficient, and correct.

Today, for a change, I’d like to talk about the “machine side” of things. Re-reading about the details of C, a language known for being high-level but “close to the machine”, made me want to review, from the bottom up, what a computer is, so that code, and code quality, can be placed in context.

I’m taking a big risk offering these definitions without looking them up (I may do that later), but here goes. I am trying to give only the essentials—the absolute minimum required to define the terms. Even though I am an electronics engineer, I have deliberately left out the word “electronic” as an unnecessary popularization of one application of electricity. At the same time, apologies in advance to physicists and chemists who will notice my skipping over their levels of mechanics and electricity. Keeping it simple here.

Machine

A thing which allows action at a distance. Generally has a defined input-output function: person does this to it, and it produces that response to the action.

Simple Machine

There’s a famous short list of them out there—here’s a fun example. To name just one, a lever: press this down over here, and over there, that goes up.

State Machine

A machine that has more than one state, or position of its parts, that it can be in. Specific actions take it from state to state. State machines can be mechanical. Even a see-saw is a state machine.

Clocked State Machine

A state machine that proceeds from state to state by having each state create the next action, which action is applied at the next independently-determined, regular time interval. Not suprisingly, the pendulum clock is the prototype, mechanical clocked state machine. Hence the name “clock” in computers (which we didn’t get to yet).

Electric State Machine

A state machine whose “position” is in fact the pattern of electrical charge. Even a lightbulb is an electric state machine. So is a bit of computer memory.

Computer

A clocked electrical state machine. As we will see later, this definition is enough to make it a generic machine—a machine that can do almost anything people want it to do.

Digital Computer

A computer where all the states are combinations of parts’ states which can only take N fixed integer values.

Binary Digital Computer

A computer where N is 2. Generally the two values are called 0 and 1. But of course the 0 and 1 don’t exist physically. They appear as two different charge patterns in the electrical parts of the computer.

Machine Language

A small set of binary numbers, with corresponding computer state-change responses. When a special part of the computer is forced to take on the state represented by one of these numbers (popularly called “loaded into memory”), at the next (one or a few) clock cycle(s), the computer will change to the corresponding new state. Also, a machine language is written by the computer parts manufacturer, and supplied with it.

Assembly Language

A small set of letter combinations which map 1:1 to the machine language. Exist only because most people remember letter combinations better than number combinations.

Computer Program

A list of combinations of language elements (“statements”) that, when loaded into memory along with a “start” instruction, cause a computer to proceed automatically from state to state.

High-level Language

A set of words, and rules for combining them, that, when used in a computer program, which is passed through another computer program (called a “compiler” if processed all at once, or an “interpreter” if processed one word at a time), produce a machine language computer program.

Software Design (activity)

Deciding how a computer program should be organized to best cause the running program to be compiled or interpreted so that the computer will do what was required. (See “Requirements”, immediately below.)

Requirements

A set of statements, in a human natural language, each one containing “shall” or “must”, which mostly describe how a computer should respond to actions applied to it.

Well, that was a lot, but much shorter than a college textbook!

Where Code Quality Fits In

Go back and read “high-level language”. That’s where code quality fits in, and why it’s a challenge. The code must both represent the design description, and meet the constraints of the particular high-level language. Further, that language may have been written for the convenience of the compiler writer. Finally, a large part of the machine language that makes up the running program does not come from the developer’s high-level language program, but from third-party programs written by multiple hardware manufacturers. It’s like copying a painting while looking at the painting in a mirror, and looking at the canvas in another mirror.

No wonder that under those constraints, writing code that is both clear to people, and correct for the compiler, is difficult. But with the twin tools of code review and static analysis, it is possible.

Written by Tom Harris

November 25, 2008 at 10:57 am

Posted in Technology and Society

Tagged with ,

Telescopes and Software

with one comment

This evening I was looking for pricing on some code analysis tools, and found an organization that had done a very comprehensive survey, and published it
 
http://dev.lsstcorp.org/trac/wiki/CppCodingStandardCheckerReview%3A#CStaticAnalysisTools
 
And they’re pretty organized and public about their entire software development process: http://dev.lsstcorp.org/trac/wiki
 
But I asked myself, who are these people?
 
Well, here’s a photo: http://www.lsst.org/About/lsst_team.shtml
 
They are building in Chile: http://www.lsst.org/Images/pachon.shtml
 
They want to take pictures like this: http://www.lsst.org/Science/lsst_science.shtml
 
Overall, this is their project: http://www.lsst.org/lsst_home.shtml, in part:

In a relentless campaign of short exposures with its 3.2 Gigapixel camera, the LSST will cover the full available sky every three nights, opening a movie-like window on objects that change or move on rapid timescales: exploding supernovae, potentially hazardous near-Earth asteroids, and distant Kuiper Belt Objects.

All in all, some pretty interesting people!
 
Also honest about how their software milestones, like those on so many other projects, are behind schedule: http://dev.lsstcorp.org/trac/roadmap?show=all

Written by Tom Harris

August 20, 2008 at 11:44 pm

Why We Write Software

leave a comment »

“Isn’t it nice to know that, when all else fails us, we have an innate decision-making tool to fall back on?”

Robert L. Glass, “Intuition’s Role in Decision Making” (IEEE Software, January/February 2008)

Yes, Glass admits, estimates that come unbidden from a manager’s subconscious seem the very opposite of quantitative or rational. But most decision-making methods have a common theme: using historical data to decide what to do next. Quantitative estimation puts everything out in the open. Rational support for a desired deadline is at least based on the facts. Intuition, at the other extreme, pulls that data, informally known as “experience”, from the subconscious. And since a good manager has experience, intuition works.

Sort of.

What’s hidden by Glass’ essay are the unstated quality standards that justify each method. Only a complete, quantitative estimate, matched by continuous measurement and adjustment, can promise high quality by the target date. Intuition, on the other hand, even coming from an experienced manager, makes quality likely, but hardly guaranteed. His successes are what keep him in his job, and his few failures are forgiven. Rightly so. He is employed to deliver good enough software, quickly, to meet modern society’s ever-growing appetite for computerized life.

So should we favor intuitive, seat-of-the-pants estimating, with its benefit of early delivery, but its cost of uncertain quality?

Digging deeper, we find that there are some very different reasons why we write software, which strongly influence how we plan our work.

  1. Profit
  2. Functionality
  3. Beauty

Anyone who gets paid for writing commercial software must acknowledge that profit pays his or her salary. Profit leads eventually to pretty good quality, via competition. In the short run, though, we experience a lot of pressure, a lot of errors, and many customer-accepted (if sometimes societally unacceptable) failures. In that context, it seems, we should estimate quickly and intuitively, but admit that quality is expendable.

In a well-funded, non-profit organization (e.g. NASA, famed for error-free software — wholly separate from failure-free flights), software can be about complete functionality. Take as much time as needed to implement everything, perfectly. After all, when the spaceship flies past Jupiter, there’s no second chance.

Where, then, is guaranteed perfection, estimated correctly and delivered quickly? The only place we see that in life is artistic performance. A pianist plays, from memory, a piece that she only decided a few months ago to perform. An hour long, no mistakes. The event starts, and finishes, on time. The customer — the audience — rises to its feet in noisy appreciation. The enabler of perfection is seeking beauty, or doing a thing for its own sake.

Many software developers write software because it’s beautiful, fun, or spiritually rewarding. And that reason engenders the highest-quality work. A quality that delivers on time, with no costly rework. Functionality. Profit too.

Somehow, in the commercial context, that reason why we write software must be harnessed and encouraged by software managers. Otherwise, dismissing a developer’s data with an intuitive estimate is not a fall-back, but falling backwards.

Written by Tom Harris

February 15, 2008 at 11:26 am

Posted in Technology and Society

Tagged with

Looking Back, Looking Forward

leave a comment »

Some return for your U.S. taxpayer dollars:

CrossTalk, The Journal of Defense Software Engineering is an approved Department of Defense journal. CrossTalk’s mission is to encourage the engineering development of software in order to improve the reliability, sustainability, and responsiveness of our warfighting capability and to inform and educate readers on up-to-date policy decisions and new software engineering technologies.

Whatever you may think about “warfighting”, CrossTalk sometimes has some really good articles, and even some great ones. Here are two, from the December 2007 issue:

Very good, about software maintenance:

Geriatric Issues of Aging Software

Great, about moving beyond “escaped defects” to defect prevention: 

Advancing Defect Containment to Quantitative Defect Management

Both are thorough and comprehensive—worth reading!

Written by Tom Harris

November 27, 2007 at 7:52 pm

Posted in Prevention

Tagged with ,

Craftsmen (and women) in the Modern Factory

leave a comment »

Used to be that products were made by craftsmen. Lots of art, skill, and tools in the hands of an experienced individual.

The industrial age brought us the factory, with an emphasis on automation, process, and soon, statistical control.

More recently,  high-quality producers worked to combine the two, with individual or small-group responsibility for an entire component as part of an industrial manufacturing system.

In software, the building construction analogy has fallen. The important, human part of programming is design. Construction, so often error-prone, need not be. Take an ingredient from each part of the history above: from craftsmanship, discipline. From manufacturing, computerized tools.

Here’s how I see a modern factory of software craftspeople working:

  • The best tools for writing good code attached to each developer’s IDE
  • The same tools centrally build-automated (e.g. with CruiseControl), with IDE-compatible output too
  • Code review for readability, maintainability, and extensibility of code, and for continuous developer improvement
  • Constant professional discussion amongst developers and their group leaders about coding and detailed design
  • Detailed root cause analysis to prioritize improvement efforts

Written by Tom Harris

May 30, 2007 at 8:32 am

Posted in Technology and Society

Tagged with ,