Archive for the ‘Technology and Society’ Category
I’m in Software
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?
The Day they Broke the Lever
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?
Software Comes of Age
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!
- Coders at Work, by Peter Seibel (review by talkaboutquality)
- If I Only Changed the Software, Why is the Phone on Fire? by Lisa K. Simone (review by talkaboutquality)
- I am a Bug, by Robert Sabourin (review by talkaboutquality)
Do You See What I See?
Recently I found an excuse to dust off some old lab books of introductory science experiments. They were the curriculum for a 9th grade Physical Science I class at my high school; I wrote them as a summer job during college. I didn’t invent the experiments. Rather, the head teacher gave me outlines, and my job was to try them out and make sure they would work, so that prospective students wouldn’t get frustrated and turned off by science.
The excuse was a friend, a scientist, who is meeting a public service requirement of her studies by volunteering to teach science to schoolchildren, and to their teachers. I offered my science course as possible material for her classwork. As we looked over the experiments, we doubted a bit how even 9th graders might learn from them, or be as excited about them as I was when I built and tested them myself. Sure, the projects were easy, and they had worked. But would the experience of building these projects — static electricity demonstrations, electromagnets, motors — be enough to convey the principles behind their operation? Would the kids see the point?
Yesterday I was in the kitchen preparing a simple lunch of tacos and beans. Washing and cutting lettuce, chopping an onion, peeling a cucumber, grating cheese, warming the beans with some tomato sauce. In the quiet afternoon, I couldn’t help noticing the crunch of the knife through the lettuce. Or wondering how best to preserve the other half of the cucumber, now leaking water from its open end. And why do we grate cheese? So much science, here in the kitchen!
Now with the internet, you can search “science in the kitchen” and get pages and pages of websites with all sorts of neat science projects in the kitchen. Let alone YouTube with some pretty exciting and dangerous experiments. (Be warned!) I have no doubt that school science textbooks have taken this to heart and now include experiments that relate to the real world. And yet, science enrollment declines.
Even with the best of intentions, popular science experiments in the kitchen won’t do it. Science is not in school, nor is it in the kitchen. Science is not an activity, but a way (just one way) of looking at the world and making sense of it. What excited me in science class was not the sitting and listening to the lecture. It was making the connections with daily life outside class, and enjoying the beauty of the natural world with new understanding.
Those understandings could come from things as simple as basic cell structure in biology. There’s lots of water in a living cell, so when you peel and cut a cucumber, it gets wet. Or as complex as thermodynamics. One college winter, I learned that there’s really never a flow of “cold”, but only heat transfer. For a good month after that, climbing the steps to class, I would grasp the banister outdoors, and instead of feeling cold, I felt the heat flowing out of my hand into the metal. These experiences are what brought me back to study even more.
Science teachers have to have and share that excitement. If they’re not science experts themselves, no matter. They are learning adults, who can build their own understanding and catch the excitement from science mentors. The key has to be in giving the right answer to the question so many students ask: “But what is this good for?” The wrong answers are the allegedly practical ones — advancing technology, getting a job, or passing the test. The right answer, the one that should guide science teaching, and bring the kids back to class, is “Because the world around you is beautiful, and science gives you eyes to see it.”
Software’s Unwelcome Advantage
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.
Software Developer
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/):
- Blog: http://shape-of-code.coding-guidelines.com/
- Article: Coding Guidelines: Fact and Fiction
- Article: The 7±2 Urban Legend (small pdf)
And somehow related, from another author, Les Hatton (http://www.leshatton.org/):
Code Quality and the Machine
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.
Why We Write Software
“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.
- Profit
- Functionality
- 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.
Craftsmen (and women) in the Modern Factory
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
No Free Lunch
Recently I read an article by Norman Balabanian (“On the Presumed Neutrality of Technology”, IEEE Technology & Society magazine, reprinted Winter 2006, pp. 15-25; originally published in 1980), where he addresses, among other things, the popular claim that people choose new technologies out of free choice. That if we use a technology, whether it be a car, or a refrigerator, or permanent-press clothing, we freely choose the benefits, and have accepted the costs. In several examples, Balabanian shows that we do not. We live modern life as part of an interlocking, consumption/profit-driven system which requires us to accept most of the new technologies, or starve.
I decided to do a small experiment in the household, to see up close what Balabanian was talking about.
The Experiment
I set out to collect and put aside all the food packaging that our family opened and threw away as part of our meals at home for one week. Not paper plates or napkins, or non-food trash such as newspapers. Just the containers that our food comes in. My kids wondered at first, but after a day or two I convinced them that even after school people still learn, and this was my self-assigned science project this week. As material rapidly piled up, I cut off “data” collection at 4 days.
What did I find?
I collected a half-full garbage bag of paper and cardboard, similar of plastic bags and bottles, and a few metal cans, for a total of 1 kg of waste material. By weight, the packaging was a bit less than 4% of the food net weight. Not much at all, but I was not concentrating on waste vs. recycling.
Rather, I was looking at the question: have we freely chosen to buy our food packaged?
Looking at the list below, I have to say “no”. Very few of these foods are available for purchase either at our corner grocery, or our large supermarket, without the packaging (i.e. take in your own container).
Reminds me of a cynical saying we used to have in high school: “You have a choice … and it has been made for you.”
The Challenge to Innovators
Don’t tell me how to recycle these materials. (We do already—as much as our city provides for.) That’s more forced choice: take the food in packages, and then recycle the packages.
Instead, suggest ways that we or the food distribution system could change so that we could eat our (reasonably) healthy diet without all the packaging in the first place.
Appendix 1: Four Days of Food Packaging
Food Amount (g) Type Wrapper Type Comments
Cheetos™ 55 Prepared Plastic Silverized
Pudding 330 Prepared Plastic
Fruit 1000 Prepared Plastic Styrofoam
Flour 2000 Prepared Paper
Cola 3000 Prepared Plastic
Milk 3000 Raw Plastic
Cereal 1200 Prepared Paper Waxed cardboard
Cereal 0 Prepared Plastic
Cottage Ch. 250 Prepared Plastic
Sugar 1000 Raw Paper
Potato Chips 50 Prepared Plastic Silverized
Eggs 1400 Raw Paper Cardboard
Soda Water 1500 Prepared Plastic
Smoked Salmon 100 Prepared Plastic
Granola 500 Prepared Plastic
Brown Sugar1000 Raw Paper
Yogurt 450 Prepared Plastic
Fruit Juice3000 Prepared Plastic
Margarine 2000 Raw Paper Waxed paper
Tuna Fish 320 Prepared Metal
Pineapple 825 Prepared Metal
Crackers 325 Prepared Plastic Silverized
Egglplant Spread 1000 Prepared Plastic
Mineral water 3000 Raw Plastic
Total Food Weight 27305
Talk About Quality 