Lesson from the flaming BBQ - people who just get it

I was hosting a BBQ over the summer, giving me a chance to use my very rusty "grill master" skills. Stepping away from the grill for just a few moments, I looked back to see huge flames spilling out of the grill. Luckily for me, one of the guys nearby just stepped in and quickly turned down the heat. He didn't track me down and notify me of the flames, ask me if it was okay, or delay in any way – he just did it. By the time I got back to the grill and all was calm, he casually mentioned turning down the heat. He had done many BBQs before, and he just "got it".

That's what a good team wants from its developers – people who just get it. They see a fire, and deal with it. Sure they keep management informed, but they don't make management a bottleneck with and endless stream of questions. These are developers who write that extra null-check, create the defensive code that defaults to a safe value if a param is missing, make a safe business assumption for a validation rule, upload a tool or patch to a shared drive so the next guy can easily get it, you get the idea… In each case, they could do it the "wrong" way, but they risk that and do it anyway.

I think this ultimately stems from management. First, management needs an atmosphere that encourages common-sense risk. Micro-management creates an aura where developers are scared to do the slightest action without multiple levels of approval for fear that no matter how obvious it may seem, it was the wrong thing. If you see the hamburgers burning, but you're not "allowed" to touch the grill, you'll just sit and watch dinner burn, and no one wins. Second, management needs to delegate and encourage and build up developers to take such "risks".  Start small. It's much like a parent training their kids. Sure eventually someone guesses wrong (say they pick the wrong default validation rule and hence need to re-code it), but if they got the previous nine right, then your team comes out ahead. It sure beats eating charcoaled burgers because the team has been trained to only allow managers to turn down the grill.

Measure what you actually care about

Our three kids are currently 2, 4, and 6. We are starting to potty train the youngest. She's a cute thing, but you can imagine it's always a trying experience. Because I'm very anti-ivory-tower, and think the best developers are the ones grounded in the practically of everyday life (such as potty-training a two-year old), I can't help but think how this relates to software engineering.

Here's how: we found ourselves rewarding our daughter every time she successfully went potty. It sounded reasonable, but we remembered that it's actually misleading – we're rewarding the wrong thing. What we really want is not a two-year old that goes potty every 20 minutes in order to earn her chocolate-chip, but rather a two-year old that remains dry. Even two-year olds can figure out how to game the system.

This sort of misguided measurement is what often occurs in demoralized IT shops. For example, the main compensation is based on the number of bugs fixed or number of UI screens created (because it's easy to measure), but what they actually care about is increased functionality or quality. The irony is that this often encourages the exact opposite of what the boss really wants. Just like I don't want  a two-year old going "tinkle" every 20 minutes, I don't want developers gaming the system by fixing large quantities of irrelevant or duplicate bugs.

The blog post doesn't have a quick answer, I mainly just wanted to write about my daughter's potty-training adventures while she was taking a nap. But a quick approach is to focus on what you actually care about (say quality), and then work backwards thinking "what would high quality look like", such as less production complaints, les support time, less application down time, less developer time spent fixing bugs, etc… Then focus how to measure those things.

If you're going to fail, fail big – example with dirty towels

After showering the other day, I needed a towel to dry off.  I saw a bunch of towels in a nearby laundry basket, but wasn't sure if they were dirty laundry going downstairs, or clean laundry coming upstairs. I was too lazy to walk down the hall to get a towel from the closet that I knew would be clean, and the towels in the basket looked clean, so I used the ones from the basket because they were immediately available. But it didn't feel "right". I started feeling bits of lint and loose hair on me, so I did the most thorough test I could find – I phoned my wife and asked her if the towels in the laundry basket were clean or dirty. She informed me that they were "of course" dirty towels used as floor mats.

Like every other aspect of normal life, I see this directly analogous to software coding. The dirty towel is like a defect. If it was obviously dirty, I never would have used it, hence saving myself the grossness of drying myself with a floor mat. Applied to software: Better to have a defect explode in your face so that you're forced to fix it, as opposed to a "half-bug" that continually bites you.

Real life: Avoiding customization to build a Sandbox

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/real_life_avoiding_customization_to_build_a_sandbox.htm]

I have three kids - two sons and a daughter. Cute little buggers, so I wanted to make them a sandbox to play in. I figure doing something physical and outdoors, as opposed to watching TV, would be good for them. Plus, I'm all for anything that even remotely encourages them to do engineering. However, I have very, very, minimal wood-working skills. When it comes to woodworking, I am (at best) a hobbyist - by no means an expert. This means I was just trying to build a simple sandbox that works - no fancy wood cutting, things that take big vocabulary to describe, or expensive tools required. I made a crude box-like design, drove to the local home depot, and got help picking out the wood (12x1x6 inch cedar). The only cuts I made where ones that the home depot guy could do in the store - so no triangle, notched, or diagonal cuts. I hauled my precious wood back to my garage (read: not professional tool workshop), applied one coat of polyurthethane something (read: I hope that helps protect against weathering), and hammered the boards together. After digging the box into the ground and filling it with sand, it was good enough and I was done.

Why dump such a story on my technical blog? Because my hobbyist mentality towards a wood sandbox is essentially the same as many "programmers" hobbyist mentality towards the craft of software engineering. We both just want to get it done, make the end users happy, and maybe enjoy it along the way. If we miss out on an optimal technique, that's okay. Working with other people, it can be useful to understand that mindset.

And yes, the kids loved it.

 

Real Life: Copying code is easier than copying snow dinosaurs

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/real_life_copying_code_is_easier_than_copying_snow_dinosaur.htm]

In Chicago, we get snow at the end of March. The warmer weather makes the snow packy, so we could finally do useful things with it, like make snow dinosaurs:

 

Actually, it was just one snow dinosaur - which brings me to my point: In the physical world, it's expensive to reduplicate work. For each snowball, I need to find an open patch of snow (material) and manually roll the ball (labor). Unlike software, I cannot just create the "code" once and copy it five times. It's not like some million-line application framework that you can just reduplicate with a single copy command. Hence, after an hour of exhausting snow-ball rolling and lifting, to my son's disappointment, we stopped at just one snow-dinosaur. Now if we just made a Silverlight game with snow dinosaurs, we could add as many as we wanted.

Real life: Taking down the Christmas lights and project failure

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/real_life_taking_down_the_christmas_lights_and_project_fail.htm]

In Chicago, we've had another cold winter. Finally, we got a reprieve as it got warm enough for the snow to melt. I looked outside at our 25 foot (?) pine tree, and saw my opportunity to take off the lights. I had done this before, and I figured it should be a quick "project".

However, as luck would have it, things did not go well. The winter wind must have pushed the lights closer to the tree trunk, and entangled them in the branches. I had borrowed someone else's extension pole to initially put them out, and returned it, so I did not have the ideal tools. Regardless, I started out working on the bottom of the tree - close to the ground where I had the most maneuverability, and things seemed optimistic. However, as I worked on higher and higher branches, it got slower. At first I thought I'd just "tough" it through, perhaps with the job taking 2-3 times longer than I thought, but things just screeched to a halt at the 15-foot mark.

With the long strands of lights entangled in all the branches, I had no choice but to actually cut the lights. I thought that I had found my solution, so now it would just take 4-5 times longer than scheduled, and I'd need to throw away the lights. But, at the 20-foot mark, I didn't even have the tools with which to cut the lights. Now I was desperate - it would be a fire-hazard to have openly-cut electrical lights hanging on a tree 20 feet in the air. So, I broke down and drove to the hardware store. The guy found an old Christmas-light extension pole, complete with claw for grasping lights to pull them down (i.e. the right tool), and I returned home with new hope.

Finally, with this new tool, I could finish the job - behind schedule and with a mess of cut-up lights for garbage. It almost felt like a software project.

Real Life: Taking the fridge door off

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/real_life_taking_the_fridge_door_off.htm]

 To fix a normal squeaky door is relatively easy - just tap out the axle that joins the hinges, oil that, tap it back in, and... no more squeaky hinge. After the 20th such hinge, I got the hang of it. So, whenever my wife says the hallway doors are squeaking (translation: "please fix them"), I'm looking forward to an easy task. However, the other day she mentioned that the fridge door was squeaking. Now that was an issue. Taking off one hinge at a time for a hallway door is easy - but fridge doors aren't built like hallway doors, so you need to take the entire door off. Taking off the entire fridge door is hard (at least for me). But, alas, there was no other way. So, I got out the necessary tools, and took the entire fridge door off, oiled the door axle, and... it too stopped squeaking! The moral is that, just like in software development, people often need to take one step back before taking two steps forward. Maybe that means throwing away precious code, reading a long article instead of just jumping to a quick solution, writing a unit test harness, or something. The current problem might require you to "take the fridge door off".

Real life: Automation and teaching your kids

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/real_life_automation_and_teaching_your_kids.htm]

We have 2.5 kids. Cute little bunch - but very dependent on Mom and Dad. Every few minutes, they come back to us, needing something. Of course, our goal is to teach each kid to just take care of things - brush their own teeth, pick up their toys, eat their food, etc... And then, ideally they could string all these acts together and just take care of themselves for some time on end. Especially as the older one learns to do this, it frees us up to focus on other things - like the young one throwing toys at the wall. Especially with the second, and third, you realize that you don't scale - there are too many kids per parent - you need to make them self-sufficient, at least for a time.

 

This reminds me much of automated process. Both ideally could be on autopilot. Both come back to me asking for help (my console app burped on a bad xml input file, my service didn't handle the machine restart, my build script crashed on spaces in a filename, etc...). While it's cute to initially have your pet application that you baby-sit and marvel in awe of how well it churns through those calculations, soon you'll have a new pet application, and you'll need that first one to be self sufficient.

 

One more similarity - you hope that one day they'll both make you rich. The kid will strike it big and take care of Mom & Dad in their old age, and those .Net applications will keep delivering business value and keep you employed. [just kidding]

 

Although, of course the analogy breaks down because the kiddies are so much cuter, but you get the idea...

Real life: the leaking window

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/real_life_the_leaking_window.htm]

House repairs provide a lot of good software analogies. Once during a big rain storm, our window started leaking. It was a newly installed window, and it had never leaked before. Well, obviously a leaky window can become a huge problem if left unfixed. So, I went out sometime later, sprayed the window with the hose to try to get an idea of where the leak is (I was not, and still am not, a house repair expert), and to my great frustration - the window did not leak. Of course I wanted to reproduce the problem, narrow it down to the exact cause, and then make a quick fix - just like I would in a software project. I didn't want to rebuild the whole thing.

So, here is a "critical feature bug" (the leaky window), which occurred in "production" (during the actual rainstorm), but I cannot reproduce in my "development environment" (sunny day with my spraying the window with a hose). It was a non-reproducible bug. However, I couldn't just ignore it or look the other way, I needed to ensure that it didn't happen again (given that it's my house, I need to take "ownership" of the "project"). It's the kind of thing that drives a software project mad.

In this case, I just 'blindly" resealed things - checked the siding, exterior frame, interior, etc... And the window never leaked since. If it does end up leaking again, then I'll probably need to call an expert, much like how some doomed software projects sometimes call in a star consultant to troubleshoot their obscure bugs.

Real life: How do you test a sump pump?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/real_life_how_do_you_test_a_sump_pump.htm]

Back when we moved into our home (a while ago), this was our sump pump.

As home-owners knows, sump pumps are very important because without one, your basement gets flooded. That causes at least tens of thousands of dollars of damage, as well as potential loss of any personal items in your basement - for example all your electronic equipment or books could get ruined due to water damage.

 

In other words, it's a big deal, i.e. an important "feature" of your house. So the natural question as a new home-owner is "how do I ensure that this mission-critical feature actually works?" Obviously I didn't want to wait for a real thunderstorm and power outage to find out if everything would be ok. While I had heard the buzzwords ("make sure your sump pump works and you have a battery backup in case of a power outage"), and I had been on previous "teams" (i.e. my parent's house, growing up as a kid) that had successfully solved this problem, when push came to shove, I was certainly no expert. For all I knew, this could be the best sump pump in the world, or a worthless piece of junk. However, I knew the previous owners of the house, they were great, so I assumed that the sump pump was great too, and everything would be okay.

 

Eventually, I figured out how to test it by contacting some "domain experts" (previous house owners), who explained the different components to me. I then "mocked out" a power outage by simply unplugging the power plug (as opposed to waiting for a real power outage, or even turning off my house power). I then lifted the float to simulate water rising, and listened for a running motor. I checked a couple other things, and became confident that the feature did indeed "work as designed". I was told that is was actually a very good setup because it had a separate batter charger, and two separate pipes out, so they were completely parallel systems (kudos to the previous owners).

 

The number of analogies between me needing to test my sump pump, and a user needing to test a critical feature of a software project, are staggering. It's a reminder to me how real life experiences help one understand software engineering.