3D Printing Board Game Pieces

For Christmas I bought Robot Turtles for the family. It’s a great game, and very easily customizable for different skill levels.

Although the cards are nice, I thought it would be fun to to go from the card playing pieces to 3D printing from ShapeWays.  I came across a turtle model on ShapeWays and contacted the designer asking if they could be extended to support the color schemes (and possibly the addition of lasers on the back.  A few weeks later a TMNT variant of the turtles appear on his shop.  Next ShapeWays purchase I included the little turtles in the request. Read on for pictures of the turtles.

Read more of this post

High Confidence/Low Information vs High Accuracy/Low Information Estimates

Quite often estimates are needed where there is low-information, but a high-confidence estimate is required.  For a lot of engineers, this presents a paradox.

How can I present a high confidence estimate, when I don’t have all the information?

Ironically, this issue is solved fairly easy by noting the difference between high confidence and high accuracy estimate.  A high confidence estimate is defined by likelihood that a task will be completed within a given timeframe, while a high accuracy estimate provides a prescribed level of effort to complete the task.  This article presents a method of balancing a high confidence estimate balancing analysis effort against accuracy.

This is a refinement on the “Getting Good Estimates” posting from 2011.

Read more of this post

Desk-Checks, Control Flow Graphs and Unit Testing

Recently, during a discussion on unit testing, I made an inadvertent comment about how unit testing is like desk-checking a function.  That comment was treated with a set of blank stares from the room.    It looks like desk-checking is no longer something that is taught in comp-sci education these days.  After explaining what it was, I felt like the engineers in the room were having similar moments I had when a senior engineer would talk about their early days with punch cards just after I entered the field. I guess times have changed…

Anyway…

What followed was a very interesting discussion on what Unit Testing is, why it is important and how Mocking fills in one of the last gaps in function oriented testing.  Through this discussion, I had my final Unit Testing light bulb moment and it all came together and went from an abstract best-practice to an absolutely sane and necessary best practice.  This article puts out a unified view on what Unit Testing is, is not, and how one can conceptualize unit tests.

Read more of this post

Root Cause Analysis; Template and Discussion

A typical interpretation of a Root Cause Analysis (RCA) is to identify parties responsible and apportion blame.  I prefer to believe a Root Cause Analysis is a tool to discover internal and external deficiencies and put in place changes to improve them.  These deficiencies can span the entire spectrum of a system of people, processes, tools and techniques, all contributing to what is ultimately a regrettable problem.

Rarely is there a singular causal event or action that snowballs into a particular problem that necessitates a Root Cause Analysis.  Biases, assumptions, grudges, viewpoints are typically hidden baggage when investigating root causes.  Hence  it is preferable to use a somewhat analytical technique when faced with a Root Cause Analysis.  An objective analytical technique assists in removing these personal biases that make many Root Cause Analysis efforts less effective than they should .

I present below a rationale and template that I have used successfully for conducting Root Cause Analysis.   This template is light enough to be used within a couple of short facilitated meetings.  This contrasts to exhaustive Root Cause Analysis techniques that take days or weeks of applied effort to complete.  In most occasions, the regrettable action is avoidable in the future by making changes that become evident in a collective effort of a few hours to a few days.  When having multiple people working on a Root Cause Analysis, this timebox allows analysis within a day.

Read more of this post

RAID – Interrelation of Risks, Issues, Assumptions, Dependencies

I find that I am often describing the differences between a risks, issues and assumptions.  A simple way to cluster these together is with the acronym “RAID”.  This is an acronym describing the

Risks
Assumptions
Issues
Dependencies

Similar to how a SWOT analysis has Internal/External and Positive/Negative dimensions to the acronym expansion, we can consider the same for RAID.

Monitored Unmonitored
Future Risks Assumptions
Now Issues Dependencies

You actively monitor, taking actions as necessary for Risks and Issues, but you declare Assumptions and Dependencies, and don’t take any ongoing actions beyond occasionally confirming or challenging them.  If an assumption or dependency fails a challenge, it will most likely move being an issue or a risk.  Arguably, under close examination most assumptions and dependencies can usually be treated as a risk or an issue. Read more of this post

3D Printing Shelf Pegs [Updated]

Update: The internet is a wonderful place.  Shortly after posting this, I received contact from one of the commenters below.  Through a short discussion, it looks like one of the readers went on to buy 100 sets (400 pegs) from the Shapeways link.  I have them listed at Shapeways manufacturing cost only, but I feel I profited in helping the world in such a little way.

When buying a house, you always find that there are some parts of the house that the previous owner had something installed, and the bag of spare parts and the supplier they used are lost to antiquity.  This some times only gives you the option of replace, hack, or just live with it.  This happened in the house we bought last year.

The shelves in the kitchen don’t have your standard Ikea style shelf pegs that hold the shelves up.  Neither do they have the standard shelf pegs you can buy at home depot.  These are custom jobs created by some unknown manufacturer.  Not only are the non-standard pegs, but the holes they fit into are not only custom, they are a funky insert, twist and lock style.

After a discussion with a colleague at work I thought I’d 3D printing.  After going through a bit of a process, I ended up ordering a set from shapeways.com.  Here is the comparison of the original with the new.

New and old pegs

Read more of this post

Using Regression Isolation to Decimate Bug Time-to-Fix

Software defects generally fall into two primary classifications: defects that represent functional misses of a new implementation, or defects that are regressions in the behaviour of the system due to some change.  This paper discusses a major reduction in the Time-To-Fix for regressions.  In a previous role I lead a team of engineers in implementing this system.

To improve the Time-To-Fix, it was ultimately determined that we needed to resolve two problems that accounted for the majority of the time developers spent dealing with regressions:

  • Reduce effort to isolate the regression.  Early effort on bug analysis can be greatly accelerated if the guess-work on which change causes the regression is removed. Using bisection provides an absolute level of confidence of the regression trigger.   There is no guessing or supposition.  I have written on the use of bisection in preference of code diving in this blog post.
  • Ensure that the regression goes to the correct team the first time. Reduction of the bouncing around of the defect report is achieved by identifying the engineer who regressed the issue and ensuring that it is fixed by that person or team.  In particular breaking the attempt to reproduce, debug, re-queue cycle prevents days of wasted engineering time.

We implemented and deployed the system described between 2008 and 2010. Read on for more information.

Read more of this post

Follow

Get every new post delivered to your Inbox.