Category Archives: From the Yellow Notepad

The Frustrated Software Architect

Simon Brown gave an interesting lecture on “Agile Architecture,” entitled The Frustrated Architect at GOTOCon. Here are some notes and reactions:

  • Whatever methodology you use, aim for the best of flat, self-organizing teams. Make sure to mind the inter-team gaps. That’s where architecture helps.
  • My team could probably use UML more for modeling the architecture (the “what” and “how” of interactions between our features) more. Color-coding different class/component roles adds another dimension of description.
  • Do class-responsibility-collaboration (CRC) modeling for architecture. Using Post-Its makes it “Agile.”
  • “Coding the Architecture” = Win. “Project Managing the Architecture” = Fail.
  • Focus on functional/nonfunctional requirements, constraints, and operating principles.
  • Use “paper prototype”-like activities in small groups to create effective sketches of the architecture. Then ask “Would you code it that way?” If the answer is no, redo/fix it.
  • The architecture should highlight both the domain (e.g., accounting) and software design (e.g., GUIs, model-view-control, etc.).
  • Base the architecture on requirements and prove the architecture works via experiments.
  • Architecture is what is difficult to refactor in an afternoon (or week). It’s costly to change, complex, risky, and (often) novel.
  • Do “just enough” design. How do the significant elements work together, mitigate key risks, provide foundation to move forward.
  • Just document what the code doesn’t describe.
  • We need our technical mentors to keep teaching as they keep moving up the corporate ladder.


Dear Diabetes Blog Week readers, we’ll be back to our normal programming tomorrow. Stick around. (I don’t post techie stuff like this very often.)

Posted in From the Yellow Notepad, Software Engineering | 2 Comments

Thinking Differently about Software Optimization

Yesterday morning while eating my “Free Wednesday Breakfast” chocolate croissant and fresh fruit with yoghurt, I watched an interview with John Nolan entitled “The State of Hardware Acceleration with GPUs/FPGAs, Parallel Algorithm Design.” In the spirit of giving back, I’m posting a few notes.

  • 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.

Posted in Computing, Fodder for Techno-weenies, From the Yellow Notepad, Software Engineering | Leave a comment

QCon SF 2011 Software Engineering Conference Notes

It’s sometimes possible to forget when reading all of the posts here about travel, diabetes, triathlon, and photography that they’re just a small part of my life. I have a job to which I devote a whole lot more time. I don’t talk about it much because (a) discussing what I’m working on putting into the Image Processing Toolbox isn’t appropriate or allowed, and even if it were (b) talking shop probably isn’t that interesting to most of the people here. But—believe it or not—the majority of traffic to my site lands on the pages that are technical, so I don’t feel so bad about posting the random “fodder for techno-weenies” post. (It’s a term of endearment, I promise! :^)

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.”

Posted in Computing, Fodder for Techno-weenies, From the Yellow Notepad, Software Engineering | Leave a comment

Exercise Data

I mentioned last week that I’ve been journaling about exercise for over a month now. With all of that data—over forty events—it’s finally time to sift through it for patterns, to see what worked and what didn’t, and to come up with a new round of “experiments” to do as I swim, bike, and run.

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.

Posted in Data-betes, Diabetes, From the Yellow Notepad, Life Lessons, Reluctant Triathlete | Leave a comment

Spring Cleaning

It was a long winter with more snow than I can ever remember. We had snow on the ground continuously from the day after Christmas through mid-March with an extra four or five inches on April Fools’ Day. Despite the weather, we did a lot . . .

  • 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.

Posted in Cycling, Diabetes, From the Yellow Notepad, General, I am Rembrandt, New York, Photography, Running, Travel, USA | 1 Comment

How to Stay Awake in Meetings, Episode #7

Sometimes I get bored in meetings. Here are some scribblings from one of my 2009 notebooks:

Ενα “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.

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

Posted in From the Yellow Notepad, General, Hoarding | Leave a comment

Early Ideas about Using Checklists in Software Engineering

Some months ago, I wrote a review of Atul Gawande’s Checklist Manifesto and about using checklists in software development.

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?

Posted in From the Yellow Notepad, Hoarding, Life Lessons, Software Engineering | Leave a comment

Requirements . . . again

It’s the week between Christmas and New Year’s Day . . . time to clean out the files at work. Actually, this year at the office I’m going through all of my yellow notepads — about 17 of them. As I find something interesting, I’ll post them here.

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.

Posted in From the Yellow Notepad, Hoarding, Software Engineering | Leave a comment

Bon Mots – Part 2

Since we’re going to Montréal this weekend, here’s another installment of some French words that were recently new to me. (You might be interested in the first part, too.) As always, if I have missed something subtle in their meaning, let me know.

  • tortpas 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.)
  • haubanlinceul, shroud
  • paroisse — parish
  • tiroir — drawer (as in “a desk drawer”)
Posted in Bon mots, From the Yellow Notepad, General | 1 Comment

Bon Mots – Part 1

It’s time to share some of the French words that were new to me. If you speak or read French, maybe they’ll be useful to you, too. And if I have missed something subtle in their meaning, let me know.

  • bagnolevoiture (a car)
  • viréepetit 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
  • toucheun clef sur le clavier de l’ordinateur (keybord key)
Posted in Bon mots, From the Yellow Notepad, General | Leave a comment

The Checklist Manifesto

How can you prevent mistakes? Some mistakes have extraordinary costs: airplane crashes, surgical infections, building collapses, nuclear power-plant explosions. Even the mistakes that don’t kill people — like software defects and leaky roofs — can slow you down by adding waste to a process, forcing you go back and spend time (and money) to fix a problem. In either case, we don’t choose to make these mistakes. So how do we prevent them?

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:

The Daily Show With Jon Stewart Mon – Thurs 11p / 10c
Atul Gawande
www.thedailyshow.com
Daily Show Full Episodes Political Humor Health Care Reform

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.

Posted in Book Notes, From the Yellow Notepad, Health Care, Life Lessons, Software Engineering | Leave a comment

Implementing Lean Software Development – Part 1

At midday yesterday my carpool buddy and I looked at the weather map, saw a scary blob of impending frozen doom, and decided to heed the Governor’s advice to go home. But the snow that was forecast — the blizzard that was supposed to mess up the evening commute — never really materialized here in the Commonwealth. Oh well. Only 1-2″ to shovel.

While working away the afternoon at home, I started reading Mary and Tom Poppendieck‘s Implementing Lean Software Development. I guess “rereading” would be more accurate, this time with an eye toward actually implementing the ideas. Here are my notes from the first few chapters.


What is Lean Production?

  • Use just-in-time (JIT) flow of work products.
  • Stop the line to fix problems as soon as they are discovered.
  • Eliminate stockpiles of in-process inventory. Create small batches.
  • Make mistakes impossible from the beginning.

Product development is knowledge creation via exploration of designs, experimentation with prototypes, and integration meetings that evaluate designs and make decisions.

Schedules have synchronization points, but let expert workers function autonomously between them.

Explore multiple options and make competing prototypes. Defer the decision about which to actually build until the right time (usually later than you think).

Software should be easy to change. Employ all of those high-quality best practices and metrics during construction.

The Toyota Product Development System — upon which the Poppendiecks base their book — is very empirical. The final idea/design/product emerges during development. At the outset, define the goals to meet, not the technology or architecture you’re going to use to satisfy it.

1: Eliminate Waste — Minimize the time from request to fulfillment

  • Waste is everything that doesn’t actually add value to a customer feature. Focus on value.
  • Reduce the amount of partially done work (inventory). [Basically, don't work on what you haven't been asked for, and complete what you start. Get it written, tested, checked-in, and reviewed.]
  • Reduce the time between requirements, coding and testing. This helps reduce requirements churn. Use test-driven development (TDD). Shun “big bang” integration.
  • Avoid extra features and scope bloat.

2: Build Quality In

  • Control the conditions for creating quality components, preventing defects.
  • Write tests first. Use TDD.
  • Continuously integrate. Integrate code and tests together.
  • Write less code. Keep it clean and simple. Don’t duplicate. Refactor.

3: Create Knowledge

  • Go from a sketch to detailed design during construction.
  • Release a minimal set of functionality to customer for feedback.
  • Create daily builds and get feedback (knowledge) from integration tests.
  • Have an experienced team. Pour learning back into the team.
  • Build a modular architecture that supports adding/changing features as you learn more.
  • Generate new knowledge through disciplined experimentation. Codify that knowledge and make it available to the larger organization. Build a knowledge base. Encourage long-term thinking.
  • Continuously improve processes.

4: Defer Commitment

  • Try to make most design decisions reversible/undoable/nonbinding.
  • Schedule irreversible decisions for the last possible responsible moment.
  • Always move toward the concrete, and identify where change is likely to occur.
  • Experimentation reduces the risk of making the wrong decision.
  • Planning is an exercise, but plans are overrated. Avoid “plan-driven methods.”

5: Deliver Fast — Compete on time

  • Be faster than your customers’ ability to change their minds.
  • Requires low defect rates, high quality processes, good understanding of the customer.

6: Respect People

  • Favor ownership at the worker level, not top-down.
  • An entrepreneurial leader should own the product and foster engagement.
  • Develop and nurture technical expertise as a competitive advantage.
  • Give general plans with reasonable goals. Then let the group self-organize to meet them.
  • There is no “one best way.” There is continuous improvement, though.

7: Optimize the Whole

  • Optimize the whole value stream, that is, not just local processes.
  • Pay particular attention to where products,code and processes transition between departments, teams, organizations or physical locations.

The product development timeline:

  • Concept — What’s the unmet customer need or desire?
  • Feasibility — Test feasibility by experimentation. Build stuff. Ship betas. Design systems. Investigate the major features of the business process, key hardware modules, interfaces, boundary behaviors, software architecture and constraints. Can the product really be built? Will it work?
  • Pilot — Work with your customers. Show off the product; collect data; iterate. Let people choose from multiple options by playing and “voting with their attention.” Run multiple pilots to refine the design.

You have to go way beyond meeting basic expectations, even beyond adding new features or improving performance. You have to identify needs customers don’t know they have and then delight them by meeting those needs. This requires developing a deep understanding of the customers’ world.


That’s all for now. I’ll post more as I continue my way through the book — perhaps the next time it “snows.”

Posted in Book Notes, From the Yellow Notepad, Software Engineering | Leave a comment

What’s the Right HbA1c Target?

In my most recent post I mentioned the matter of an on-going debate over the proper target for HbA1c values. I went back and listened again to the debate at this year’s EASD conference on the “right” A1c target. (You can find it by starting at the EASD webcast page and searching for “Berger”.)

The talks by Drs. Irl B. Hirsch and Andrea Siebenhofer-Kroitzsch are chock full of information, and I’ll summarize them here. I’ve also taken the liberty of including some of their slides. Any mistakes in recapping these presentation are entirely due to my limited knowledge of epidemiology and shouldn’t reflect on the good doctors arguments. Also, there’s a lot of statistics in these presentations; and while I studied mathematics as an undergraduate, I went the abstract math route and am rubbish with statistical jargon.

First, Dr. Hirsch advocated for a target of 6.5%.

  • An A1c of 6.5% works out to an average of 144 mg/dL or 7.8 mmol.
  • But 6.5% actually has a fairly large overlap with 7.0% if you use the 95% confidence intervals of each.
  • So, there’s not that much of a difference between 6.5 and 7.0%.
  • 6.5% is protective. There’s a small but significant reduction in the risk of complications with an A1c below 7.0%.
  • And there’s an “exaggerated increased risk of hypoglycemia” below 7.0% for type 1.
  • The DCCT (which suggested that there was increased risk of severe hypoglycemia with better A1c) was reported in 1993. It’s a different time now. JDRF continuous glucose monitor (CGM) studies show that risk is way down at all levels of A1c to the same as very high A1c.
  • Lower A1c values are protective for type 2 as well, but treatment is a “moving target.”
  • No matter what you target, the actual is going to be higher (often by as much as 0.5%). — So why not aim lower?
  • Furthermore, doctors have been told “additional action” is required if the A1c is more than 1.0% over the target — so people with diabetes (PWDs) often aren’t getting told to change until well into the danger zone.
  • Does the ACCORD study indicate that trying to achieve normal A1C results in increased mortality? [Yikes!]
  • As in other trials, a higher average A1c in ACCORD is associated with a higher risk of death: +22% for each 1% of A1c.
  • And with intensive treatment, the risk of death continues to decrease below 7.0% — Not so with “standard treatment strategy.” [I believe the "intensive treatment" group aimed at lower A1c.]
  • Moreover, the people with the highest risk of mortality in the study, were the people with the lowest decline in A1c.
  • The causes of death in ACCORD weren’t differentiated, though.
  • Of course, the target value is individualized based on other factors. “Clinical judgement always trumps guidelines.” “If you can’t get there, don’t push it.”

Dr. Andrea Siebenhofer-Kroitzsch used meta-analysis of several different diabetes trials to argue that we can’t tell definitively whether improving glycemic control (as measured by a lower A1c) actually helps.

  • There are many other factors that along with A1c confound what causes improved/worse outcomes. Factors such as social status.
  • So far, there are only seven randomized, controlled trials on A1c (DCCT is by far largest with 1441 patients).
  • The age of people in the DCCT were quite young, so it was hard to see macrovascular complications (such as heart disease) directly from the study.
  • And, the ACCORD study had to be stopped because intensive treatment had a higher mortality for some groups. [Seriously?]
  • Some studies showed more hypoglycemia and more weight gain with aggressive treatment.
  • Other changes are more effective in preventing complications: blood pressure, cholesterol reduction.
  • Don’t confuse intensive self-management with A1c.
  • Tight glycemic control is very beneficial for young people with type 1. Admits that people with type 1 need tight glycemic control because of length of treatment. [But type 2 is occurring much earlier in age, one audience member reminded us.]
  • Lots of open questions about the value of glycemic control.
  • Individualized treatment is more important, almost suggesting letting patients to set their own targets as long as a minimum level of outcomes are met.

Here are my reactions and some questions I had while listening to the session:

  • It’s good to see that the increased use of CGM technology can dramatically reduce the number of severe hypoglycemia episodes. Given what it costs to go to the ER, there’s another argument in favor of covering CGMs and supplies more widely by insurance carriers.
  • The meta-analysis was very . . . meta. Consequently it pushed very hard on the difference between “proof” and “connection.” A lower A1c may suggest better outcomes, but it doesn’t prove that the lower A1c caused it. I get this, but the data are compelling to me.
  • Almost all of Dr. Siebenhofer-Kroitzsch charts suggest favoring more intensive treatment, although that seemed to contradict the core of the presentation. Perhaps I don’t know how to read them correctly? [Mo meta, Mo problems.]
  • Does the fact that clinical trials never met their A1c targets mean that people with diabetes (PWDs) are going to feel even worse about not meeting A1C targets if the target is lowered to 6.5%?

Ultimately, based on the questions and comments from the audience, the debate sounded like a draw. I think I’m in Dr. Hirsch’s camp, and I would ultimately like the lowest A1c I can safely get; but I don’t think I’ve ever really been close to breaking below 6.5%. So maybe Dr. Siebenhofer-Kroitzsch’s camp and the ADA have a point worth considering carefully when looking for a number to cover all of us.

Some of Dr. Hirsch’s slides:

Some of Dr. Siebenhofer-Kroitzsch’s slides:

Posted in Diabetes, Fodder for Techno-weenies, From the Yellow Notepad, NaBloPoMo, NaBloPoMo 2009 | Leave a comment

Afternoon (basal) delight

This post is inspired by Anna in Montréal, who is adjusting her basal rates.


A Side-effect of Exercise

I have a bike. This shouldn’t be a big surprise, as I’ve written about my border-to-border and Quabbin Reservoir rides recently.

I love riding my bike, and during the warm months with lots of sunshine I rode it almost everyday. I like the sensation of rolling along, with the wind whistling in my ears and the scenery blurring by. I don’t even mind the hills anymore, even though the wind stops whistling as I crawl along.

All of that riding has been great at lowering my blood glucose reading. In fact, it’s worked a little too well. Insulin — the enzyme that helps transport glucose into your cells for energy — becomes much more effective when you exercise. And when your muscle cells slide past each other, they basically act as pumps and can work (almost) without insulin. (But not completely without.)

When I ride, I carry a waterbottle full of sports drink — Gatorade if you care to know — but I was still having hypoglycemia more often than I’d like. If you don’t have diabetes, this is commonly referred to as “cracking,” “bonking,” or “hitting the wall.” Your muscles have spent their glycogen (a form of glucose usually found inside of muscles), and your body can’t convert enough fatty acids into energy. You feel tired and find it hard to keep going.

If you have diabetes, hypoglycemia has all of these same attributes. Of course, for us it also means that our brains don’t get enough glucose either. So we’re not just tired, we can also pass out. And stopping for a little while doesn’t fix the problem. We have to replace it right away. So I try really hard not to have hypoglycemia. And as someone trying to take off a few pounds — which is going quite well, thank you very much — I want my body to turn fat into fatty acids and leave my blood glucose more or less alone. And I don’t like to drink a lot when I run, which I’m doing now that it’s dark in the evening. But, as I said on Halloween, hypos scare me.


Time to Fix the Basals

So I pulled out my copy of Smart Pumping. “Oh look! I should probably fix my basal rates as a first step.” Well, it was time to do that anyway.

For those of us with insulin pumps, basal insulin is the continuous trickle of background insulin that keeps our blood glucose in the happy/normal range of 80-150 mg/dL, counteracting the steady release of blood glucose from the liver. Why the liver does this, I don’t know. I read in my book that basal insulin should be about 40-50% of your average total daily dose (basal + food/correction boluses). Mine was about 55-60%. A sign of problems. Fixing these rates requires skipping meals and testing every couple hours. Skipping meals is hard. And if one reading is too much different than the one before, you have stop, make adjustments, and start another day.

But I wanted exercise to be easier (and last longer). And (more importantly) I was coming up on my 10-year anniversary with diabetes and had told myself that I wasn’t going to go five or ten more years just “getting by.” I was starting to be quite unhappy about all of my hypos and high readings. And I had a supportive, active new endocrinologist who wanted to help me improve my readings and my ability to predict them.

After figuring out my morning basal rates — which involved about four or five skipped breakfasts — I began my afternoon tests in late September. When I started, I was getting 22.0 units per day. (A unit is 1/100 of a mL. A vial of insulin has 1000 units.)

Four weeks, seven tests and seven adjustments later, I think I’ve figured it out. I have just one more afternoon test to go — I hope — but I think my new rates are correct. For the curious people with diabetes out there, here’s a bit of the data.


Numbers and stuff

On 26 September, my basal rates were

00:00 - 07:00 = 0.9 u/hr
07:00 - 09:00 = 1.0
09:00 - 20:00 = 0.9
20:00 - 00:00 = 1.0
(22 units per day)

The first or second test:

6 October 2009
Last basal: 4.0u at 7:42 (active insulin at 12:30 is 0.4u)
11:39 - 143
12:54 - 79
Stopped

8 October 2009 - Attempt #2 or 3
Last basal: 4.3u at 7:22
11:20 - 155
12:56 - 97
Stopped

I was checking more often than required in those early tests, because I could actually feel my blood sugar moving. I kid you not, and I had suspicious that I was going a scary place.

By 12 October, I had changed my rates to

00:00 - 0.9 u/hr
07:00 - 1.0
09:00 - 0.7
15:00 - 0.8
20:00 - 1.0

13 October 2009 - Attempt #4
11:38 - 133
13:00 - 93
14:00 - 78
Stopped

19 October 2009 - Attempt #5
11:27 - 216
12:54 - 188
14:45 - 138
15:47 - 111
Stopped

After this, I was feeling close to being there, and before my last test had already knocked off a lot of insulin.

00:00 - 0.9 u/hr
07:00 - 1.0
09:00 - 0.7
11:00 - 0.5
15:00 - 0.6

27 October 2009 - Attempt #7
Previous bolus - 07:51
10:44 - 256
11:53 - 234 (Active insulin 1.1u)
13:36 - 226
16:01 - 180
18:01 - 153

I know that last test started out with high readings, but I just wanted to get the damned thing done, and I knew that having higher readings would give me a good cushion for seven hours of testing.

Currently, here’s where I am:

00:00 - 0.9 u/hr
07:00 - 1.0
08:00 - 0.8
09:00 - 0.7
11:00 - 0.5
20:00 - 1.0
(18 units per day)

These basal tests are all about gradual refinements. If your BG readings change by more than 30 mg/dL up or down over any two hour period, adjust +/- 0.1 unit/hour starting 2-3 hours before the dip/bump. The Pumping Insulin authors also recommend redoing all of your basal tests (overnight, morning, afternoon, and evening) whenever you change exercise patterns, your weight changes 5-10%, or you suspect they’re wrong because of fasting highs or lows.

Posted in Cycling, Data-betes, Diabetes, From the Yellow Notepad, Historical Record, Life Lessons, NaBloPoMo, NaBloPoMo 2009 | Leave a comment

AMD performance counters

Here’s a little reminder for myself and for anyone on the web who’s searching for information about AMD Athlon and/or Opteron performance counters.

AMD Performance counter resources:

Less techie posts to follow . . . honestly.

Posted in Computing, Fodder for Techno-weenies, From the Yellow Notepad, Software Engineering | Leave a comment