George Mauer is on the Net

Screencast: Keeping Features Out Your Way With Branching

Pop quiz:  What’s the software developer’s biggest enemy?  It’s not marketing.  It’s not those snot-nosed DBAs.  The rigid chair that will invariably give you arthritis?  Nah.  Your know-nothing boss?  Not even close.  No, the developer’s biggest enemy is the customer.

That’s right customers and their god d*mn feature requests and bug reports!  Life would be so much easier without them.  And acknowledging the absurdity of that statement, unless you are some kind of programmer Adonis (which unlike a regular Adonis physically implies only that your esophagus is invulnerable to lesions caused by Bawls) and write flawless code you will have to deal with feature requests that can rapidly pile up and overwhelm your development process.

I had mentioned previously on this blog that I am working with a team of Indian contractors and this is exactly what they found happening with the latest high stakes omg-fix-this-now-or-we-all-die release.  The team was behind and the release went out mere minutes before users started working with it.  Of course in the rush to finish on time bugs cropped up and features were left out.  Lots of features.

So immediately the next morning, with tickets raining down and demands for new drops every day the team got to work.  And the daily releases never came.  On the 3rd day we finally dived into their process with them to identify the problem.  

Simply speaking, they couldn’t reach a stopping point.  By the time certain features were ready to go others were half-implemented and so no release could be scheduled.  It was like some sort of real life Zeno’s paradox.  Fortunately this one has a solution.  Fully acknowledging that it is probably named differently in a dozen books and Agile pamphlets (just not any that I’ve seen), I call it branch-per-release or “how to use source control to get yourself out of a tight spot”. 

The idea is blatantly simple:

  1. Chose a release date
  2. Decide which features will fit in that release date
  3. Use your source control chops to create a branch for that release
  4. Decide what release each of the features on your plate goes in
  5. Create a branch for each of those releases
  6. Implement each feature set in the branch for its release
  7. When development on a branch is completed and tested, reintegrate into trunk.
  8. Rinse, repeate.

I have created a presentation and a series of screencasts (3 x 5 minutes thank you Jing) to demonstrate the process.  And here they all are:

Apparently embedding videos on is a pain in the *ss (as is code highlighting) so as mere links they must stay.

Creative Commons License
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.


June 4, 2009 Posted by | ALT.Net, Programming | Leave a comment

Of Cavemen Jeff Atwood and SOLID

Jeff Jeff Jeff,

Reading your blog has always been a bit like programmer masturbation, it mostly serves to make the reader feel great about what an inquisitive and intellectual developer they are.  That’s ok though, it keeps people reading and just through the sheer volume and accessibility of your writing you’ve pounded into people’s skulls some extremely useful ideas, frequently without them even realizing it.

Heck, it was you that got me into reading programming blogs (tip of the hat to Steve Yegge as well) and that is precisely why this whole tiff with Uncle Bob is just silly and your latest defense the lamest of all.  You reach far more people than Uncle Bob does, you acknowledge that the SOLID principles are good ones, you say that the problem is with capturing the ear of the uninformed – and then you put them down?  Give me a break!

I don’t have time to rant at length like others have but consider this:

Captain Caveman!

You know who were really the original unreachables?  Cavemen.  Completely in isolation from each other they decided it a hassle constantly having to seek out rock outcropping roofs and moss mattresses and all on their own they started piling rocks on each other to make houses.

Sure when the Assyrians invented the arch the Egyptian and Aztec builders didn’t hear about it, but eventually the Romans came along and in that very Roman way searched out the best ideas and decided to apply them to their own projects.  Good thing the Assyrians didn’t have bloggers.  They might have declared the arch unfit for popularization due to the infeasability of their marketing.

We’re at the very beginning of this stuff, lets encourage the good ideas, no matter who is listening.

Update: InfoQ has a roundup of the whole debacle.

February 16, 2009 Posted by | ALT.Net, Programming | Leave a comment

Re: What is Unit Testing?

In a post last month Zachariah Young posts that 

… unit tests … verify that the business logic is correct.  I believe that for it to be unit testing it has to use a testing framework like nunit or junit.

I say thar be dragons!  Tying your understanding of unit testing to a specific tool allows you to neatly sidestep thinking about whatThar be dragons  testing actually does.  Additionally, you deny credit to an excellent tool like NUnit by pigeonholing its purpose.

Consider for a minute what NUnit actually is.  Yes their own website claims that they are specifically a “unit testing framework for all” but what does it actually do?  In my opinion it is a framework for setting up an application’s state, executing code, and then asserting that the resulting state is as you expected. That’s pretty broad.  Way broader than the confines of mere unit testing.  

Take the excellent WatiN or (no longer maintained) NUnitASP tools.  Both can be run using NUnit but neither is used to build a true unit test.  WatiN for example remote controls your browser to investigate how your page will react to certain stiumuli.  What unit does WatiN test?  Your Page_Load method?  Your page renderer?  Whether the viewstate persists that you had entered some text halfway up the page before submitting and the text is not cleared when your page returns with a validation error?  The localhost routing mechanism on your PC?  Or does it test the integration of all of these?

I made the same exact mistake myself when I decided to ‘see what this TDD thing’ is all about last April.  I ultimately had to delete my entire testing project after I came to the realization that each test bit off far too large a chunk making it utterly impossible to maintain once true refactoring started.  I nearly cried that day.

But out of the ashes I was reborn with what I hope (but don’t really expect) to be the final zen-like understanding of this unit testing thing.  The first aha moment was when I finally caved in and decided to learn Rhino Mocks and my understanding sharpened when I caved again and looked into the new Rhino Mocks 3.5 AAA syntax.  Overall the lesson seems to be that I’m always wrong and I will eventually give in on everything and like it.  My girlfriend will be happy to hear that.

Let me tell you how I understand unit testing now.  Imagine a room.  You are standing on the outside and can comunicate with its ouccupants through a two way loudspeaker.  This room is your unit – if it helps you can imagine the room as painted black.  Now in testing you present your unit with a problem:

Given that you are on 735 Bourbon St New Orleans, Louisiana how far is it to my grandmother’s house?

I used to think that unit testing involved merely waiting for the answer:

Your grandmother’s house is 1345 miles away and you haven’t visited in months you shmuck.

Now I realize its more about everything else that is said.  “Where does your grandmother live?” and “Can you be so kind as to  slip an atlas under the door?” should definitely be questions that you hear over that loudspeaker.  If you’ve separated your resposibilities properly the unit will also require a calculator that given two points on a map can tell you the distance (the specific calculator implementation should depend on whether you intend to fly or use the highway system).  The unit might even request that you hang a EnRouteToGrandmas = true sign on the door.  

The point is that you’re not so concerned with the final answer as much as you are with the unit asking the right questions.  Afterall, without that information know that it could not possibly be doing what you mean for it to do!

And so I define unit testing as

Verifying that given an input, a piece of code makes all the external requests that you would expect where the unit is small enough that the number of these can be enumerated with ease.

Note that this definition does not necessitate automated testing and this is something that I again think is basically correct.  After all, a framework should not do anything that you cannot do for yourself.

The beautiful part is if you’re limiting the amount of requests that you’re going to expect – let’s say no more than four – single responsibility emerges almost all on its own.  After all, how much can a piece of code do if its not communicating with the external world?

So there you go, thats my understanding of unit testing.  I look forward to being proven wrong in the future and having to refactor everything all over again.  But until that time,  Zachariah, you’ve been blogo-served!

Disclaimer:  I do not know Zachariah personally but he seems like a smart guy that is highly involved in the ALT.Net community.  I do not purport to be more knowledgeable than him in programming issues, I just disagree with him on this one point.

kick it on

January 15, 2009 Posted by | ALT.Net, Programming | , , | Leave a comment