Here are the slides from my “Functional C#” talk at devLink. Enjoy.
Archive for category Posts
In August I’ll be giving a talk on lean software development at devLink. Preparing for this is a true delight. I’ve loved these ideas since I first read W. Edwards Deming back in ’91. A decade later I cheered like a sport fan as Agile ported much of the substance to software development. Fun ride, and really important stuff.
Tonight I’ve been reading up on a concept that has a Dr. Seuss name “poka-yoke”, but is one of the most grown-up things we do: mistake-proofing.
Wikipedia: Poka-yoke (POH-kah YOH-kay) is a Japanese term that means "fail-safing" or "mistake-proofing". A poka-yoke is any mechanism in a Lean manufacturing process that helps an equipment operator avoid (yokeru) mistakes (poka). Its purpose is to eliminate product defects by preventing, correcting, or drawing attention to human errors as they occur.
The idea is if you spot a hazard remove the hazard so bad things don’t happen. Microwave ovens are a great example. Say it’s a special night, Dr. Who is about to come on and you’re microwaving a delicious frozen burrito. The opening music…
…is playing, you run into the kitchen, 12 seconds remaining, you open the microwave door, poke at the burrito and it is perfect (no cold chunks and it hasn’t split down the middle either), it’s just right, and you sprint with your feast back to the TV faster than a Dalek can screech “EX-TER-MIN-ATE!”. Even if you don’t realize it, the best part of the night was that your hand wasn’t cooked to the bone. Huh? Because some thoughtful engineers (perfect grown-ups) said “Ah! Poka-yoke! We had better put a cutoff switch to stop the death ray if the door is opened.” Thanks to the civil-spirit of man looking out for fellow man, you get to keep your burrito-hand even when you forget to press the off button.
Other examples of poka-yoke:
- the drain hole near the top of a bathroom sink basin (prevents spillover)
- match books (strike on the back so the whole book doesn’t ignite)
- unit and integration tests
- dangling clearance bars at parking garage entrances
- managed code (malloc leaves bruises)
- round manhole covers almost everywhere except the occasional Reuleaux triangle manhole cover in hilly San Francisco
Heck, remember “The Catcher in the Rye”? The book gets its title because Holden Caulfield wants to be a human Poka-yoke. He imagines a hay field that spills over a cliff and up there kids are running around oblivious to the danger. He wants to catch them (in the rye) before they plummet to their deaths. Holden’s heart was in the right place, but a better plan might have been to mow the field, or erect guard rails, or in a full Lean system Holden could have activated the Andon to stop the line. Definitely a quality control problem when kids are running around falling off cliffs.
Another great, fun book is The Design of Everyday Things by Donald Norman. It includes many examples of products with mistake-proofed designs and other designs that amplify mistakes. The bad designs really bother Mr. Norman, and hell they should really bother all of us.
So why did I say “grown-up” earlier? Because I mean it as much as I ever mean anything. Like my father, when I see a broken bottle on the sidewalk, I pick it up and dispose of it. Why? Because I believe in civics. Because I possess empathy. Because the broken bottle is a dangling pointer to sadness that can be avoided. Poka-yoke is at the core of what makes a parent a good parent, an engineer a good engineer, a programmer a good programmer, a human a good human.
When you write code are you on the lookout for hazards to your users and colleagues? Diligence and compassion are not forms of gold plating, they are what should be expected. Think about your development tools, and the frameworks you use? Do they make “doing the right thing” easier and “doing the wrong thing” harder? Or the other way around? How much do bad tools cost society? More to the root problem; how much does the short-term, local optima phrase “well that’s their problem” cost society? Would you say over the past 50 years that Wall Street, Detroit, and our government are the sorts that pick up glass or the ones that throw the bottles? What leads to this behaviour? What would the world look like today if these three groups had earnestly seen value in poka-yoke since WWII?
Ayende recently announced a groundbreaking addition to the Rhino suite of tools: the Rhino Linked List
Lets all pitch in and help him maximize market penetration by contributing…
Your Best Rhino.LinkedList Ad Slogans.
Tweet your slogans with a “#linkedrhino” hashtag to help the cause.
The original source artwork is available here (format Gimp XCF) if you want to do something really special. Winners will be announced in two weeks unless I get bored or forget.
Enjoy!
“An IDE is either with us or against us.”
I use Visual Studio 2008 SP1 and Resharper 4.5 to develop a WPF-based ERP system. Visual Studio 2008 SP1 introduced a lot of pain. For the past half year I’ve experienced a dozen IDE crashes a day. Some hotfixes have helped, “Siverlight Tools” helped, but overall things have been rotten, and Resharper, as necessary as it is, has amplified the bugs that infest the core of Visual Studio. – Please save us MEF! –
Here are the worst of the problems, and some workarounds that have returned me to ranks of the civil-tongued.
- Out of Memory Exception: While developing WPF, if I made the fool-mistake of building while a XAML document was open I would receive “Unknown build error, ‘Exception of type ‘System.OutOfMemoryException’ was thrown.’ ” in the build output. No amount of “Rebuilding” or “Cleaning” would allow a build to succeed. The only fix was to shut down Visual Studio and restart it.
- “Microsoft Visual Studio is Busy”: Several times a day (again while developing a WPF apps) Visual Studio would show an hourglass, and the nasty tray icon “Microsoft Visual Studio is Busy” would appear. Again no cure, but to shutdown and restart Visual Studio.
- “Disappearing IDE”: While coding a WPF app, I would be– typing code, typing code, typing c… Whap! No more Visual Studio. No error. No harddrive-chatter-drama, just Poof! Gone. There was no chance to save any changes, but at least this bug did half of the task of shutting down and restarting Visual Studio for me.
The fixes:
Fix #1 : Ilya Ryzhenkov[.] and Andrey Serebryansky of JetBrains pointed me to this fix for the OOM (“Out of Memory Exception”). Details:
OutOfMemory exceptions are often caused by address space fragmentation in Visual Studio process. For users experiencing excessive OutOfMemory exceptions we provide a tool which overrides Visual Studio’s memory allocation policy to ensure more continuous address space for Common Language Runtime.
Fix #2 : VS2008 SP1 sometimes hangs irretrievably after WPF Designer.
Fix #3: Silverlight 2 Tools. This helps the random crashes when editing XAML, but alone was no match.
Bonus Fix: Steve Harman’s post on permitting Visual Studio to gobble more than 2GB RAM.
Footnote:
As part of my Visual Studio de-spaz-ificaton program I uninstalled and reinstalled Visual Studio 2008. Don’t know if this step was a necessary one, or just part of the time-honored ritual: uninstall Visual Studio, throw chicken bones, reboot, reinstall Visual Studio, mumble hexadecimal incantations, reboot.
My thanks to the people that created and presented these fixes, and to the people that created the original bugs: I guess you can cancel that restraining order.
Bryan Hunter is currently serving his 15th year in the War on Visual Studio
Alpha. Dog.
May 19
Tried out Wolfram Alpha the other day. Safe to say it did not become self-aware during my interrogation.
Maybe Wolfram Beta will be better.





