Thursday, October 2, 2014

Cowboys vs Perfectionists vs … Body Builders

I've worked with many developers over my fifteen years of professional software development.  Sometimes I just can't help but classify them.  But I bet you've noticed this too: there tends to be two main types.


If you've never heard of unit testing or avoid it because it slows you down, you're probably a cowboy.  Cowboys can prototype concepts to prove viability before you've finished describing the idea.  They can hit unrealistic deadlines and still have plenty of time to gold plate.  A cowboy is guaranteed to get you to market before your competition.  But God help you if you put their code in the hands of end users: you'll have more bugs than a bait shop.


If your goal is 100% code coverage, you only code TDD, or you spend more time refactoring than producing customer-centric code, you might be a perfectionist.  Perfectionists write pristine, maintainable, refactorable, low-defect code.  Applications built by perfectionists will last the test of time.  The problem is it'll take them twice as long to get to production as it should and if their project doesn't run out of money first, their competition is liable to beat them to market, invalidating all that beautiful code.

Body Builders

Quick quiz: how do the most successful body builders maximize muscle mass while minimizing body fat?  Steroids of course.  Ok, how do they do it legally?  Maximizing muscle mass takes lots of lifting, lots of protein, and lots of calories.  Minimizing body fat requires cardio work and dieting.  But dieting and consuming calories are mutually exclusive.  So the answer is that body builders alternate between periods of cutting (dieting) and bulking (eating and lifting).  Neither activity alone will allow them to reach their goals.

Cowboy + Perfectionist = Cowfectionist?

So what do body builders have to do with software developers?  A fantastic software developer I once worked with used to say he felt software developers should be paid based on the lines of code they delete.  I always enjoyed his deleting code theory (clearly he was more of a perfectionist than a cowboy), but it struck me recently that deleting (refactoring) is to writing code as cutting is to bulking.  In other words if you try to do one exclusively, or (worse) both simultaneously, you're setting yourself up for failure.


We all have tendencies toward cowboys or perfectionists, but to become the most successful software developers our goal should be to alternate between cutting and bulking, refactoring and producing.  Obtaining a high muscle, low fat code base that gets to market on time with high maintainability requires neither a cowboy nor a perfectionist: it requires  avoiding extremism, embracing moderation, and recognizing the strengths of those different from ourselves.  If we can find that balance we can truly accomplish great things.

Tuesday, September 9, 2014

My Humbling Week as a Machinist

A terrible ripping noise followed by a clang and a bang echoed through the metal shop.  Everyone turned to look at me.

The bang could have been my last heart beat as I destroyed a machine that costs over $10,000.  Or it could have been a razor sharp bit cracked in half spinning through air and deflecting off my skull.  

In reality it was my the sound of the machine making an emergency stop as I hit the big red button reserved for emergencies.

Developer to Machinist

I got to this point with a goal, a chunk of time, insufficient respect for a new field, and perhaps a touch of hubris.

The goal seemed simple enough: build an aluminum mold for an injection molding machine to help mass produce a part I needed for my hobby.

I was to accomplish this goal at Techshop, a maker group that provides access to tools, information, and an awesome community.  And I was to accomplish it in a week during a vacation.

The general process I used was:

  1. Design the part in Autodesk Inventor
  2. Prototype on a 3D printer
  3. Design the mold in Autodesk Inventor
  4. Design the machining (CAM) operations in an Inventor add-on called Inventor HSM
  5. Export the CAM operations to GCode and import them into a TorMach CNC Milling Machine
  6. Run the cutting operations on a couple of pieces of aluminum (a top and bottom)
  7. Run the injection molder
Autodesk Inventor

Autodesk Inventor is an amazing CAD package that normally costs over $7,000, but as a TechShop member, not only do you get access to a fully stocked metal shop, and just about every piece of machinery imaginable, but you get a copy of Autodesk Inventor.  Fortunately the help documentation and tutorials are excellent and designing a simple part wasn't too hard.

From there I used a Makerbot Replicator 2 to 3D print a prototype and iterate a couple of times on the design.  The part, in case you're wondering will be a cap for the led column on a Siren of Shame, but it's really just an excuse for me to fiddle around and learn machining.

Mold Design

With a TechShop class on mold design I learned the key pieces of information I needed to make the mold including how to:

  • Create a sprue that the molten plastic will be injected into
  • Multiply a single part multiple times (and maintain the link to your part so you can theoretically change it)
  • Create a runner system to distribute molten plastic to the parts
  • Build gates to inject the molten plastic into the parts
  • Design vents that allow air, but not molten plastic to escape
  • Add cold slug wells to keep gasses and sediment out of your mold parts
  • Add registration pins that keep the two halves of the mold (cavity and core) aligned
  • Design your part to be easily injectible (add draft angles and fillets to every surface)

Inventor HSM

Inventor HSM is an amazing plug in for Autodesk Inventor that allows creation of 2.5D and 3D CAM operations for CNC milling machines directly from your Inventor models.  Unfortunately it's pretty new, the documentation is a little weak, and there aren't any TechShop classes on it yet.  Worse, if you don't know what you're doing many of the default cuts won't be correct, to potentially dangerous effect.  


Everything is so nice and easy right up until you have razor sharp cylindrical blades spinning up to 5,000 RPM and automatically moving along a path that you may or may not have defined correctly.

I ran my first cuts in foam to validate my approach, gain practice with the TorMach CNC milling machine, and get experience with the wide range of bits I would need (including traditional end mills for surfacing, ball end mills for runners, an end mill with a taper for draft angles, and a couple of micro bits for air channels and such).

Unfortunately, my confidence increased after I ran through my cuts in foam.  Foam, it turns out, is completely different from aluminum.  Here's a video of my first disaster.

The surfacing was fine, but I was taking too aggressive of cuts.  After a kind "Dream Consultant" at TechShop explained my mistake I was able to correct it like so (notice the difference in how the machine sounds):


Unfortunately I didn't learn that lesson until after breaking a bit, lightly injuring a collet (bit holder), and embarrassing the heck out of myself in front of a small audience.

Lessons Learned

Throughout my milling time (30+ hours) I made numerous mistake.  Anyone with woodcutting experience (or machining common sense) will probably find these mistakes amusing.  I hope others may find this list constructive:

  • End mills only cut up through where the flutes end.  You can't run a mill into aluminum above that line without bad results.  And for goodness sake don't run the collet (the thing that holds the bit) into your aluminum or even worse things happen.
  • When bits break they go flying really fast and scare the crap out of you and it's loud and everyone in the room comes over to publicly shame you.
  • Even if you're cutting with the blades of your bit you should only mill a small amount of height of aluminum at a time (1/2 the bit width max) otherwise the drill makes a bad cut and terrible noises and you risk breaking the bit.
  • End mills (the ones with an L shape) aren't for drilling.  If you do this then miniscule aluminum shreds will bind to the bit and fling around and create an invisible shield that will block the flow of coolant generating smoke, risking overheating and damaging your bit and the aluminum.
  • Design everything in your part with specific bits in mind.  It's way too easy to design something on the computer that will be nearly impossible to machine.  Going back and modifying your part after you've designed your cuts in practice is extremely hard.
  • Getting your X, Y, and Z coordinates zero values correct on the machine is kinda important. If you get Z wrong, even a few hundredths of an inch too high for example, your cuts will be in air and you could waste a lot of machine time and not be able to tell because the area is flooded with coolant.

But as the kind staff reminded me, we are here to learn and we all have to start somewhere.

The good news is I never damaged the machine (it's actually quite forgiving), I only broke one bit, and most importantly I didn't (significantly) injure myself or anyone else.


In the end I successfully milled my pieces, finished them, ran a couple of runs on the injection molder (still some work to do there as you can see below), and ultimately accomplished my goal.

All in all trying on a completely different hat for a week was both fun and rewarding.  Building something real was a blast.  I learned a ton.  But to tell you the truth as thrilling as it was to accomplish my goal, I'm just as thrilled to be headed back to a job where a screw up won't injure anyone or damage a ten thousand dollar machine.  I'm happy to be headed back slightly smarter, happier and more humble.

Tuesday, July 15, 2014

Raspberry Pi Powered Siren of Shame via Node.js

I picked up a Raspberry Pi this week and had fun connecting it to a Siren of Shame.  Naturally the Model B+ with 4 USB ports came out the day after mine arrived.  Regardless, I had fun setting it up.  If you're interested in trying it too here's what to do.

Getting Started

You'll need a Siren of Shame device and a Raspberry Pi that's running and connected to the Internet.  Element14 has a great getting started set of videos if, like me, you're completely new to Raspberry Pi.  I used the Raspbian OS, but theoretically it shouldn't matter what OS you use.


Libusb provides an API for applications to interface with USB devices, including Human Interface Devices (HID) such as the Siren of Shame.  To install libusb use apt-get (the universal Linux installer).

If this is a new Raspberry Pi with a fresh install of Linux then you will need to update your list of available packages with

sudo apt-get update

Follow that up with:

sudo apt-get install libusb-dev

You should now be able to run lsusb from the command line to list devices.  Plug in a Siren of Shame, run lsusb, and you should get a device with an id of 16d0:0646 called GrauTec.  It should look like:


Bus 001 Device 011: ID 16d0:0646 GrauTec

If your device doesn't show up, it could be an issue with the cable.  Andy Lowry, who has an excellent blog post where he lights up his siren of shame when freight trains are near, reports that he had to try several cables before finding one that worked.


Thanks exclusively to Joe Ferner and his node-sos-device project we have a solution for connecting Siren of Shame's to linux using Node.js.  To install Node.js it should be as easy as:

sudo apt-get install nodejs
sudo apt-get install npm

Incidentally, rather than using node-sos-device directly, we will be using Joe's higher-level node-sos-client, which knows how to monitor Jenkins and Bamboo CI servers.


If you haven't configured your device to work with git you could do it the right way with SSH and generate an ssh key or you could just:

git clone


cd node-sos-client

Next you'll need to download all Node dependencies.  If this is a fresh install you'll need to tell the node package manager (npm) where to retrieve dependencies from:

npm config set registry

Now you can install all dependencies for node-sos-client by running

npm install

Upgrading Node

For some fortunate users (Andy Lowry for one) installing node via apt-get works fine.  If, however, you get an error about node being out of date you'll have to uninstall, download, and update your path.

First, to uninstall the old version of node:

sudo apt-get remove npm
sudo apt-get remove node

No download and unpack:

cd ~
tar -xvzf node-v0.10.2-linux-arm-pi.tar.gz

To add it to your path

nano .bashrc

And add the following two lines at the bottom:


If you restart your command prompt and type node --version you should get v0.10.2.

Now retry npm install.

cd node-sos-client
npm install

And you should be good to go.

Running node-sos-client

First make a copy of the default configuration file:

cp config.json.example config.json

We'll configure it correctly later.  Next pick up the dependency on node-sos-device by running:

npm install sos-device

To run the app you should be able to run

sudo node build/sos-client.js

However, if you had to install node with the wget method, then you'll need to run

sudo $NODE_JS_HOME/bin/node build/sos-client.js

If you're lucky you'll see the app print out the device stats as json and a configuration error, something like:

deviceInfo: { version: 1,
  hardwareType: 1,
  hardwareVersion: 1,
  externalMemorySize: 0,
  audioMode: 0,
  audioPlayDuration: 0,
  ledMode: 0,
  ledPlayDuration: 0,
   [ { id: 2, name: 'On/Off' },
     { id: 3, name: 'Fade' },
     { id: 4, name: 'Chase' },
     { id: 5, name: 'Fade Chase' } ],
   [ { id: 1, name: 'Sad Trombone' },
     { id: 2, name: 'Ding!' },
     { id: 3, name: 'Plunk' } ] }
Failed to poll: bamboo0 { [Error: getaddrinfo ENOTFOUND] code: 'ENOTFOUND', errno: 'ENOTFOUND', syscall: 'getaddrinfo' }

However, if you have a cable that doesn't work well, or are connecting through a non-powered USB hub you may see:

Error: usb_detach_kernel_driver_np: -113 could not detach kernel driver from interface 0: No route to host

In this case try experimenting with the way you connect the device to the Pi.

Configuring the Connection

Today node-sos-client can connect to two CI servers: Bamboo, and Jenkins.  To connect to Jenkins update the config file to something like:

  "builds": [
      "type": "jenkins",
      "config": {
        "url": "",
        "username": "[username]",
        "password": "[password]"

And you're done.  With any luck running sudo node build/sos-client.js will light the siren and sound the speaker on initial connection, and whenever the build breaks.


I hope you've enjoyed and are now on your way to terrorizing your build breaking colleagues, even when you're not at the office.  Enjoy!

Monday, June 16, 2014

App for the Windows.Launch contract failed with error: The app didn't start

If you're developing a Windows Store app and you get the error:

...App for the Windows.Launch contract failed with error: The app didn't start

in the following Event Log:

Applications and Services Logs\Microsoft\Windows\Apps\Microsoft-Windows-TWinUI/Operational

The error may be caused because you attempted to install your app via a dism installation and then attempted to deploy it via F5 deployment in Visual Studio.

To verify this is the case you can run:

dism /online /Get-ProvisionedAppxPackages

If you see your app listed you can then remove it with:

dism /online /Remove-ProvisionedAppxPackage /PackageName:[packagename]

You don't even need to log out and log back in.  Hope that helps someone somewhere.

Wednesday, February 19, 2014

Six Techniques for an Effective Retrospective

If a non-agile team were to adopt one single agile technique, what would it be?

My answer, without a doubt, is a regular retrospective.  Why?  An effective retrospective allows you to continually improve your process.  It allows you to add in the other Agile techniques, gradually, as your team is ready for them.  Over time it can be the gateway to a fully agile process that is completely customized for your team.

But there is a fine line between an effective retrospective, and a gripe session that that fails to lead to process improvement.  These six techniques can help you get the most out of your retrospectives.

1. Prepare items before-hand

One of the most important steps for an effective meeting is to have a clear agenda.  Asking team-members to prepare retrospective items ahead of time lays an specific agenda which facilitates:

  • Allocating an appropriate amount of discussion time per item
  • Producing more well thought out, higher quality suggestions
  • Knowing when the meeting is over

2. Centralize items in a repository

Specifying a central location such as a Google Docs spreadsheet or a SharePoint list that team-members can add to as items occur to them can further increase meeting effectiveness.  Not only can team members see and prepare to respond to other team members, but it represents a history of changes, and can provide more structure in entering items.

3. Identify problems and solutions

Unstructured retrospective items submitted by team members seem to come in one of two forms:

  1. Solutions in want of a problem; and 
  2. Problems without a clear solution 

Both types of submissions aren't necessarily bad, but they can lead to ineffective process changes or long discussions that fail to result in meaningful change.

The most effective retrospectives I've seen ask team members to present both a problem and a solution.  By separating off the two sides of the coin the group can decide as a team if there are perhaps better solutions that fit the problem.

4. Revisit old solutions

If a team member has identified a problem and the group has arrived at a process change, how can the team be sure that the solution fixed the problem?

The best approach is to have the team revisit old unresolved items at each retrospective.  If the solution solved the problem, resolve it.  If not, postpone for another meeting or propose another solution.

5. Focus on process, not individuals

Invariably person X will do something to upset person Y.  Then Y will want to bring the issue up at the retrospective.

Having a problem/solution format will help discourage airing personnel issues, but proactive leaders will want to establish some rules ahead of time to encourage team members to work out issues outside of the retrospective to keep the meeting focused on the team's process.

6. What went well

While no concrete changes typically comes from a "what went well" section of a meeting, a pat on the back never hurts, can keep morale up, and can encourage team members to keep doing the good parts.


With a little extra structure your retrospectives can be shorter, more results-oriented, and more effective.  Why not give these tips a try at your next retrospective?

And if you aren't doing retrospectives?  Schedule your first, you won't regret it.