• When optimizing code for GPU, FPGA, or CPU, definitely focus on pipelining and overall throughput, not just local optimizations.
• There’s a trade-off between “faster” and “sooner.” It’s not always worth saving a few seconds (or even a few minutes) if the kernels take hours or days to compile. (Then again, sometimes it is.)
• Try to reduce dependence on the language/compiler “stack” that removes inefficiencies. The optimizer does good work, but you can do things to help it. Think about the hardware or architecture format. It’s not a sin to reduce the amount of abstraction in the service of performance. Pay attention to things that affect processor pipelining and cache movement.
• BTW, some languages and technologies exist to provide higher level programming that’s close to the hardware, but they’re proprietary, secret, or still in R&D.
• Use algorithmic optimization techniques. Step back and find the shortest-time computation.
• Avoid using if statements. The goto construct is considered harmful, but if is basically the same thing. Instead think about state machines and polymorphism. There’s no branch-prediction penalty to pay, since the system “just is” in the state it’s supposed to be in. The logic is clearer, because there are no switches, making it easier to test, too.
• Don’t always assume that floating-point values are necessary. Integers can often be creatively used and are far faster for math than double-precision numbers.
• Of course, there’s a compromise between speedy/efficient and readable/maintainable.
• Aim to structure programs as “symbolic intent.” Mathematical descriptions are bad ways of expressing programs. Think about functional programming models instead of procedural.

If you want to know more, you should definitely watch the half-hour interview. And if your reaction was more along the lines of “Yes, yes; that’s all true, and it’s how I design my image processing code,” then I definitely hope you’ll consider applying for the GPU/multicore engineering position we have open.

This is another one of those posts. Every year between Christmas and New Years Day, I try to use the quiet week to get stuff done and tie up loose ends. Last year, I cleared out a bunch of notes. This year, I’m looking at presentations and slides from the QCon SF 2011 conference (wrap-up). Its focus on software architecture and project management is about 75% of my job, so many of the presentations seemed tailor-made for me. Here’s some of what I learned.

Erik Doernenburg. “Software Quality: You Know It When You See It” has a really good slide deck that got me thinking about some projects I might want to set up. It’s full of practical, usable suggestions:

• View the code at the 1,000 view, rather than ground-level or 30,000 feet.
• Look at the test-to-code ratio, not just code coverage.
• Graph the change of metrics between versions and revisions, compare across different parts of the code, and look at them relative to industry standards.
• Measure the “toxicity” of code by rolling up various quality metrics about a bunch of modules into stacked bar charts.

We should pose these questions during design and code reviews:

• Is the software/change of value to its users?
• How appropriate is the design?
• How easy is the code/design to understand and extend?
• How maintainable is the software?

It was full of some really great links to things like Metrics tree maps (a.k.a., pretty heatmaps for source code) as well as a few tools: SourceMonitor, iPlasma, and using Moose to visualize quality.

Joshua Kerievsky. “Refactoring to Patterns” — some notes:

• Refactoring is like algebra’s equivalence-preserving manipulations. “Design patterns are the word problems of the programming world; refactoring is its algebra.”
• Understanding the refactoring thought process is more important than remembering individual techniques or tool support.
• Code smells have multiple refactoring options and often benefit from composite refactorings.
• Look for automatable refactorings first. Consider changing the client of smelly code before the smelly code itself.

Guilherme Silveira. “How To Stop Writing Next Year’s Unsustainable Piece Of Code” was pithy and thought-provoking.

• There is no value for architecture or design without implementation. That’s just interpretation of the software.
• “New language. New mindset. new idiomatic usage. Same mistakes.”
• Complexity and composition are natural and good, but if they’re invisible, they’re evil.
• Start with a mess and refactor right away. Starting “right” is hard (and misguided thinking). Refactor for better, not just prettier.
• Make complexity easier to understand and see.
• Hiding complexity in concision hurts testability, since no one knows the complexity is there. Furthermore, if it’s hard to test, it’s also hard to use correctly.
• “Model rules. Do not model models.”

Michael Feathers. “Software Naturalism: Embracing The Real Behind The Ideal” is a presentation that I would like to see/hear, since the slides seemed full of information but weren’t self-explanatory. Here are two things I could glean: 80% of software defects in large projects were in 20% of the files. In general, the more churn in a file, the more complex it tends to be.

Panel: “Objects on Trial” was perhaps the most unusual presentation, since it was a mock-trial. I use objects all the time . . . some of them are good . . . some demonstrably so. Even so, I never latched onto the idea of object-oriented (OO) design versus objects as types. The four panelists, in one way or another, basically said, “That’s the problem.”

One of the panelists drew an extended analogy between the space program and OO. The space shuttle (which we all love) was fixated on reuse but basically was a waste of heavy lifting; people don’t reuse the right stuff. In software, object reuse is largely accomplished by cut-and-paste copying of boilerplate code that does close to what you want. Of course, the panelist acknowledged that we do reuse the ideas in OO via design patterns, and no one seems to have much of a problem with that. Ironically, having a rich pattern language means that software engineers are in a better place than ever before to use objects correctly.

A key problem with our approach to objects is that we’ve failed (generally in software engineering) to handle complexity well, which was supposed to be the point of OO design. A conflation of beauty and OO design makes things worse. Internally, software is ugly, and beauty shouldn’t be a goal. Making a fetish of beauty makes code inflexible because people don’t want to extend the beautiful thing that works.

For other panelists, objects weren’t the problem at all. For them it’s static typing in “OO languages,” such as C++, Java, and C#. We’re at a place now where all of the good things about OO have been lost in an attempt to make OO languages as fast as C. This runs counter to the goal of having “ordinary,” understandable code. Generic programming using strongly typed (possibly template heavy) languages just makes everything complicated.

For me, it’s moot. C++ is what I use, and I don’t have a large proprietary object system that I can tap into for reuse. I’m in the camp that uses C++ objects to generate new types for data hiding and aggregation, as well as (to a lesser extent) reuse. But some of these types are generic, template classes that are hard to understand. I plead “no contest.”

So, into Microsoft Excel it went. After sorting and grouping the data, here it is:

Diabetes Exercise Data

Believe it or not, I am really more of a narrative person than a numbers person, and I already worry that looking at the data this way will obscure other important details or magnify the importance of data over context. (That’s actually why I hate the way many endocrinologists approach diabetes management, though I understand why they do it that way.) Nevertheless, I hope this different view into the last five weeks will illuminate trends. We shall see what comes from all of this.

• Lisa and I took a day-trip to New York to see an exhibit on insulin and meet people with diabetes from the online community.
• I visited the MFA several times since the new Art of the Americas wing opened.
• I traveled to San Francisco to attend a couple of conferences.
• We went to the Museum of Russian Icons in Clinton.
• And, of course, there was a lot training for a half-marathon in March and a triathlon in a few weeks.

Here are photographs from our five-month winter adventure.

Ενα “whiskey” σε παρακηλω!

Le soleil sûr ma tête, ce me fait comme un bête.

ΑΡΧΕ ΚΟΡΙΝΘΩΣ

La pluie de l’Espagne reste pour le plus part dans les pas.

शान्ति ॐ शान्ति

οίμοι κακαδαιμων εγένετω τυφλός

Je veux crasser arracher mes yeux.

Compiled apps don’t run
In R2009b.
Missing DLLs.
— A haiku

Mon petit chat a des cheveux blancs et noirs.

ή γύνη σπεύδει προς των αγρών

I’m pleased to say that it looks like I might get a chance to follow-up on that idea more in the coming year. I’ll keep you updated. In the meantime, here are few ideas on the subject from one of my notebooks. (I appear to be going through these “historical documents” in a rather random chronological order.)

When are the pause points where we might use checklists?

• Before starting to design
• Before starting to code
• Before code review
• Before submitting changed files
• Before QE-led testing

Who might be included in the check-off activities? The goal is to catch problems and communicate what’s happening.

• Coder/Developer
• Quality Engineer/Tester
• Buildmasters
• Doc Writer
• Project Leader (?)

What’s so mindless that it’s taken for granted? (e.g., “build and run tests on every platform.”) Are these second nature? Or are they sometimes forgotten/overlooked/not done?

What goes onto a “pre-flight” checklist? What goes onto special circumstance (“OMG the plane is crashing!”) checklists? The idea is to have lots of small checklists.

What level of specificity is required for a checklist?

Today, requirements. I honestly can’t remember if I’ve written here about defining requirements in software projects. Getting them defined right is so important, I would be surprised if I hadn’t. Here are just a few more notes.

Questions to ask about your requirments:

• Are they adequately motivated?
• Are any missing?
• Are there any included that aren’t really needed?
• Are any solutions masquerading as requirements?
• Are they testable?

These requirements are often overlooked:

• Localization (L10N)
• Robustness
• Performance (speed, memory)
• Backward compatibility

And remember, not all requirements have the same priority. Try to stage solutions to address different priority levels.

Update: It’s hilarious how many times I’ve already found names and telephone numbers for people who work at Medtronic Minimed.

• tort — pas correct
• retraite — pension
• parmi — among (“parmi ceux-ci . . .” = “among these . . .”)
• la Toile — The Web/Internetz/etc.
• mention — statement (masc. n.)
• pouce — thumb
• renverser — to overthrow
• pari — gamble (masc. n.)
• pas forcement — not necessarily
• nulle part — nowhere
• ailleurs — elsewhere
• hors piste — backcountry
• bourrée — stuffed
• enregistrer — to save
• majordome — butler
• à la une — feature (as in “a featured story”)
• tyrolienne — yodel (fem. n.)
• se faire chier — to piss off, to annoy, to have a fucking nightmare, to be pissed off
• la chiasse — the shits
• chiant — boring
• piéger — to trap, ensnare (“la France piégée par les vélos”)
• les hirondelles — the swallows (birds)
• locataire — tenant (fem.)
• ado — teenager, adolescent
• tache — stain (fem. n.)
• honte — shame
• crainte — fear
• les orteils — toes
• marée noire — oil slick
• tricheur — cheater (masc.)
• hauban — linceul, shroud
• paroisse — parish
• tiroir — drawer (as in “a desk drawer”)

• bagnole — voiture (a car)
• virée — petit rendre-visite (a small trip, a hike, etc.)
• revendiquer — to claim
• raté — failed, attempted, missed, abortive (adj./pp.) or failure, misfire, backfire (n.)
• portiques — gates, turnstiles
• rien que… — just…
• jeu de mot — pun
• étonnant — amazing, enormous
• touche — un clef sur le clavier de l’ordinateur (keybord key)

Atul Gawande proposes a solution for all sorts of endeavors in his book The Checklist Manifesto: How to Get Things Right. It’s a short, engaging read, and I recommend it for anyone who has to apply knowledge to complete a task. That’s most of us.

We use checklists and recipes in some of our software development processes, and I’m in the process of applying what I’ve learned to improve them. I hope to share some of the results here in coming months — supposing that the final product isn’t too site-specific — but in the meantime, here are my more-or-less raw notes from Gawande’s book, which isn’t specific to any particular industry, although it was written from a surgeon’s perspective.

• Checklists are all about managing complexity, providing a “cognitive net” against “flaws of memory and attention and thoroughness.” They are “forcing functions . . . straightforward solutions that force the necessary behavior.” A good checklist should help its users “get the stupid stuff right.”
• The project plan is a kind of checklist. And the communication (submittal) schedule is a complexity manager. The idea is to communicate what needs to happen when in a complicated process (like building a skyscraper, writing software, or operating on a patient) and having a process in place to ensure that all of the parties in the project have shared all of the information about changing requirements and problems available at specific times.
• It’s possible/advisable to use tools to manage complexity, conflicts, and information integration. Sometimes the result of using the tool looks like a checklist, but not always. Sometimes it’s a Gantt chart or a cook’s recipe.
• The checklist steward: Anybody can change a checklist, but it has an owner who feeds and waters it.
• Complex situations don’t (usually) require detailed instruction. They do require high-level goals and lots of communication. (Gawande gives the fascinating case study of Wal-Mart’s response to hurricane Katrina in 2005.) Solutions should be simple, measurable, transmissible. They should encourage team interaction and engagement. Project owners should facilitate communication for complex tasks.
• The team huddle helps coordination, and it can help with keeping commitments. It’s important to communicate risks and issues early and often.
• Communication should happen (at the very minimum) during specified “pause points” between transitions in the process. In the operating room, these points might be just before administering the anesthesia, before closing up the patient, etc. In an airplane cockpit, they are before starting the engines, before leaving the gate, before take-off, before landing, and so on. (Figuring out what these are in a software development process is something I’ve already started considering.)
• Aviation uses lots of small checklists. A “normal situation” checklist should be very short. An exceptional situation should be very brief, readable, and actionable, too.
• Good checklists are made by practitioners, usable, available, put into use, about 5-9 items long, tested, and completable in about 60-90 seconds (or less).
• Bad checklists are long, imprecise, vague, hard-to-use, or impractical.
• Cockpit crew have created two categories of checklists: DO-CONFIRM and READ-DO. “With a DO-CONFIRM checklist . . . team members perform their jobs from memory and experience, often separately. But then they stop. They pause to run the checklist and confirm that everything that was supposed to be done was done. With a READ-DO checklist, on the other hand, people carry out the tasks as they check them off — it’s more like a recipe.”
• Things that are “never” forgotten by a normal practitioner don’t need to be on a list.
• After they’re put into use, checklists need continuous improvement. They must be revisited and refined. It’s a good idea to put a publication date on them.
• Most people — doctors, financiers, software engineers, etc. — don’t like to use checklists. They consider them neither fun nor in keeping with the “heroic” nature of their role. They feel checklists are “beneath them.”
• Ideally they should be usable and helpful for both novices and old-hands.
• Checklists should not be rigid, creativity- or team-killing exercises. They’re designed to “get the dumb stuff out of the way” and provide the leeway to be creative on the hard/sexy stuff. They’re frameworks for self-discipline and productivity.

Other people’s notes about the book:

• How to write a checklist (What Consumes Me)
• A checklist for your checklists (The Clutter Diet Blog)
• Checklist Manifesto (Lumber Tribe)
• Official book website (Atul Gawande)
• Checking — 1, 2, 3 (Health Man Blog)
• Charlie Rose interview

Do you use checklists? How well do they work for you? What do you like and dislike about them? Feel free to leave your feedback in the comments.