Monday, October 11, 2010

Culture beats process

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.

Saturday, October 9, 2010

Can’t Succeed? Redefine Success

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!

Thursday, August 12, 2010

MSBuild Presentation - May 2010 UDNUG Meeting

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.


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 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

  <Target Name="Hello">
    <Message Text="Hello Utah .NET User Group"/>

Add Another Target

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

Now I want Before to run and then Hello.

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

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)

  <Target Name="Hello Again">
    <Message Text="Hello Again UDNUG!" />

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:

  <Target Name="Hello Again" DependsOnTargets="Before Hello">
    <Message Text="Hello Again UDNUG!" />

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

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

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

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


    <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

    <SamplePhotos Include="C:\Users\Public\Pictures\Sample Pictures\*.jpg" />
  <Target Name="Photos">
    <Message Text="Photos: %0A%0D@(SamplePhotos, '%0A%0D')" />

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

Well known metadata 
Well Known Item Metadata on MSDN

  <Target Name="PhotosMeta">
    <Message Text="Photo filename: %(SamplePhotos.Filename)%(SamplePhotos.Extension)" />


      <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"/>


Move the following to Demo.Extra.proj

<Project xmlns="" ToolsVersion="4.0">
  <Target Name="Also Before Hello">
    <Message Text="Also Before Hello"/>

  <Import Project="Demo.Extra.proj"/>

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

Task Reference on MSDN

MSBuild Community Tasks

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.

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

    <Import Project="$(MSBuildCommunityTasksPath)\MSBuild.Community.Tasks.Targets" />

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

  <Target Name="Build">
    <MSBuild Projects="@(Projects)">
      <Output TaskParameter="TargetOutputs" ItemName="AssembliesBuilt"/>
    <Message Text="Built Assemblies: @(AssembliesBuilt)" />
    <Copy SourceFiles="@(AssembliesBuilt)" DestinationFolder="."/>

    <Projects Include="C:\Users\Mike\Demos\MSBuildPrototype\MSBuildPrototype\MSBuildPrototype.csproj"/>

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

  <Target Name="String">
    <Message Text="MessageFor Length: $(MessageFor.Length)"/>
    <Message Text="MessageFor First 2: $(Messagefor.Substring(0,2))"/>

Static property functions

Getting the date before is an example of this.

  <Target Name="Math">
    <Message Text="Square root of $(Value) = $([System.Math]::Sqrt($(Value)))" />

MSBuild property functions

  <Target Name="Add">
    <Message Text="Sum of $(x) and $(y) is $([MSBuild]::Add($(x), $(y)))"/>

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

Modify this:

  <Target Name="Math" AfterTargets="Add" BeforeTargets="String">
    <Message Text="Square root of $(Value) = $([System.Math]::Sqrt($(Value)))" />

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

Inline Tasks

    AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll" >
    <ParameterGroup />
      <Using Namespace="System"/>
      <Using Namespace="System.IO"/>
      <Code Type="Fragment" Language="cs">
// Display "Hello, world!"
Log.LogError("Hello, world!");

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

    AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll" >
      <Value ParameterType="System.Int32" Required="true"/>
      <Using Namespace="System"/>
      <Using Namespace="System.IO"/>
      <Code Type="Fragment" Language="cs">
// Display "Hello, world!"
Console.WriteLine(Value * Value);
//Log.LogError("Hello, world!");

  <Target Name="Hello">
    <HelloWorld Value="4"/>

Wednesday, April 14, 2010

Anger isn’t good for anybody

370801205_efe0fa8d7d[1] 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.

Wednesday, April 7, 2010

Movement != Momentum

Free_Body_Diagram[1] 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. 

63969933_0c1e556fcd_m[1]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.

Saturday, April 3, 2010

Impractical != Impossible

2316418326_a243fddbc2[1] 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!

Thursday, March 18, 2010

Friday, February 19, 2010

Recommended Reading

I’ve been wanting to put together a recommended reading list for some time now, so I guess I’m going to not let “best” be the enemy of “better” and just do it.  I have added a small link to it below the “about me” side bar (which I will work on making more prominent soon… need to clean up the sidebars at some point).

Or you can use this link to view my recommended reading list.   None should be a terrible surprise if you’ve read any of my posts.  I’ll go back and elaborate on them more in the future (give my reasons and analysis) as well as expand (and possibly contract) the list.  Enjoy!

Good vs. Great; Better vs. Best

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.

Friday, February 5, 2010

Absentee Management

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.

Wednesday, February 3, 2010

Blame tied to Responsibility

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.

Tuesday, January 26, 2010

Good Grief Charlie Brown

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

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.”

Original design by andrastudio
Blogger port by Blogger Templates