Software on the Side

On Speaking… and not speaking

2012-05-07T22:41:00.001-06:00

So as I mentioned in a previous post, I’m working to expand my speaking footprint this year beyond Utah. This started out pretty well with a three session gig at Boise Code Camp which was a blast. There is a great dev community up in Boise and I plan on going back next year. I was able to attend Agile Games 2012 in Boston which was amazing. Need to do a write up on that soon before everything leaks out of my brain :) Again, more great people and I felt super enriched after the three days.

Unfortunately, around that time, my sessions were turned down for MADExpo and Chicago Code Camp. I was pretty bummed about it, more than I thought I would be. I plan to try again next year and market my sessions better. Need to figure out how to get more buzz words into my titles :)

Happily I have been accepted to Agile Roots. I’ll be running “Hands-on Group TDD with Randori” (title pending).

Additionally, I’ll be presenting at the Utah .Net User Group this Thursday (May 10, 2012) on “Linq (from the inside)”.

I’m still waiting on Portland Code Camp and Seattle Code Camp which I hope to still speak at. I’ll likely go to Portland Code Camp either way as we’ll be in Portland to visit family.

I am hoping to attend SCNA in Chicago in November. And that should round out the year. Should be exciting!

Utah Code Camp Spring 2012 Slide Decks

2012-03-12T22:40:00.001-06:00

I had the opportunity to speak at Utah Code Camp again (my fourth code camp presenting Fall 2011 Spring 2011 Fall 2010) which was a lot of fun. Not sure if I would do three presentations again, but it was a lot of fun and I met a lot of great people.

If you attended one of my sessions, please take a minute to rate the session at SpeakerRate (not official eval… please do that too):

Here are the slide decks. Contact me with any questions!

Randori: Group Practice

View more presentations from Mike Clement

The Randori starter project is available at https://github.com/mdclement/NumbersToLcdRandoriBase

The Code Katas session was presented as two slide decks. One with the introductory material and the other with the guided FizzBuzz kata.

Code Katas Spring 2012

View more presentations from Mike Clement

FizzBuzz Guided Kata

View more presentations from Mike Clement

Linq (from the inside)

View more presentations from Mike Clement

The code base that I started from (tests and methods without implementation) is available at https://github.com/mdclement/Linq--from-the-inside--Presentation-Base

Expanding my Speaking Footprint in 2012

2012-02-24T00:36:00.001-07:00

So one of the things that I plan to do more of this year is presenting at Code Camps and the like. I’ve presented several times at Utah Code Camp (Spring 2011, Fall 2011), but want to expand my footprint. So, I’m currently submitted to Boise Code Camp, Chicago Code Camp and MADExpo. Over the next few weeks/months I’ll see how well my session topics are received outside of the Utah community. I also plan to submit to Portland Code Camp and Agile Roots this year once their calls for speakers are open.

If you’ve attended (and hopefully enjoyed) previous sessions that I’ve presented, please rate me at http://speakerrate.com/mdclement

The topics that I’ve been submitting (and that I’ll be presenting at Utah Code Camp Spring 2012) are listed below along with the abstract. I’m looking forward to an exciting year of meeting with developer communities both inside and outside of Utah!

Linq (From the Inside)

Knowing how to use Linq is useful if you're doing any coding using .NET 3.5 or newer. But have you ever thought about what is going on "under the hood"?

Join us as we dive into the guts of Linq and implement Linq extension methods such as Where, Select, Any, All and Sum. Not only is it interesting to see what's going on, it'll help you to build better code using Linq.

Code Katas: Practicing your Craft

One of the key values as part of the Software Craftsmanship movement is to be "skill-centric" and as part of that, practicing our skills as software developers is key! The Code Kata format is a coding exercise that is repeated and perfected. It provides one of many ways to practice the craft of software development. We'll discuss the Code Kata format, introduce a few katas and discuss some other practice formats.

I will be guiding the Kata in C# (no previous knowledge necessary though). As this is hands on, to take full advantage of the session have Visual Studio or SharpDevelop installed, NUnit installed (or via NuGet) and an integrated unit test runner (recommend Resharper or NCrunch for VS).

Randori: Group Practice

Looking for a new way to practice your craft? Randori provides a complementary way type of training when compared with katas.

Elements of Randori are: Pair Programming, Pair changes with mechanism (Time box, Ping Pong), Start from scratch, Use TDD, Everyone should be following, Pair should be explaining, Audience gives suggestions only with when Green

An example is at http://vimeo.com/2499540 . This is a hands on session!

But I really learned from writing: Quote of the Week

2012-01-31T14:28:00.001-07:00

Note: Might be silly to call this a “quote of the week” given that it’s been years since I posted one but… oh well.

Heard this this morning on NPR from an interview with the composer Philip Glass:

What this amount of music has done for me is taught me how to write music. Oh, I had great teachers. Boulanger was one. Another was Ravi Shankar. And I went through the Juilliard process, and that was good, too. But I really learned from writing, which is how painters learn to paint, and writers learn to write, and how even dancers learn to dance. In a way, that's true. But what was the value of being so prolific? It's how I learned my trade.

Philip Glass from Philip Glass At 75: Listening With Heart, Not Intellect

What I heard in there is "But I really learned from writing, which is how painters learn to paint, and writers learn to write, and how even coders learn to code."

Utah Code Camp Fall 2011 Slide Decks

2011-09-13T00:44:00.001-06:00

I had the opportunity to present at the Fall 2011 Utah Code Camp on September 10, 2001. I have uploaded my slides to Slideshare.
If you attended one or both of my sessions, please take a few minutes to evaluate the sessions at SpeakerRate.

On both of these presentations, you’ll be able to glean things more from the speaker notes than from the slides. I plan on posting more on each of these subjects later.

Power of Patterns OR More Than Programming with Objects

View more presentations from Mike Clement

The Code Katas session is divided into two slide decks; one for the session specific slides and another for the slides for the Bowling Game Kata in C#.

Code Katas: Practicing Your Craft

View more presentations from Mike Clement

Bowling Game Kata in C# Adapted

View more presentations from Mike Clement.

Utah Code Camp Spring 2011 Slide Decks

2011-04-11T23:38:00.001-06:00

As I’m sure at some point they will not be available on the Utah Code Camp downloads page, I’ve gone ahead and posted my slide decks from my sessions on SlideShare. They are not entirely comprehensible, especially the Rhino Mocks one since the majority of the time was spent in code. I’ll get that posted soon as well.

Using Rhino Mocks for Effective Unit Testing

View more presentations from mdclement

Software Craftsmanship

View more presentations from mdclement.

Lessons from Laser Tag: Metrics and Feedback Loops

2011-03-18T22:24:00.001-06:00

Recently the Utah Development Center at Microsoft (where I work) had a “morale event” (I still think it’s funny that they explicitly call them that) where we visited a local laser tag place. We played three times and each time I ended up in the middle of the pack (yeah, I’m not that good). But I did see some interesting lessons that could be taken from the experience. Here is one of those lessons.

After the first round, an interesting thing happened. We each got a printed “score card” to tell us how we had done. It had how many kills, how many timed you were killed, breakdown by opposition player (friendly fire was off), number of shots fired, accuracy percentage and some overall team stats. The one additional number on the sheet was “rank”. Being good little programmers/engineers, most of us started to try to reverse engineer the ranking algorithm. It appeared to be surprisingly simple. We were ranked by number of kills. (I don’t think this was confirmed, but we suspected that number of timed you were killed was used as a tie breaker.)

It was like the game totally changed. Because it did.

Suddenly the feedback loop from the metrics used gave us this: Don’t worry about accuracy percentage, don’t worry about the number of times you get killed. Kill the most people and you win. The only thing that matters to your rank is number of kills. The next game the overall kill count went up significantly (about 20% increase).

Metrics have the tendency to focus us like this, which is super powerful. But remember, with that great power comes great responsibility. While many still played for “team pride”, for some people the individual ranking became the most important personal metric of success. If you no longer care about the success of your team, the number of kills that you sustain no longer matters. It is not a metric that you care about. All that matters is getting the most individual kills.

Choose the metrics that you use with care.

A recent real life example that I heard went something like this: The manager of a development group doing SINO (Scrum in name only) set a goal for the group that “this year, we’re going to get everything done that we commit to for a sprint done in that sprint.” This is a well intentioned goal. Basically do what you say you’re going to do. BUT, if that is the metric used, what happens to the amount of work committed to in a given sprint? In order to do well against the metric, the amount of work committed to drops (or estimates are WAY high). Suddenly half way through a sprint (or less) the developers have completed the work that had been committed to. All that matters is getting the work committed to done.

Some managers reaction would be to think, “Well, that didn’t work, lets add some more metrics to get what I want. Let’s continue to try to control the system.”

That may or may not be the best approach. Eventually you may end up with a system that is so bogged down with itself that no work actually gets done.

I’m not saying that metrics are bad. They can be very, very good and are very, very powerful. Just be sure that you’re using the right tool for the right job. Don’t use a nail gun where the gentle tap of a hammer is the right thing.

Prime Factors Kata in C#

2011-03-03T01:09:00.001-07:00

I recently led a practice of the Prime Factors Kata in C# at the Utah Software Craftsmanship Group. I couldn’t find a C# version, so I adapted the Java version that Uncle Bob posted back in 2005. I’ve done a recording of me practicing the kata so that others can practice it. I recorded it at a fairly high resolution (approximately 1920x1080) which means you’ll need to watch it on a screen around that size in order to make out the text in most cases… sorry, this is my first attempt at screen capture of a coding exercise… I’m sure I’ll get better with practice!

Enjoy!

Prime Factors Kata in C# from Mike Clement on Vimeo.

But We Can Get ‘em Cheap!

2011-01-12T01:28:00.001-07:00

What’s wrong with that phrase? A better question would be is there anything right with it…

“But we can get ‘em cheap” is the ultimate lie, especially in hiring. Now, that’s not to say that you can’t get quality team members for “cheap”. BUT, when you preface that with “but” it means that you don’t really want to hire that candidate. It means that you are attempting to justify a bad hire with a claim of “cost savings”.

But the lie is that you’re not really saving money.

Let’s say that this “get ‘em cheap” candidate (A) would somehow accept an offer of $45K. But you have doubts. You wonder why somebody would take such a low salary with the experience that they claim on their resume, but you go ahead, extend the offer. Surprisingly they except your low offer and so you get ready for your new employee.

In a parallel universe, you passed on candidate A because they weren’t good enough, even if you could “get ‘em cheap”. So you keep looking, and maybe looking some more. So you’re going to incur additional costs in the recruiting/hiring process. But you’re confident that you’ll find a quality candidate if you keep looking.

So you keep looking.

And looking.

And then you find candidate B.

But you’re pretty sure that they’re going to want at least $80K if not more. And sure enough, after some negotiation, you settle on $90K. Plus you definitely spent more time and money looking than you wanted to. You’re pretty sure it’ll be worth it though.

Back in candidate A land, you start doing training. You’re explaining a concept and you can tell your new hire isn’t quite getting it. They are nodding away, but you’re pretty sure they just aren’t asking questions because they don’t want to appear incompetent. You get the feeling that they are following the old motto “better to keep your mouth closed and be thought a fool than to open it and remove all doubt” might be your new hire’s strategy, but you can’t tell so you write it off as you just not being able to read them. But you get the same feeling as you go through your other training sessions. He also comes and asks some questions that are a little weird… and repetitive.

But he was cheap right? Well you’re now not only paying A’s salary but now wasting one of your productive developer’s time. A’s not really getting much done, but you figure it’ll just take a little longer for him to ramp up. But he keeps bugging your devs… and soon you realize that the new hire has been rotating around who he asks questions in order to make it less noticeable that he doesn’t know what he’s doing… so instead of repeating a question twice, it’s really that he’s asked it five times… and in code review it comes out that he still doesn’t get it.

So two months later you’ve tried and tried and things aren’t working out. You have encouraged, warned and helped as much as you feel you can, but it’s just not working out. Not only has A been minimally productive himself, he’s constantly needed help from others which means that your team hasn’t been as productive. So you end up firing A and start looking again, until you find someone that you can “get cheap”…

Meanwhile in the parallel universe, candidate B is asking all the right questions… once. You see the light turn on in his head as you explain your system architecture. And the questions that he asks help you understand that maybe there are some improvements that could be made to your framework code to help ease development. B is productive within two weeks and at the end of their second four week sprint has gotten as much done as most “ramped up” devs.

So which is the better deal? Which really is cheaper?

“But we can get ‘em cheap” to me is the ultimate red flag. It means that more than likely you’re getting a low quality candidate for a low salary but at a cost that is really higher than anybody should be willing to pay.

Are there ways to get good devs less expensively? Sure! Interns and new college hires can be a great way to get bright devs that can be trained easily relatively inexpensively. But even that is not an endless pool as you still need more senior devs to mentor and train them.

There is another hidden cost/benefit that comes with a new hire, and this is probably one of the most costly: What do your other devs think when that new hire walks in the door for the first day? Do they think “what a great addition to the team!” or “oh boy, I can’t believe I work here where they hire these people”. Building a great team means that every hire counts. There is no room for “meh” team members on a great team. Should they all be great in the same way? No! But they all should be great at something the team needs.

Even if your A turned out “okay” (half as productive as B, but decently productive) and you could hire two of them for the same salary as (or even less than) B, B would still be a better deal because 1) fixed per employee costs (like hardware, software, health insurance, benefits) and 2) your communication graph is smaller. Your team will be tighter and more productive with a single solid performer that is able to raise the performance of the whole team than two blah performers. Smart people want to work with smart people!

Just remember, if you hear “but we got ‘em cheap” when frustrated with a new hire, you’ll probably be hearing the same thing in 6 months when you’re training his replacement.

Promotion != Management

2011-01-10T01:02:00.001-07:00

Are you familiar with the Peter Principle? In a sentence, it states that employees are promoted to their level of incompetence. Think about that for a second.

Sure it’s kinda cute and makes you chuckle, but what does that really mean for your organization? It means you have a certain percentage of your employees/co-workers that are incompetent at their current positions. The scary thing is that most of these people are in management positions… they are running your company.

The sad thing is that these same people were most likely competent if not exceptional in another non-management position in your company. How else did they get promoted to that management position if not by demonstrating competence in another role? But that also means that there are people in your organization that are getting paid to fail instead of being put in a position to succeed.

So the question is why? Why waste all this talent and ability? Why not put them in a position to succeed? Because to put them in their old positions would often result in a “demotion” and this is culturally difficult to do.

The trick is not to tie promotions to role. Otherwise you artificially limit promotions/salaries for those in individual contributor positions because they aren’t “moving up” the org chart. You contribute to a culture that the only way to progress your career is to “get into management”. This is a mistake.

The flawed fundamental assumption is that if you are good at something, you’ll be good at managing people that are doing that something. Managing people requires a unique skill that is often not found in your top individual performers. People management needs to be its own role within your company. Those that recognize their limitations and feel that they are best in an individual contributor position may feel less valued in the organization, causing them to leave.

On wikipedia it is says that a result of the Peter Principle is that “work is accomplished by those employees who have not yet reached their level of incompetence”. Make sure that your organization keeps people below their level of incompetence or else who’s going to do the work?

Culture beats process

2010-10-11T08:15:00.000-06:00

Last week I tweeted “culture leads to behavior; process leads to resentment”. I thought I’d follow that up…

One of the things that I’ve noted in my career is that the natural reaction of many people is to “add process". We’re introducing bugs late in the release cycle. Let’s add a check in process. We’re not sharing code “correctly”. Let’s add a code sharing process. Bug information isn’t getting communicated correctly. Let’s add a bug entry process.

A coworker said (though I’m sure he got it from somewhere else):

Process is like violence. If you’re not getting the results you want with it, you’re not using enough.

True, if you put enough process around something, you might eventually get your desired result. Might. Engineering systems is hard. Engineering systems that involve people is really hard. One of the first business books I read was The E-Myth Revisited: Why Most Small Businesses Don't Work and What to Do About It. It was an eye opener. It described how a business really is a set of processes. To have “The Manual” that helps things be repeatable.

I loved it. I ate it up. I need to reread it now and see how much my current view of the world jives with it though.

Because for some things this works. For example, Ray Kroc and the hamburger. McDonald’s does not have the best hamburger in the world, but people go back because it’s predictable. It’s repeatable. You get the same hamburger, chicken McNuggets, salad, or apple pie pretty much anywhere. The process, the system makes it happen. But then maybe that job can be done by robots.

Now where does that break down? Is the service consistent at each McDonald’s? No. As much as the process attempts to enforce this, at each store are different people, with different personalities, different backgrounds and different whatever going on that particular day.

This is why culture is more powerful than process. If you can instill a culture of cheerfully helping customers, your employees will do just that, regardless of “The Manual”. If you instill a culture of quality code, employees are going to think twice before checking in crappy code. Maybe they’ll get somebody to review it or give it another pass. Processes or systems can be a starting point, but without culture they have no meaning.

Culture helps people do the right thing. They might not always do the right thing, but that’s okay. It’s an opportunity to teach about the culture, not add a process. Culture is “the why” of a business. And when you know why, it’s a lot easier to get a great result. Put too much process around it and you’ll get a robot.

Can’t Succeed? Redefine Success

2010-10-08T22:51:00.001-06:00

We set goals. We set exit criteria. We define requirements.

Unfortunately we don’t always reach our goals, complete our exit criteria, complete all our requirements.

So what do we do about that?

Now Failure sometimes happens. Sometimes we completely miss the mark. But often we simply need to redefine what we see as success. That might mean adjusting your goals mid-flight. Maybe fudging the exit criteria for a situation that you didn’t anticipate. Change the requirements based on the evolving understanding of the customer needs.

How do we know if we Failed or if we Succeeded? Most of the time a simple “5 Whys” exercise will get us there. (Sometimes 1 Why might be sufficient!) Why did you set that goal? What is the purpose of the exit criteria? Why did we define requirements in the first place? If we failed at “the why”, then we failed. Otherwise, redefine success and take a victory lap!

MSBuild Presentation - May 2010 UDNUG Meeting

2010-08-12T19:05:00.001-06:00

This last week while thinking about going to the UDNUG (Utah .NET User Group) meeting this week, I realized that I never posted my notes and such from my MSBuild presentation at the UDNUG in May. So without further ado, here are links to the final demo files and below are my raw notes. Enjoy!

Why MSBuild?
.csproj files are MSBuild files
MSBuild is distributed with the .NET framework so a VS installation is not required on your build server.

NAnt

Primary alternative is NAnt - was pretty much dead (very little activity in the last 4 years, mostly because it had matured and partly because MSBuild released with VS2005/.NET 2.0)
Earlier in 2010, .9 version is being worked on (in RC1) which I haven't looked at.

Another is Ruby/Rake
I plan on looking into this some at some point as it would be nice to have a first class language, instead of XML configuation.
info on lostechies.com from Derick Bailey on this topic if you are interested (Derick Bailey on Ruby/Rake)
But even this uses MSBuild to build the actual projects, just uses Ruby to do additional work around MSBuild

While I don't usually use this reason (I have chosen NHibernate over Entity Framework, nUnit over msUnit, etc) the fact that MSBuild is an MS product is useful. Also it means that your build will be similar to a VS build (but not identical) Also it’s installed wherever the .NET framework is installed.

Start with the classic "Hello World" demo

Add Target with Message

Add Another Target

Now I want Before to run and then Hello.

Add "Also Before Hello"
<Target Name="Also Before Hello">
<Message Text="Also Before Hello"/>
</Target>

Move Hello to the end
Note that the first target still runs by default. Can specify any target to run on the command line.

Command Line Reference on MSDN

Also can specify the "default target" using "DefaultTargets" (default Hello)

Add Hello Again to the default targets. Note that the targets run in order that they are listed.

Add a depends on target to Hello Again:

Run: note that Before Hello ONLY RUNS ONCE.
the assumption is that you only want to build dependencies once.

Properties
<PropertyGroup>
<MessageFor>Utah .NET User Group (from a Property)</MessageFor>
</PropertyGroup>

<PropertyGroup>
<MessageFor>Utah .NET User Group (from a Property)</MessageFor>
<Today>$([System.DateTime]::Now)</Today>
</PropertyGroup>

<Target Name="HelloProperties">
<Message Text="Hello $(MessageFor) on $(Today)"/>
</Target>
There are some property names that are reserved for MSBuild.

Conditions

    <MessageFor Condition="$(MF) == 'UDNUG'">Utah .NET User Group (from a Property)</MessageFor>
    <MessageFor Condition="$(MF) == 'UCC'">Utah Code Camp (from a Property)</MessageFor>
    <MessageFor Condition="$(MF) == ''">Nobody</MessageFor>

Items/Item Groups

Exclude
<ItemGroup>
<SamplePhotos Include="C:\Users\Public\Pictures\Sample Pictures\*.jpg" Exclude="C:\Users\Public\Pictures\Sample Pictures\*house*"/>
</ItemGroup>

Well known metadata
Well Known Item Metadata on MSDN

Transforms

<Message Text="Photo filenames: @(SamplePhotos->'%(Filename)%(Extension)')" />

Incremental Builds

<Target Name="Text" Inputs="@(TextFiles)" Outputs="@(TextFiles->'CopyOfTextFiles\%(Filename)%(Extension)')">
<Message Text="hooray for changeme.txt"/>
<Copy SourceFiles="@(TextFiles)" DestinationFolder="CopyOfTextFiles"/>
</Target>

Import

Move the following to Demo.Extra.proj

Run the Hello target to show that it's using the other file too.

Task Reference on MSDN

MSBuild Community Tasks
http://msbuildtasks.tigris.org/

Show MSBuild.Community.Tasks.Targets
Show that it is using the UsingTask tag to import all the tasks.

If you didn't use the MSI (in my case I want to have it xCopy buildable), you need to make sure to set MSBuildCommunityTasksPath so that the imported targets file can find the tasks.

<SourcePath>$(MSBuildProjectDirectory)</SourcePath>
<MSBuildCommunityTasksPath Condition="'$(MSBuildCommunityTasksPath)' == ''">$(SourcePath)\MSBuildCommunityTasks</MSBuildCommunityTasksPath>

<Target Name="Zip">
<Zip Files="@(SamplePhotos)"
ZipFileName="SamplePhotos.zip" />
</Target>
Actually build a project!

New in MSBuild 4.0
Not a lot of experience here, but there are a few features that look pretty exciting.

New in MSBuild 4 on MSDN

Property Functions

String (instance) property functions

Static property functions

Getting the date before is an example of this.

MSBuild property functions

Can do x and y on separate /p: or use "" to wrap a ; separated pairs
RunBeforeTargets and RunAfterTargets

Modify this:

Math runs After Add and Before String when you run either.

Inline Tasks

<Target Name="Hello">
<HelloWorld />
</Target>
Show parameters

Anger isn’t good for anybody

2010-04-13T23:43:00.001-06:00

I had a weird sort of realization recently about some anger that I’ve been carrying around for some time now. Up until that moment of realization, I had seen myself and completely justified in my anger. It has become such a good comforting friend over the past few months that I almost feel threatened at the thought that I should lay it down and walk away.

I’m not saying that I suddenly believed that my anger was not justified. I still think that I had a right to be angry… but I think that my license expired months ago. I need to let it go and move on. Anger isn’t good for anybody, not for the person on the receiving end of the anger and even worse for the person that is carrying the anger around. I know this, but it’s often hard to see what’s right in front of your face or, in this case, in the mirror.

I do remember reaching a point a few months ago where I was tired of carrying it around before and wanted to let it go because it was weighing me down. But I don’t think that I saw it in the same way as I do now. Then I was just tired, I didn’t worry about it anymore. But now I see it as a personal failure that I have not been able to let it go and spend effort on more important things. So much wasted energy! For what!?!

Now, I know that I can’t magically make things all better (nor should I have to), but I need to do something to heal myself. I must work to consciously not pick up the anger again. I need to put down the anger and walk away because it’s sapping my strength, and I need that energy for more important things.

Movement != Momentum

2010-04-06T23:29:00.001-06:00

Momentum is an interesting thing. One of those cheesy “motivational” posters states “Momentum: It is not of importance where we stand but in what direction we are moving”. Cheesy? Yes. Partly true? Sure.

The problem is that movement can cause the illusion of momentum. Let’s do a little physics refresher. The equation for momentum is:

p = momentum
m = mass
v = velocity

If you have friction, you might be able to exert enough force to overcome that friction and move for a brief period of time, but as soon as that force is removed, the counterforce of friction quickly slows things to a stop.

This stop and start movement does not equate with momentum. In terms of your life or team, if you have momentum, one change can trigger another change, can trigger another change, like an avalanche. Working to get some movement is important, but do not mistake it for momentum. To get momentum, you need to increase force or reduce friction. Probably you’ll need both!

Stop and start movement can yield positive results, but it requires too much effort and is not sustainable. Getting “the big Mo” (as Josh Lyman calls it) is very important to any effort.

Impractical != Impossible

2010-04-03T11:22:00.001-06:00

Recently at Utah Code Camp, I got into a conversation about which solution should be used to solve a problem (given that there are multiple solutions… and there normally are). Somebody (yeah, I didn’t get his name… my bad) mentioned that he had a boss that always looked for the “third best” solution. This was based on the assumption that 1) the “first best” solution was “impossible” and 2) the “second best” solution was too expensive. That was supposed to make the “third best” solution the “best” solution.

Well, somebody else commented that an “impossible” solution wasn’t really a solution and I agree! What he really meant (after some additional explanation) was that it was impractical as he commented that it might be a viable solution in a few years. Things that seemed impossible only a few years ago are common!

Think about some examples:

Imagine telling someone a few years ago with dialup about streaming high definition video. Impossible!
Imagine telling someone in the era of tube TVs about high definition flat panel displays. Impossible!
Imagine telling someone in era of computers that filled rooms that you would one day have a gigahertz processor and gigabytes of storage in your pocket. Impossible!

To me this emphasizes the fact that we should be careful how we use absolute terms such as “impossible” or “never” or even “always”. Using these terms can limit your credibility as it takes only ONE counterexample for you to be proven wrong. Use them with care!

Featured on Management 3.0

2010-03-18T02:06:00.001-06:00

I recently had my first guest post and was featured on the new Management 3.0 site that is being run by Jurgen Appelo of http://www.noop.nl/ fame. It’s my post on Absentee Management, check it out!

Good vs. Great; Better vs. Best

2010-02-19T09:45:00.001-07:00

In Good to Great, Jim Collins states that “good is the enemy of great.” In Working Effectively with Legacy Code, Michael Feathers states that “we can’t let ‘best’ be the enemy of ‘better’”.

On the surface these seem contradictory, but I would argue that they are, in fact, complementary. I have been very much guilty at times of getting “analysis paralysis”, being overly concerned with the “right answer” or the “right way”. In that case, where you have nothing, doing something is better than doing nothing. At the very least, doing something, even if it’s wrong, gives you feedback that it’s wrong and you can move on. The trick is to do something that is low risk. The smaller your something is, the faster you can get feedback and adjust.

This goes with the “release early” philosophy of agile. The other part of that philosophy is “and iterate” which is important as well. Getting something done allows you to take it and improve it. Having something concrete via quick prototyping or tracer bullets and iterating can get you there faster than waiting for the “right way” to become apparent. If we always think “I don’t have time to make it perfect so I won’t do anything” we will never do anything. “Best” becomes the enemy of “better.” Martin Fowler said as much:

When you actually sit down to write some code, you learn things that you didn’t get from thinking about them in modeling terms. There is a feedback process there that you can only really get at from executing some things and seeing what works.

Once we get something good enough, the problem then becomes the attitude that “I don’t think it’s worth the effort to improve it, it’s good enough.” And here is where “good is the enemy of great.” The problem becomes when everything is humming along “well enough” that we become complacent. That is until something shakes things up. Like when the weight of defects reported become overwhelming because the code was not kept clean and non-legacy (no automated tests). Or when an economic downturn hits and you realize that you didn’t take the opportunity during the “good years” to fine tune things or expand and improve and are now faced with tough decisions.

We need to be constantly improving (in code, in business and life), not settling for good, striving for great, but not so worried about best that we don’t pursue better.

Absentee Management

2010-02-05T16:20:00.001-07:00

I heard the report “3 Weeks After Quake, Shelter A Main Concern in Haiti” on NPR recently. It made me quite sad to hear about all the people that want to help (from inside and outside Haiti) and those that want to get started with rebuilding their lives, but are unable to do so with any sort of efficiency because of a lack of any sort of management direction (from the government of Haiti or the UN or anybody).

If you don’t have time to listen to the report (only about 4 minutes long), some of the phrases in there are:

Some feel that they “should be focused on a longer term solution”
Some reconstruction is taking place but “not under any sort of coordinated plan”
Some are working on their own but it “can be quite dangerous”
The government is “working toward a plan, discussions taking place”

“Discussions taking place”? One of my favorite phrases lately has been “talk does not cook rice”. In this case, talk does not save lives or rebuild a country.

So what does this have to do with software development? In agile we often talk about “self-organizing teams”. Often we talk about “getting out of the way of the team”. This does not mean that management has no role in agile. In fact I would argue that management’s role is even more important! At the very least managers are responsible for:

giving parameters for the work to be done (may be in the form of backlog, a product vision),
providing necessary resources to the team (monetary or people) and
removing the team’s impediments (make sure the team isn’t stuck).

This means that they should be doing, not talking. Mapping out a course, not just discussing it. Figuring out which way to point the team next and getting them the resources to get there. Otherwise the teams will start taking things into their own hands and that “can be quite dangerous.” At the very least it will result in wasted effort.

Even in an extreme case like Red Gate’s “Down Tools” experiment (which I’m curious to see what the results are) you can see these elements:

“The only aim is to create something relevant to Red Gate that you wouldn’t have created otherwise.” – but there is a clearly stated aim and “The only rule is that you have to complete something by Thursday lunchtime.”
“Each team will have a discretionary budget of £500 for hardware / software / other stuff we don't already have in the building” – while this may not be enough for a super ambitious project, it should be more than enough for 4 days and it does set some parameters. Most importantly it says “we’re behind this… with our pocketbook”

A team that is trying to self-organize without management’s direction and help is going to fail almost by definition as they won’t know what to look for in success. Obviously the stakes for the people of Haiti is much higher, as in many cases we are talking about survival, not just another software project. But just like the people of Haiti, if a development team has no direction, no resources and no help with impediments, the journey will continue to be bumpy.

Blame tied to Responsibility

2010-02-03T13:29:00.001-07:00

When code with a major defect is released to the customer, who’s fault is it? Who do we blame? Scott Bellware just posted basically saying “it’s not the tester’s fault”. I think it’s fair enough to say that the “QA missed something” syndrome is not healthy, but neither is “there's nothing that QA has ever missed that developers didn't miss first”. The problem with the argument that “It's less of a tester's job to check that a developers' code is right, but that their tests are right” also implies that the tester didn’t “do their job” because they didn’t find the holes in the tests that lead to the defect not being caught and therefore, released.

This finger pointing usually happens in organizations where “QA” is the “gatekeeper”. Sometimes that is the role that the organization has given them or the one that they have set up for themselves. Either way they have implicitly set themselves up as being blamed for any defects that are released. Is that fair? Maybe not, but you can’t have it both ways. You can’t simultaneously be responsible for it and not get the blame.

Of course this is coming from a programmer. So what’s my point?

The attitude on an agile team should be the team missed something. And in an agile organization, “the whole organization missed something.” To pin responsibility for any particular failure on any one particular individual or role in an agile team is to absolve the other members of the team from responsibility for success or failure of the team. The attitude becomes, “if QA is responsible, I can’t get blamed.” Or conversely “if the programmer is responsible, I (the tester) can’t be blamed.” Take away the “safety net of blame” and attitudes change… but more on that in the future.

So when a defect is released, who failed? The programmer failed, the analyst failed, the tester failed, the user during UAT failed. In reality the whole team failed, agile or not.

Good Grief Charlie Brown

2010-01-26T10:03:00.001-07:00

If you are familiar at all with the Peanuts comic strip, you’ve seen this frame in various forms over and over again…

This situation was described aptly in The West Wing episode “The Drop In”:

"You are the Charlie Brown of missile defense. The Pentagon is Lucy." When Leo says he doesn't read the comics, the President explains, "Charlie Brown wanted to kick a football and Lucy would hold it except that she'd pull it away at the last minute and Charlie Brown would fall on his butt. . . . Each time Lucy would find a way to convince Charlie Brown that this time she wouldn't pull the ball away, but she would and once again Charlie Brown would fall on his butt." As the President predicted, Leo's high hopes are dashed, and the President tells him, "By the way, the words you're looking for are, 'Oh, Good Grief.'"

(summary provided by http://westwing.bewarne.com/second/34dropin.html)

So is Charlie Brown right to continue to trust Lucy or is he unable to learn from his mistakes?

A friend recently posted Cynicism & Professionalism which this is a kinda sorta response to. Here is a partial quote of my comment that I posted there:

But I think it's always useful to keep in mind that most people are mostly trying to do the right thing most of the time.
Whether or not people's intent and their results end up in the same place or not, well that's another story (says the cynic ;) )

While “past performance is not an indicator of future results”, I think that we are unwise to ignore past experiences in formulating our response to the future. Forgiveness is important. Giving someone the benefit of the doubt is important. Trusting that people’s intent is generally good is important. But the lesson I get from Charlie Brown and Lucy is "Those who cannot remember the past are condemned to repeat it."

Sometimes you need to leave Lucy there holding the ball so that you’re not left saying “Oh, Good Grief.”

Programmers’ Mecca

2009-07-10T08:42:00.001-06:00

Other than big sites like Microsoft and Google, this has to be the ultimate programmers’ Mecca…

(note: if you’re in a feed reader, you might need to go to the site to see the video)

Wipe the drool… and control the envy…

Failure

2009-07-01T08:05:00.001-06:00

Sometimes failure is the path to success…

Do you understand the words that are coming out of my mouth?

2009-05-12T07:32:00.001-06:00

Often when discussing a disagreement, the two (or more) parties involved will stop communicating. The natural reaction of most people is to start to defend their position vigorously while ignoring anything the the others are saying.

This frustrates me to no end.

The common case is that both sides have valid points to be made and that usually, if both parties are really communicating (read: listening) and intelligent, one side will either realize that they are in error or both will adjust their positions to another better common position. I have had numerous occasions when I have been arguing a point and finally started listening and realized that there was a way to get to “win-win” that wasn’t even on the table originally.

If you understand my position and reject it, I’m happy to “agree to disagree”. But before we get there, we’re both going to need to get to a point where we understand the words that are coming out of each other’s mouths.

Software on the Side

On Speaking… and not speaking

Utah Code Camp Spring 2012 Slide Decks

Expanding my Speaking Footprint in 2012

Linq (From the Inside)

Code Katas: Practicing your Craft

Randori: Group Practice

But I really learned from writing: Quote of the Week

Utah Code Camp Fall 2011 Slide Decks

Utah Code Camp Spring 2011 Slide Decks

Lessons from Laser Tag: Metrics and Feedback Loops

Prime Factors Kata in C#

But We Can Get ‘em Cheap!

Promotion != Management

Culture beats process

Can’t Succeed? Redefine Success

MSBuild Presentation - May 2010 UDNUG Meeting

Anger isn’t good for anybody

Movement != Momentum

Impractical != Impossible

Featured on Management 3.0

Recommended Reading

Good vs. Great; Better vs. Best

Absentee Management

Blame tied to Responsibility

Good Grief Charlie Brown

Programmers’ Mecca

Failure

Do you understand the words that are coming out of my mouth?