June 17, 2014 Leave a comment
Short form presentation of how engineers can easily make judgements on Return on Investment. Also on SlideShare
Musings on Software Engineering, Management & Other Stuff
April 27, 2014 Leave a comment
We’ve seen badges and gamificiation appear in everything from a core business plan (Foursquare & Gowalla) to navigation apps (Waze). I’ve seen them on a user homepage at least two companies. It helps get people engaged by bringing together groups of common interest and drive involvement in tasks that they might not otherwise be involved in. You look up a colleagues and find they’ve done something similar to you.
The problem with the virtual badges is that they are too cheap to make (effectively free to create a new one) and only appear when you go to the employee’s homepage. Having played with 3d printing, I realized that you could make these badges in real life and bring a bit of physical interest to the work place, applying the same rules. With a few minutes on an online 3d modeling tool, online 3d printing services, and finally a magnet and some super glue, you can easily end up with full color sandstone badge.
March 4, 2014 Leave a comment
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.
February 20, 2014 2 Comments
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.
February 3, 2014 Leave a comment
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…
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.
November 19, 2013 Leave a comment
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.
July 11, 2013 1 Comment
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
Similar to how a SWOT analysis has Internal/External and Positive/Negative dimensions to the acronym expansion, we can consider the same for RAID.
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