Fake - The future of .NET build tools?

Tired of XML based build systems?
Thought so. That's why I spent a few minutes hacking togheter the basis for my own build system. I call it Fake. And looks like this:

let clean = task "Clean" (fun () ->
    Console.WriteLine("Cleaning."))

[<Default>]
let build =
    task "Build the lot" (clean => fun () ->
        Console.WriteLine("Building.."))

let loadTestData =
    task "Load some test data" (fun () ->
        Console.WriteLine("Loading test data..."))

let test =
    task "Test it" ([build; loadTestData] => fun () ->
        Console.WriteLine("Running Tests...."))

Then simply

x:\..\>fake test
Cleaning.
Building..
Loading test data...
Running Tests....
x:\..\>

Is this idea worthwhile? Tell me in the comments.

Team Foundation vs Subversion and Bazaar - Round 1: Update my workspace.

I usually work with Subversion or Bazaar but currently I'm on a project using Team Foundation Server. Today I got the silly idea of updating my workspace using the command line interface. Assuming that you are standing in the directory you want to update this task can be accomplished as follows:

Subversion	Team Foundation
svn up	tf get .\* /version:T /recursive

Now one of theese is sane, the other is complelty insane. I won't tell you wich is wich.

RED - Re Evolutionary Development

Something is happening in devloperland, if you put your ear to the tubes of the blogosphere you can hear a faint message. The Software Craftmanship movement is gathering momentum with a simple message, and one of the high priests of XP has abdicated.

There's a new focus comming and it cuts right through all excuses, the message is simple.
YOU are responsible.

No one else is going to give you the mandate to work in a fashion you know you really ought to, no one else is going to educate your peers for you, and no one else is going to fix your broken process. Yes I know it's horrible. The business demands the impossible and your cow orkers are all a bunch of imbicils. That's exactly why it's your problem. You're the only sane, educated, competent, levelheaded person around, it's your responsibility to do something about the madness.

We need to stop trying to blame everyone else for our problems, we need to stop discussing what's wrong with "other people" and actually start taking action. Every single day, strive to improve, learn and share!

I'll dub this "Re Evolutionary Development" or RED for short and as all good philosophies it needs a set of principles the first one simply is:

RED Principle #1

Each day ask yourself.

• What did I learn?
• What did I share?

The Care and Feeding of your Build - Stability.

Having an automated, fast, repeatable build provides the heartbeat of the project. Sadly it's often neglected and viewed as tedious to set up, boring to maintain and the only time it actually does get any attention is when it doens't work. Good build systems exhibit a few key charecteristics, today Im going to talk about one of the finer points, stability.

What is stability?

The stability of a build can be stated as:Unless something changed, do nothing.
Or as Ant best practices item "14. Perform the Clean Build Test" puts it:

Assuming your buildfile has clean and compile targets, perform the following test. First, type ant clean. Second, type ant compile. Third, type ant compile again. The third step should do absolutely nothing. If files compile a second time, something is wrong with your buildfile.

Why stability?

Stability is important since it has a direct effect on the length of your build/test cycle. Any inefficency introduced grows both with the project and with the number of team members. This means that unless you keep your build stable every compile will cost you a small amount of time, for every team member, over time this adds up to substantial amount.

Easy ways to fail.

There's a few ways that almost every build system I've worked with failed the stability test the most common offenders I've found are.

Unconditional Post Build xcopy

It's often convinent and sometimes neccessary to copy output files to some other directory. Often this is done to create smaller solutions/projectfiles for the IDE and more stable projects are simply built and copied to a folder with precompiled binaries and referenced from there. This is a good strategy. The problem arise when the copy is unconditional since this often forces a rebuild of all dependent projects even though the shared library did not change! If you're using Visual Studio, unless you got a really really good reason always use "When the build updates the project output" option for "Run the post-build event:". If you're using Ant/NAnt/Rake/ and have a target that does compile+copy always check before copying.

Unguarded build targets

Common offenders in this category is test/coverage targets, creation of installation packages and "zip tasks", care should always be taken to ensure that something actually did change before redoing theese procedures. Often this can be accomplished by comparing timestamps for the source and destination files. If no tangible output is generated by default it can make sense to introduce a marker file and touche it on completion of the task.

Summary

Keep your build fast by avoiding redundant work, take care to never do work unless something actually did change.

Manifesto for Software Craftmanship

Ever felt that there's something missing from the Agile Manifesto? Feeling left out in all the management fluff? Ever wondered, but where's the focus on my craft? I sure have.

There's a old, new, movement on the raise, a movement for software craftmanship. Sign the Manifesto for Software Craftmanship and help us raise the bar.

Pizza Points - story estimation made round!

There's two commonly used methods for agile estimation Story Points and Ideal Programming Somethings, commonly days or hours. Both methods have their merits with some bias towards Story Points (SP) from Mike Cohn and various other well known names although Ideal Programming Somethings seems to be more commonly used by the teams I've spoken to.

There seems to be quite a bit of confusion regarding how they relate and how both terms relate to hours. To remedy some of this I want to propose a new system, Pizza Points, that is driven by an easy to explain intuitive and rich metaphor.

Lets look at the similarities between work and pizza as used in the following discussion.

• Pizza is round, work tends to be circular.
• Pizza can be filling and deeply satisfying, as can work.
• Pizza comes in different sizes, as does stories and tasks.
• Pizza can have lots of varying and interesting fillings, work can be filled with many intresting things.
• As we mature we can eat more pizza and as we learn a domain and tools we can tackle bigger tasks.

Depending on the peculiarities of your favourite pizza parlour the size and form may vary, maybe you have children, normal and family, maybe the range is small, medium, large, and extra-large often it's round and sometimes you get oddly square bites. There's no guarantee that a small pizza is the same size between to different places and there's likewise no sense in assuming that a pizza point is equally sized between two teams. That said, if you stick to one place, keep your team intact, any given size will overtime be quite consistent.

So how do we get started using Pizza Points?

We have to start by establishing some sort of baseline size, no diffrent from the initial sizing of story points. Find a fairly small, easily graspable story discuss the criterias for done and label it "children", "small" or why not, one. Continue estimation by thinking about the relative *size* not filling, give them descriptive names, standard, family, 2, 3, 5, 8, 13, 20, 40, 100, xxx-large.

It's as easy as that. The thing to remember is that size is actually a constant but the filling might greatly influence how much we can eat. I like pizza and can eat quite a lot given toppings like different cheeses, ham, pineapple for example. Give me anchovies and you'll have me struggling an evening to come close to finishing even a child size bite. The size haven't changed, my aptitude and motivation did.

If you're the one placing orders and want to get as much pizza eaten as possible during any period of time it can be wise to ask your team for their taste preferences. But real life sometimes dictates that we put anchovies on their plate, that's a big responsibility.

To summarize, think size not filling, match fillings to team, expect size to vary depending on team. Also expect mature, adult, teams to eat more than children.

And don't forget to order planning pizza as a reminder during long estimation sessions.

The story about TypeMock.

To mock or not. That's the question. Here's how I think some BDDers and Mockists labled their Kool-Aid before drinking it.

Given TypeMock
When I want to test
Then everything looks like a mock object.