Jeff Mather’s Dispatches

The 9 to 5 Life of an International Playboy

  • Home
  • A Miscellany of New England Iconography
  • Exercise Data
  • To Do
  • Work Syllabus

Thoughts from a Thursday Morning

Posted in August 12th, 2010
by Jeff Mather in Baseball, Book Notes, Color and Vision, Diabetes, Health Care, Life Lessons

In honor of the company meeting earlier this morning, here are some of the things I’ve learned and thoughts I’ve had this morning . . . bullet point style:

  • I can’t decide whether Arcade Fire’s new album, “Suburbs,” is completely, utterly pretentious and lacking in fun, or if that’s me I’m thinking about.
  • The second week of August may be the second best commuting week of the year. It has felt like the week between Christmas and New Years.
  • The reception areas of Newton-Wellesley Hospital (NWH) are under construction, and the architects created a display of the materials they’re using. I like that a lot.
  • Phlebotomists, who specialize in doing something inherently painful with a minimum amount of discomfort, aren’t paid well enough. I’ve been poked many times, and the ones who do it well really are amazing.
  • The NWH lab dedicated to drawing blood is extremely quick. It’s where I prefer to go. It opens at 8:30.
  • At 7:00 the main hospital lab claimed a 30 minute wait, but it was really an hour-long wait for 60 seconds of actual medical procedures.
  • Some days I’m really eager to get to work and finish up what I was working on the day before. Today was one of those days.
  • In early April, Sports Illustrated predicted the Chicago Cubs would finish second in the NL Central, with a record of 81-81. To make that happen, the Cubs will have to go 33-15 for the rest of the season. The Cubs also have an estimated payroll of $137M for the season, which is $100M more than the team one behind them, the Pittsburgh Pirates. (The Pirates!)
  • I should have brought a book with me to the lab. I just finished reading about platypuses and have started reading about Romantic science.
  • I was smarter during the company meeting. Now I know a lot more about “Black-point compensation: theory and application” and ICC color profile rendering intents than I did yesterday.

And now it’s time to muck around with run-length encoding.

read more from this topic.....

3 Comments

The Checklist Manifesto

Posted in March 24th, 2010
by Jeff Mather in Book Notes, From the Yellow Notepad, Health Care, Life Lessons, Software Engineering

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:

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

read more from this topic.....

No Comments

Australia Planning

Posted in March 15th, 2010
by Jeff Mather in Australia, Book Notes, Life Lessons, Travel

This weekend we did a lot of trip planning. Preparing for an undertaking of this size — four weeks in three varied regions of a continent — is always a fine balance between ensuring that we have a place to sleep at night and leaving enough freedom to do whatever we want with a bit of spontaneity. I think we’ve pretty much done what we need to do, and we can relax again for a while.

About six weeks ago we bought our tickets to Sydney after devising a rough, month-long plan. And then we didn’t do much until a few days ago.

Well, that’s not exactly true. We did get our tourist visas online. I’m a little sad that we won’t get full page documents pasted into our passports like when we went to India, but it was a lot less expensive and much more convenient than sending away our passports to the Australian consulate. In fact, the whole process took less than five minutes for the both of us.

We also debated whether to get an RV for our trip through the Northern Territory or to hop between towns with a rental car. In the end, we decided to go half/half: We’ll carry our home with us on our backs as go from Darwin to Alice Springs; and then we’ll drive point-to-point hitting up the desert parks in the “Red Centre.” I have grand visions for this part of the adventure, at the same time that I’m a bit intimidated that the first vehicle I’ll be driving in Australia (on the left side of the road) will be a 22-foot, manual-transmission RV.

And it took us a while to figure out which part of the reef we wanted to visit. I had great hopes that we’d be able to spend a few days on a resort island on the reef itself. But, even though we’ve been saving for a couple years, neither of us could justify spending the same amount for one night on the island as for a full-week rental of a condo 20 yards from the beach. Especially, when you consider that there’s a two night minimum.

But we eventually got the big things figured out. So we bought all of our domestic airline tickets and booked all of our hotels over the last few days. I discovered that the Australian version of Expedia had the same airline tickets at half the price of the US site, even with our credit card’s “foreign transaction fee” and the currently poor exchange rate. Bonus! Of course, this did end up triggering the credit card company’s fraud protection system, and I had to contact about it  . . . twice. But it was so worth it. (Update: Also consider Wotflight.)

I’m glad all most of those decisions are made. Picking hotels is hard. Picking the right RV or rental car is hard. Finding the right flights is hard. I get wicked buyers’ remorse on almost everything I do online. In the back of my mind, I’m sure that I spent too much for not enough. I’m slowly getting over that . . . slowly.

So what’s left?

Well, I still have to rent a car or two and an RV. And I need to make sure that our health insurance will travel with us.

And I want to learn a little bit about Australia. Just enough so that I have completely the wrong idea about the place. So I think I’ll start with some fiction. My friend recommended Peter Carey, Tim Winton, and Sally Morgan (especially her autobiography My Place, which probably isn’t fiction).

Better add another book to my never-ending list.

read more from this topic.....

2 Comments

The Keystone Initiative: A Checklist Success

Posted in February 26th, 2010
by Jeff Mather in Book Notes, Health Care, Life Lessons

From Atul Gawande’s The Checklist Manifesto: How to Get Things Right, p. 44:

In December 2006, the Keystone Initiative [which used checklists in the ICU and integrated executives to help remove roadblocks] published its findings in a landmark article in the New England Journal of Medicine. Within the first three months of the project, the central line infection rate in Michigan’s ICUs decreased by 66 percent. Most ICUs — including the ones at [Detroit's troubled] Sinai-Grace Hospital — cut their quarterly infection rate to zero. Michigan’s infection rates fell so low that its average ICU outperformed 90 percent of ICUs nationwide. In the Keystone Initiative’s first eighteen months, the hospitals saved an estimated $175 million in costs and more than fifteen hundred lives. The successes have been sustained for several years now — all because of a stupid little checklist.

This is the kind of thing that has to happen in every department of every hospital if we’re going to have affordable, first-class healthcare everywhere in the US. Unlike some other changes this one is relatively easy to implement and costs very little, with almost immediate payback.

read more from this topic.....

No Comments

Checklists

Posted in February 18th, 2010
by Jeff Mather in Book Notes, Computing, Life Lessons, Software Engineering

We use checklists a lot at work. They help us reduce waste and ensure a high quality product. If we’ve run into a problem before, we’re likely to run into it again, so we might as well go down the checklist of “Did you think about this?” and “Did you do that?” items before submitting code into the repository.

But our checklists have gotten a little long and messy, which raises the risk that people won’t use them at all. Part of my job is to improve our team best practices and checklists, so I’m working out how to make all of those checklist-bound countermeasures fresher and more accessible.

So I’m very hopeful that Atul Gawande’s The Checklist Manifesto: How to Get Things Right, which arrived on my desk today, will give me some in-the-trenches perspective. I’ll keep y’all posted on what I learn.

read more from this topic.....

No Comments

Implementing Lean Software Development – Part 1

Posted in February 11th, 2010
by Jeff Mather in Book Notes, From the Yellow Notepad, Software Engineering

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

read more from this topic.....

No Comments

A Different Kind of Reading

Posted in November 28th, 2009
by Jeff Mather in Book Notes, NaBloPoMo, Travel, USA, Western Adventure

Lisa and I made it home from Wyoming to find the house still standing, the heat still working, and the kitty still happily away at his little resort until tomorrow afternoon. We have completely unpacked, and Lisa even set out all of the Christmas decorations. That’s a little easier to do this year, since we aren’t decorating a tree. We love getting a Christmas tree, but it doesn’t make sense to put one up just to let it dry out while we’re spending the week around Christmas in Oregon.

I was a bit nervous about today’s journey. Casper was forecast to have two inches of snow, starting right around the time this morning that we were to leave. And somehow I got us a the Casper to Denver to Chicago to Boston itinerary with tight layovers of less than an hour at each stop. But after the frustrating travel experiences we had last month on our way to and from Kansas, we had good travel karma today. We even walked out the door at baggage claim just as the Logan Express to Framingham rounded the corner. That never happens.

We very much enjoyed spending time with my mom and seeing friends in Wyoming, but it’s nice to be home. Nice to be back to sea level. To be back to my pile of reading.

While my two shelves of books will persist into the new year, my periodicals stack won’t. At the beginning of the year I set myself a goal of cleaning up the big shipping box full of various magazines and issues of the New York Times Book Review that I had amassed over the two and a half years that I was in grad school. What I haven’t finished at the end of the year goes into the recycling. “Out with the old” and all that.

Sadly, I haven’t made much progress throughout the year. But I did manage to read a bunch of magazines on the flights last Sunday and today, so maybe there’s hope after all. The Runner’s World article on 1980’s hurdling phenom Danny Harris, who destroyed his career with cocaine, and the National Geographic Adventure feature on a new hiking trail across Nepal were my favorites. The Scientific American article from last year about how the Large Hadron Collider will likely reshape physics reminded me that when I was younger I wanted to be a particle physicist. Oh well, something more to read about next year.

read more from this topic.....

3 Comments

I Just Can’t Read 55

Posted in November 7th, 2009
by Jeff Mather in Book Notes, General, NaBloPoMo

I’m going to take a break from diabetes today — writing about it, at least.

I rearranged my reading list this morning, finally acknowledging the fact that it had spilled over onto another shelf and that it wasn’t shrinking nearly as quickly as I had hoped.

Two full shelves of books to read
Fifty-five books. (Click for larger. . .)

There would be fifty-six, but this afternoon I finished a short book on the life and works of Gustave Courbet, the nineteenth century Romantic/Realist French painter, bad boy, and Communard. This continues a trend of reading about notable French painters: Eugène Delacroix, Jean-Auguste-Dominique Ingres, and Édouard Manet. If you look closely, you can see Ross King’s The Judgement of Paris there on the shelf. I’ve read about a third of the interesting — if somewhat passion-free — book about Meissonier, Manet, Monet, the revolution in French painting, and the birth of Modernism and Impressionism.

The truly sad thing is that shortly after I finished reading the aforementioned book about Courbet, instead of picking up The Judgement of Paris, I went to Amazon to see what books I could find about Jacques-Louis David. This, if nothing else, demonstrates that I’m a depth-first learner. When I get interested in something — 19th century French painting, for example — I tend to get really into it. But as you can see from my reading list that spans two freakin’ shelves, I get distracted (or maybe “burned out” is a better phrase) and move on to something else.

(Fortunately, there really are very few books available about just J-L David. So one day I’ll get myself over to the Newton Free Library and settle in for an evening of reading about a truly revolutionary figure.)

I’ve been thinking about this aspect of my personality recently. I don’t have this “problem” of amassing too many books and then losing interest in subjects at work. Well, not anymore. Ever since I switched over to a leaner, “just in time” learning mindset a few years ago, I’ve been doing much better. So why can’t I do that away from the office? Why doesn’t that whole Getting Things Done ™ mindset carry over at home? Who knows?

Anyway, I feel like I should do something about my reading list — short of just shelving the books elsewhere in the library. I don’t read quickly enough to read a book a day. Reading one a week might be pushing it, but it seems like a worthy goal.

Ask me after Christmas how I’m doing.

read more from this topic.....

No Comments

Book Recommendations

Posted in April 29th, 2008
by Jeff Mather in Book Notes, OPP, This is who we are

I’ve been reading a lot. That’s the benefit, I guess, of only having one class last semester. And I want to share with you some recommendations.

But before that, here’s a simple request. Currently I’m between books and having a hard time figuring out what to read next. Classes don’t start for another three weeks, and I have the ambition to read something on the longer side. So maybe I should read that book that Leslie suggested: Michael Chabon’s The Amazing Adventures of Kavalier & Clay. Then again, I still have The Plot Against America from the last time I went to the bookstore; and I’m trying to do better about reading what I buy.

What do you think? What should I read next?


Okay, here are my recommendations. Just be aware: I’m rubbish at giving short synopses that don’t totally suck the life out of whatever I’m recommending.

Apex Hides the Hurt by Colson Whitehead. An enjoyable novella about names, branding, growth, change, race, and (ultimately) ourselves. Tantalasia: “An emotional state, that muted area between desire and consummation.”

Willing by Scott Spencer. You might think I’d be apprehensive about recommending a novel about a down-on-his-luck author who goes undercover to take a high-priced sex tour, since it makes me sound a bit bawdy and the description will likely drive all sorts of unexpected traffic to my site. But I’m a sucker for a well-told, ambiguous morality tale that attempts to divine what our morals are in the Internet age. (p.s. – What’s up with not using quotation marks in fiction these days?)

Harry Potter and the Deathly Hallows by J.K. Rowling. I have to admit that I like Harry Potter. I came to the party late — mostly because Lisa wanted to talk to me about book #5 — but I was very anxious for its release last year. If I remember right, I read the whole thing in, like, 20 minutes.

The Worst Hard Time: The Untold Story of Those Who Survived the Great American Dust Bowl. Timothy Egan wrote an amazing book about the plow that literally broke the prairie and the folks on the southern Great Plains who toughed out the Dust Bowl. That period of American history is far, far worse than I had fathomed.

China Road: A Journey into the Future of a Rising Power. Rob Gifford is my everyday hero: smart, self-deprecating, ruggedly handsome. All of these fine attributes come through in the travelogue of his cross-China trip. Along the way he talks to politicians, dissidents, students, farmers, hermits, truckers, hookers, entrepreneurs, . . . everybody. And as NPR’s long-time China correspondent, he draws from a deep, deep well of knowledge and cultural sensitivity.

Terra Nullius: A Journey Through No One’s Land by Sven Lindqvist. Perhaps there’s something that gets lost in the translation of this book; yet despite its imperfect execution, it is a very thought-provoking treatise on collective guilt, reparations, and the legal fictions Europeans used to justify taking other people’s land. I was amazed to learn that Australians are just like Americans, only more so.

Foto: Modernity in Central Europe, 1918-1945. It would have been hard for this thick catalogue from a really wonderful exhibit at the National Gallery of Art to disappoint. But strange things happen in the world of art catalogues. Sometimes the images from the exhibit aren’t in the books. Or there’s no text. Or the text that does appear is hopeless art speak. This book has none of those problems. It’s as fresh as the Central European photographs it covers.

read more from this topic.....

No Comments

Photobook Club

Posted in August 1st, 2007
by Jeff Mather in Book Notes, General, OPP, Photography

I’m just throwing this proposal out there and hoping someone has an idea or two of how to achieve my goal. So please reply.

I like photobooks. Monographs, surveys, collections, criticism . . . it doesn’t matter.

I like reading and discussing books. The latter usually happens with Lisa and our friends via book club. But photobooks aren’t really what they’re into. (I can understand.)

Books of photography can be pretty expensive, and I try to respect copyrights. So scanning large portions of books just to discuss them isn’t something I would really do. Aggregating from the Internet is possibly a different matter.

Any suggestions about how to start (and sustain) a photobook club? Either virtual or in-person.

read more from this topic.....

No Comments

Color by Numbers

Posted in February 23rd, 2007
by Jeff Mather in Book Notes, Color and Vision

At the recent medical imaging symposium I bought myself a copy of Daniel Malacara’s Color Vision and Colorimetry: Theory and Applications from the SPIE Press. I managed to read the short monograph on the five hours of flights from sunny, warm San Diego to freezing New England.

It’s not exactly an elementary book, but it covers the mathematical basis of colorimetry. Unlike my article on color vision, Malacara draws upon a lot of research and presents the essential equations of color science — at least those that relate to color measurement.

This is one of the rare books on color vision that leaves the human visual system to the end. In fact, the cone response functions are among the last topics discussed. Instead, this short work of about 150 pages takes a more or less chronological approach to colorimetry, starting with a few fundamentals on colorful light, progressing through basic trichromatic systems (like RGB, XYZ, and xyY) and uniform color systems (such as Munsell, CIELUV, and CIELAB) before ending at color mixing and measurement.

It’s quite a good book for those needing concise definitions and equations. Many diagrams and full-color images complement tables for color matching functions and color transformation equations. In a few places the text is overly terse, and my only wish is that Malacara would have provided a bit more context around some of the equations explaining where some “magical” values come from.

But, all things considered, it’s a work that belongs on the bookshelf of anyone who works with color as numbers.


read more from this topic.....

No Comments

Software Development as Ye Olde Craft Economy

Posted in January 4th, 2007
by Jeff Mather in Book Notes, Software Engineering

My group at work has just started reading Implementing Lean Software Development by Mary and Tom Poppendieck. As with any other reading group, the communal experience encourages us to read something that we might not pick up on our own. Because the books are (hopefully) relevant to our vocation, discussing them together helps us find ways to apply what we learn. We haven’t started discussing this book yet, but already I am intrigued.

For the uninitiated, Lean Software Development applies the core principles of lean manufacturing (as embodied in the Toyota Production Sytem) to software development. In particular, the process attempts to eliminate waste, build quality into a product, and continuously improve the development process. The authors admit that software development isn’t the same as manufacturing automobiles or clock radios, but I’ve managed to suspend my disbelief and see how well the principles apply. Perhaps at a later time I will recap what I’ve learned from the book.

But for now I would like to go off in a tangential direction inspired by the authors’ brief history of organized manufacturing from its birthpangs in 18th century Europe, through the interchangeable parts revolution that exemplified the American System of manufacturing, continuing on to the Ford that used interchangeable semiskilled labor and parts, to lean manufacturing at Toyota. But it’s that earlier, pre-manufacturing period that interests me now and seems so applicable to software development: the craft economy.

Imagine a craft economy. It’s hard to do. Everything is made and then made again but slightly differently. Two craftsmen build two things using their own unique toolsets, and the results are often incompatible or just different enough to require learning how to use it and make it costly to fix when broken. When the craftsman needs a new tool, she typically goes to her own machine shop and builds it specifically for the purpose.

I’m not disparaging craft economies. Some — most? — of the world’s superlative things were produced by craft economies: the pyramids, Chartres Cathedral, illuminated manuscripts, Sputnik. And there’s something charming and old-timey about one-of-a-kind goods. But craft work is incompatible with modern production; primarily because it’s expensive to produce lots of individual things.

Is software development in the “craft economy” milieu?

By and large, every company is doing things differently. There are few standard practices, and what standard practices do exist — such as agile methodologies — are implemented quite deifferently. Software developers also have a dearth of tools to use; common wisdom says that it’s often easier to build your own toolset than to adapt existing offerings to the problem at hand. To be sure there are a few basic off-the-shelf tools that everyone uses — compilers, standard libraries, and code editors — but not every software group uses other essential tools: revision control systems (SCMs), rapid prototyping languages, automated testing systems, etc.

Most companies build components in-house for their own products but few commoditize these tools in ways that other development groups can use them. Of course, Java, COM, and vendor foundation classes do exactly this, but these are just a drop in the bucket of all the functionality a software developer needs to solve a particular task. There is a dearth of reusable code for purchase or free download.

Contrast software development with the manufacture of physical goods. Toyota and GM have a large number of vendors who build components that are to a great extent reusable by anyone: sheet metal, bolts, spark plugs, tires, radios, electronic control units, etc. Despite being rather sophisticated, radios from different vendors fit in the same hole (compilation), can easily be wired into any car (APIs), and have similar user interfaces. While there are specialized tools for specific tasks, for the most part, a wrench set is a wrench set is a wrench set. Tools vary in terms of price, durability, and the part they fit, but they are usally applicable to a wide variety of tasks.

In lean production, manufacturers avoid holding inventory, and parts arrive “just in time” for use. In software development and other knowledge work, teams are prized for their depth of knowledge and the expertise that they can apply to problems — not necessarily just novel problems. Groups need this experience because someday they may need to call upon it to resolve a problem almost identical to one they have already solved. Often extra frameworks are built into APIs needlessly because the engineer has a hunch what may be useful in the future, essentially storing knowledge in the product long before it is needed.

These thoughts should not be considered an indictment of software development. Clearly adopting some aspects of mass production (lean or otherwise) will translate into lower development costs; but should software engineering really be more like mass production than craft? Craft guild members experienced significant hardships when interchangeable parts gave birth to assembly lines, even rioting. Does the concept of a “software supply chain” make sense right now? What we call “software engineering” is still largely invention; the necessary conditions for software mass production may still be years down the road.

All things considered, I think the emergence of software mass production based on truly reusable components and a just-in-time supply chain is closer than most expect. Two factors will likely propel us there: open source projects and the net effect of business process outsourcing.

In my job I use a lot of open source software libraries . . . sometimes incorrectly called free software. (Free software definitely has lots of hidden costs: time spent learning an API’s syntax and capabilities, time spent interfacing two different products, time spent reviewing license agreements, etc.) These open source projects run the quality gamut, but the best provide first-class code that implements 90% of the functionality anyone would need for a given task. For my group that means reading and writing image and scientific data formats. Because using a library can easily save $100,000 in development costs (not to mention opportunity savings and the ability to bring new products to market quickly) the for-profit world is embracing open source, even if components aren’t really interchangeable yet. Some large companies, such as Adobe and Apple have placed discrete parts of their products into open source projects partly to encourage others to develop for their “platforms” and engender trust in their products.

Software project outsourcing currently accounts for a very small portion of overall software development. As software becomes more modular, it will be possible to shift even more small tasks to places where skilled or semi-skilled can do it more cheaply. (This is part of Thomas Friedman’s thesis in The World is Flat.) Furthermore, if companies like Infosys, Wipro, and Tata can hold onto the intellectual property from BPO projects, they have a perfect opportunity to create interchangeable software parts. Lots of small to medium-sized interchangeable components available at low or fixed cost: that sounds a lot like a supply chain to me.

What are your thoughts? Is there a software craft economy? Is mass production of software around the corner? Is software development too closely tied to invention or too different from making widgets to be comparable to manufacturing?

read more from this topic.....

No Comments

Professional Software Development

Posted in October 4th, 2006
by Jeff Mather in Book Notes, From the Yellow Notepad, Software Engineering

Going through some old e-mail at work, I found this review of Steve McConnell’s book Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers that I wrote for my group a couple years ago. It changed my perspective on my career a bit and helps explain why I’m in a software engineering master’s program.

McConnell’s central point is that software development is not living up to its full potential. Anyone who has ever read any part of Code Complete shouldn’t be surprised to find that McConnell blames improper software construction and project management practices for some of this. Professional Software Development goes further in arguing that the software profession lacks the level of rigor that other professional careers have and that it needs to get it. In the book’s four sections, McConnell first surveys the problem and then focuses on individual, organizational, and industry-wide ways to build a better software engineering profession.

In the first part, “Software Tar Pits,” McConnell examines (with data) why software projects fail. The most frequent cause of software project failure is requirements problems. Beware of “last-minute syndrome”; continual progress or tool-building is necessary at all times, and project leaders should look daily at how much progress was made. Beware of not preparing and doing “code and fix” development. Changing requirements is the most common source of cost/schedule problems because “software isn’t soft.”

For McConnell the reason why software developers get into these “tar pits” is that most code creators (often despite their other skills) lack formal software engineering skills. The use of the word “engineering” is intentional and is intended to reflect both a training methodology and a level of professionalism. Computer science is research-oriented, with a goal of advancing knowledge; software engineering, on the other hand, is application-oriented, with a goal of applying knowledge and problem solving. Software engineering principles deal with the “essential difficulties” of software development; software is complex, changeable, must conform to messy reality, and is difficult to visualize. Fortunately, the “stable core” of software engineering’s professional knowledge is pretty well advanced in dealing with these complexities. Information doesn’t get shared around enough, and we just haven’t been well trained in this core knowledge:

  • SW requirements
  • SW design
  • SW construction
  • SW maintenance
  • SW configuration management
  • SW quality
  • SW engineering management
  • SW engineering tools and methods
  • SW engineering process

According to McConnell, these are the core competencies that software engineers must have (to varying degrees depending on their job).

In part two, “Individual Professionalism,” McConnell discusses what individual software engineers should do to improve their proficiencies. Much of this is unremarkable: start with professional education and develop skills in a practical setting. But to be a full professional requires more controversial steps: certification and licensing. (It’s worth noting earlier than McConnell does that professionalism and high-quality aren’t necessarily synonymous and that most software developers won’t require the stringent requirements of certification or licensing. As the risks to the public and the novelty of the applications increase, McConnell feels the need for professional accountability–along with legal accountability–also increases.)

The characteristics of great designers include

  • A large set of standard patterns to apply to problems
  • Mastery of tools
  • Being drawn to complexity
  • Curiosity
  • Seeking out criticism
  • Experiencing and learning from failed projects
  • Not being afraid to use brute force during discovery, and
  • A desire to create and apply knowledge.

In the third part “Organizational Professionalism” McConnell uses data from the literature to suggest that team cohesiveness and an organization’s use of best practices are bigger contributors to team success than individual qualities. Having good developers is important, but the biggest schedule/cost improvements come from merging principles with creativity. The best organizations know the rules aren’t one-size-fits-all and have the confidence to break them and trade certain principles in favor of others.

Projects need specialization in the core knowledge areas listed above as much as companies do. The larger the project, the more specialization is needed in the areas of construction, design, planning and tracking, business management, QA, and requirements. Even ad hoc, this leads to better follow through and ownership.

Some interesting statistics from this section of the book include the gem that the return on investment of improving practices has been measured at 500-900%. That doesn’t include harder to quantify benefits such as faster time to market and improved customer confidence. Another one is that the typical effort in months for a project is 2.94 * KSLOC ^ 1.1, where KSLOC is number of lines of code (in thousands) that a project will require. NASA’s Software Engineering Lab, which is one of the best, does much better 1.27 * KSLOC ^ 0.986. They’re actual more efficient with larger projects.

It’s possible to measure the level of maturity of a software organization using the SW-CMM model. Companies fall into one of these levels:

  1. Initial: Chaotic, underperforming, unshared knowledge, “heroic” or code-and-fix development. This is the default level of most organizations.
  2. Repeatable: Basic program management practices vary project-by-project, shared responsibility, falter with novel problems.
  3. Defined: Standardized PM practices across the organization, process group, training, projects are on-time/budget, more advanced than code-and-fix.
  4. Managed: Highly predictable results, stable processes, database of project data for effectiveness analysis, organization-wide processes for all projects.
  5. Optimizing: Continuous/proactive process improvements, results are measurable and measured, QA focus on defect prevention, root-cause analyses.

Research shows that the SW-CMM method is cost-effective, allows risks, doesn’t lead to extra bureaucracy, but does take a while to implement (on average 3 years per level) and is costly.

In chapter 16 McConnell lays out an interesting, laddered professional development plan for software engineers that organizations can use. The system is the one his company uses, and it measures engineers’ proficiencies in the knowledge areas listed above (putting them into five broad competencies); has plans for training, mentoring, and public recognition of improvement; is tied to salary; and presents a roadmap for becoming a “professional.”

McConnell revisits that idea of a software engineering profession in the final part of the book, “Industry Professionalism.” It seems to be the most controversial section, though it really shouldn’t be. According to McConnell’s thinking, software development is already on the way to becoming an engineering field, despite having a ways to go. When it finally arrives at the professional stage–which comes after commerce is wed with science to produce a high quality, dependable end-product–certification and licensing will be the recognition of the status quo. Customers will expect important software to behave well and will be able to hold one or more licensed individuals who worked on the product civilly or criminally liable. That might sound extreme but the potential of some software to do harm (or good for that matter) is just as great as the “products” of other professionals (doctors, lawyers, civil engineers, etc.).

Certification is voluntary and shows proficiency in a field. Licensing is not mandatory or universal but might be required by some jurisdictions when accountability is required. (Consider that your friend can do your own taxes and you can blame no one if things go wrong, or you can use a CPA and have legal recourse in the case of negligence or ethical violations). McConnell estimates that only 1-5% of all software professionals will need licensing.

Beyond that, the industry as a whole has an enormous responsibility to the public trust to act in a professional, ethical manner. Moreover, the industry should do a better job applying computer science and software engineering knowledge that was developed many years ago and is currently unused.

On the whole, Professional Software Development is a compelling, well-argued read. However you feel about its most controversial parts, if you construct, test, or manage software, it is well worth being familiar with the issues that will likely affect your career in the next decade or so. Beyond that, I found it contained a very compelling argument for seeking out and fixing the inefficiencies in individual projects and throughout the whole organization.

read more from this topic.....

No Comments

Afro-pessimism

Posted in October 1st, 2006
by Jeff Mather in Book Notes, OPP, Photography

I am enjoying reading (slowly) Okwui Enwezor’s short introductory essays in Snap Judgments: Contemporary African Photography. The first of three essays concerns “Afro-pessimism,” the constructed view of Africa through pictures (mostly) as grim, on the precipice of disaster, deficient, retrograde — a place where “nothing good happens.”

It’s quite the provocative, fascinating essay asserting that contemporary “Western-made” images of Africa dehumanize it, pushing the continent to the “margins of life,” where it ceases to be a concrete reality in the perpetuation of the “colonial fantasy.” Enwezor rightly argues that “these stories are no longer plausible.” The photographs in Snap Judgments strive to change the discourse; Enwezor wants to return Africans from their image-bound “spectrality and transience.”

This is another example of “the West versus the rest,” in which Africans are treated as the “other,” living in worlds of myth and image that are different than how Africans experience Africa. Enwezor considers these images to be an extension of the early history of photography where wealthy Europeans and Americans took their cameras to appropriate the images of Africa in a kind of photographic sport. The Westerner’s camera becomes a “vampire machine,” sucking the life out of the continent. This sort of cultural appropriation for purely selfish reason continues 150 years later in tourist and Western “fine art” photography: “Why would anyone want to photograph people with whom there is mutual estrangement?”

Enwezor writes that Westerners photograph Africa the way they do — appropriating disasters such as famine and genocide — because the press (and by extension the public) prefer images of African suffering. It enables us to fulfill a white knight fantasy, where we attempt (infrequently and half-heartedly) to save Africa . . . if not Africans. Which begs two questions: What is the photographer’s ethical responsibility in reaction to what they see? And, what are the viewers’ responsibilities? There’s a paradox that he acknowledges: images of African suffering perpetuate that suffering. If the continent is lost — if it’s perpetually in danger, if we can’t help these living ghosts — what’s the point of trying to save it.

In the exhibition and catalogue, Snap Judgments attempts to bring Africa back from the brink that non-Africans believe it is at. He wants to add a new layer of criticism to looking at imagery, to present “multiple ways of representing African life and space,” to bring African photography (and Africa) into the now. The photographs don’t necessarily present a new “African aesthetic” (though they may for all I know). They aren’t exactly photogenic, and they aren’t antiphotogenic either (in the way of Robert Adams). But what he wants to is to show African urbanization, transformation, and self-expression.

It’s worth a look.

read more from this topic.....

No Comments

Book Notes: The Looming Tower

Posted in September 7th, 2006
by Jeff Mather in Book Notes, This is who we are

I read a lot of book reviews. They’re great: You can stay current on the state of ideas and always have something to talk about at parties; but you don’t have to read the whole book. But the Times‘ book review of Lawrence Wright’s The Looming Tower: Al-Qaeda and the Road to 9/11 was so compelling that I needed to read it myself. In the spirit of giving back, here are some notes about the book.

I approached the book with the prospect of trying to understand al-Qaeda and Islamist extremists. I suspect that I had earlier totally misunderstood the Muslim Brotherhood as it emerged in Egypt and later took root and inspired others elsewhere. If Wright is correct — and I suspect he is in this copiously researched and well-written book — it was born as an opposition to colonialism and its nationalist / socialist / modernist / capitalist alternatives. To Sayyid Qutb and other seminal figures in the Brotherhood, Islam was an all-encompassing system to remake the post-colonial world. Qutb, who actually studied in America, returned in the late 40’s scandalized and radicalized. Qutb savaged our supposed depravity and regarded the U.S. as propping up regimes that the majority in the Middle East didn’t like, as well as being a good friend of Israel and opposed to Islam — complaints we still hear today.

Decades later, Ayman al-Zawahiri (whose al-Jihad group would later merge with al-Qaeda) saw the U.S. as an enemy and a target because of our superpower status. Wright suggests that the genesis of 9/11 was in the Egyptian prisons of the early 1980s. Many Egyptians — especially Islamists like Qutb and Zawahiri — wanted their repressive government overthrown and saw US aid as propping up anti-democratic and secularist regimes. Zawahiri’s scope at the time was limited to change in Egypt, but his desire for retribution against westerners was, in his words, “all encompassing.”

Early chapters in The Looming Tower present biographical sketches of ideologues, extremists (or soon-to-become extremists) and powerful men in the Arab world. While introducing the Saudi intelligence chief Truki al-Faisel, Wright paints a picture of Arabian religiosity and fervor that could quickly lead to violence in defense of faith and the instiutions (like Turki’s) that sought to maintain the delicate status quo. It shows currents (though perhaps only minor undercurrents) in Islam and Arab, Egyptian, and Persian history that likely lead to the current religious, transnational violence. Wright suggests that many Arabs thought the Arab fighters in Afghanistan were odd, even as they donated large sums of money to the cause. He also presents fault lines within Islam concerning jihad and the se of violence against non-Muslims and (eventually) other Muslims. Still, there were many who venerated death (not unlike early Christian martyrs) and began to see themselves as stateless actors once they (as radicals) became personae non gratae in their home countries. Clearly the Afghan war was another galvanizing event in violent radicalism.

Afghanistan, where the Arabs (and Americans and Pakistanis) financially supported the mujaheddin and sent disaffected and pious young men to martyrdom, is almost anticlimactic in this retelling. (Steve Coll’s Ghost Wars: The Secret History of the CIA, Afghanistan, and Bin Laden, from the Soviet Invasion to September 10, 2001 is much better here.) But it’s supposed to be. The Arabs did little more in the battles than direct money and make favorites for the international community. But for them it was a critical time. We see a struggle for the soul of jihad between “moderates,” whose goal was to expel the Soviets, and takfirs, aiming at worldwide religious purification via the murder of everyone who stood in their way. Bin Laden’s dream of creating an Islamic state (and a name for himself in the process) played a crucial role.

After Afghanistan fell into chaos, bin Laden returned home to a country oppressed by religious police and poorly governed — essentially the Taliban with petrodollars for a small elite who largely held themselves apart. The description is reminiscent of Qutb and Zawahiri’s Egypt but with far more religious control over society. It would seem that Saudi Arabia is almost exactly what all Islamists had desired, except for the royal family which bin Laden denounced. Within a year of his return in 1989, the Saudi kingdom would host American troops. (The United States appears relatively late in the narrative.)

Not long after the end of the first Gulf War, Osama bin Laden was expelled to Sudan. Al-Qaeda was aimless and ideologically lost, but America (which really knew nothing about it) became its threat as the superpower whose cultural and material influences are so contrary to bin Laden’s world view; and we were, in his mind, blocking the resurrection of a pan-Islamic caliphate. Sharia and social control were the counterforces to capitalism and liberty. And al-Qaeda wanted the U.S. to engage in “a war with Islam — ‘a large-scale front which it cannot control.’” Bin Laden started reaching out to several older terrorist/Islamist organizations. Though not part of al-Qaeda, Ramzi Yousef aimed to destroy symbolic targets (albeit with significant casualties) and economic targets in the hopes of encouraging retaliation that would unite Muslims. In 1993 he attempted to level the World Trade Center towers using a truck bomb. The same year, Zawahiri began using suicide bombers in Egypt and elsewhere, a trend which quickly spread to other groups. Extremism in the Middle East was still diverse but seemed to be coalescing in ideology and techniques. Yet, the groups still lacked popular support.

The Taliban weren’t sure about bin Laden when he returned to an even more lawless and brutal Afghanistan after the U.S. pressed Sudan into expelling him. But the Taliban’s antipathy to all things modern or “Western” (or Indian for that matter) aligned well with bin Laden’s worldview. In Tora Bora he fully developed his millenarian mythology and formally declared war on the U.S. He lacked resources — and was in most respects an unstable failure — but met Khaled Sheikh Mohammed, who had grand visions of how to wage the kind of war that bin Laden and Zawahiri wanted.

The American counterterrorism and intelligence community was seriously dysfunctional in the 1990s. The CIA and NSA didn’t want to share intelligence. The FBI sounded like macho-cop good-ole boys. The political situation barely appears in the analysis, which is perhaps a point Wright is trying to make. (Of course, the Islamists may just be more interesting or exotic.) Wright concentrates most of his narrative efforts on John O’Neill, the FBI agent who later died in the World Trade Center attack, and the mostly nameless group at the CIA’s “Alec Station,” which followed Islamic terrorism. It’s clear even from this limited narrative that the intelligence community had not begun to penetrate or understand Islamic terrorist organizations.

But the al-Qaeda and al-Jihad organizations seemed similarly disorganized, fractious, and ideologically inconsistent. Bin Laden and Zawahiri were tangentially related to several terrorist actions but provided training and ideology for several suicide attacks in Egypt, Saudi Arabia, and Africa. These missions fragmented the cause and lost the hearts and minds of the people they tried to rally to their cause. Meanwhile, ineffectual U.S. “pinprick” actions against bin Laden in Sudan and Afghanistan elevated him in the esteem of his erstwhile community and (especially) in his own mind. He was thoroughly outside the control of the Saudis, the U.S., and the Taliban.

At the same time, the nature of “jihad” was changing to include the young, the disaffected, the criminal. Though martyrdom was still a primary concern, many of these young men — mostly upper-middle class and well-educated — were not fervently religious at the outset. What they “tended to have in common . . . was displacement.” These are the children of transplanted families or students away from their families, people “with little standing in the host societies where they lived.” In part, terrorism becomes a problem of diaspora, a failure to assimilate or be welcomed: “marginality” is Wright’s term. Ironically, the disaffected and the impressionable found safe havens in open, libertarian societies — the very kind of societies they seem most opposed to and yearned to destroy.

Wright’s description of the time surrounding the U.S.S. Cole bombing is perhaps the most challenging passage in the book in light of what happened later. The FBI was stymied in its investigations by the CIA, which withheld information that could have also easily led to the discovery of the 9/11 plot. (The CIA comes across worst of all American groups in this book.) The State Department hampered the FBI investigation in Yemen because of the best of diplomatic intentions and the pettiest of personality differences. Foreign governments actively obstructed American efforts and gave protection to al-Qaeda. And a weakened White House lacked engagement and the political will to do much of anything during an election year, including retaliation or coordination of the government message.

These same pointless barriers between the intelligence services continue until the days before Sept. 11, 2001, where Wright’s narrative essentially ends. As the Times‘ reviewer noted, other works have covered the actual day of the attack in much more detail. Nevertheless, I found the description of the attacks (as witnessed by FBI agents in lower Manhattan) extremely moving and difficult to read.

Ultimately, this book raises as many questions for the careful reader as it answers. Given all of the problems that the American intelligence and counterterrorism infrastructure had, is it now organized to effectively combat al-Qaeda and other extremist groups? Is there a downside to closer integration of intelligence and law-enforcement agencies? Could the domestic attacks really have been prevented? Are the conclusions of the Congressional 9/11 Commission correct? Has the world post-9/11 been effective in combating terrorism, whether its ideological underpinnings or actual terrible effects?

Perhaps just as challenging are the questions it should pose about contemporary society. Is this view of Islam or the Arab world balanced? Despite Wright’s compelling arguments and copious sourcing, I’m still left wondering how much al-Qaeda’s ideas reflect the prevailing mood of the region and how the average citizen experienced the same governments that bin Laden and al Zawahiri did. This says more about my and the West’s lack of understanding of Islam and the region, the polarization of American views post-9/11, and tension between liberal and secular multiculturalism and other value systems. What I still don’t know — what I was unable to glean from Wright’s rather narrow history — is how people in the Middle East view jihad; whether they admire, despise, or ignore the ideas of Qutb and the Muslim Brothers (much as people in the South now universally reject segregation, secession, and Jim Crow except in all but the most isolated and sociopathic cases); whether they want an Islamic empire with its union of religion, politics, and law; if they see the current religious groups as distinct from post-colonial, anti-despotic resistance; etc.

In his defense, Wright does present a lot of causes that came together to create al-Qaeda: post-colonial struggles, anti-modernity, a desire for a caliphate, anti-Zionism, anger at America, Soviet invasions, lack of opportunities for the young in rich Gulf countries, violent strains of Islam that were nurtured in the formation of contemporary Arabia, fixation on holy death, a sort of fear of Western or powerful women, and so on. I find it incredible that all of these could occur in one short span. It’s possible to read The Looming Tower and get some sense of the disorientation that likely occurred to many in the region over the last fifty years of globalization. Wright seems to suggest that all of these factors combined to produce violent extremism and goes out of his way to point out that bin Laden was the sine qua non of radicalism, the critical “symbolic figure of resistance” worldwide.

My review really doesn’t do justice to the compelling narrative that Wright creates, which (apart from what it tells us about the contemporary world) alone makes it worth reading. And yet the book is packed with ideas without feeling ponderous or partisan. So go read The Looming Tower for yourself.

read more from this topic.....

No Comments

Recent Entries

  • Basal Insulin, Bolus Insulin
  • New Video File Formats
  • Aussie Photos
  • Heading Out
  • Thoughts from a Thursday Morning
  • Clean Office!
  • Ten Things I Love about Adobe Photoshop CS5
  • Salt – Lake Eyre by Murray Fredericks
  • At Once Familiar and Strange
  • Aussie Photos – Part 4 (Birds)

Recent Comments

  • Jacquie in Basal Insulin, Bolus Insulin
  • Karen in Basal Insulin, Bolus Insulin
  • Ashley in Basal Insulin, Bolus Insulin
  • Leslie M-B in Basal Insulin, Bolus Insulin
  • Jeff Mather in Basal Insulin, Bolus Insulin
  • VirtueB in Basal Insulin, Bolus Insulin
  • Alyssa in Basal Insulin, Bolus Insulin
  • the poor diabet… in Basal Insulin, Bolus Insulin
  • Lorraine in Basal Insulin, Bolus Insulin
  • Rachel in Basal Insulin, Bolus Insulin

Social Network

  • Subscribes to feed
  • Stumble this site main post
  • Add to my Technorati favourite

Translators

French German version Spanish version Italian version

Categories

  • Always the bridesmaid
  • Australia
  • Baseball
  • Book Notes
  • Burying Grounds
  • C
  • Central Asia
  • City of Light
  • Color and Vision
  • Commonwealth Project
  • Computing
  • Crusty Old Paint
  • Cycling
  • Data-betes
  • Development
  • Diabetes
  • Diabetes Blog Week
  • Europe
  • File Formats
  • Fodder for Techno-weenies
  • From the Yellow Notepad
  • General
  • Health Care
  • High Tension
  • Historical Record
  • History
  • Hoarding
  • I am Rembrandt
  • I like type
  • India
  • Large Format Camera
  • Life Lessons
  • MATLAB
  • MetaBlogging
  • NaBloPoMo
  • New York
  • OPP
  • Photography
  • Running
  • Software Engineering
  • This is who we are
  • Travel
  • Uncategorized
  • USA
  • Video
  • Western Adventure
  • Worthy Feeds

Archives

  • August 2010
  • July 2010
  • June 2010
  • May 2010
  • April 2010
  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • October 2007
  • September 2007
  • August 2007
  • July 2007
  • June 2007
  • May 2007
  • April 2007
  • March 2007
  • February 2007
  • January 2007
  • December 2006
  • November 2006
  • October 2006
  • September 2006
  • August 2006
  • July 2006
  • June 2006
  • May 2006
  • April 2006
  • March 2006
  • February 2006
  • January 2006
  • December 2005
  • November 2005
  • October 2005
  • September 2005
  • August 2005
  • July 2005
  • June 2005
  • May 2005

Pages

  • Home
  • A Miscellany of New England Iconography
  • Work Syllabus
  • To Do
  • Exercise Data

Blogroll

Meta

  • Log in
  • Valid XHTML
  • Valid CSS
  • WordPress
  • Theme Author
©2006 Jeff Mather’s Dispatches
Powered by WordPress | Talian designed by VA4Business, Virtual Assistance for Business who's blog can be found at Steve Arun's Virtual Marketing Blog