Mar 31, 2010

Coding Dojo’s, Alt.Net and Continual Improvement

Last night at the Sydney Alt.Net user group I facilitated a Coding Dojo.  There’s a short summary of how it went on the site. I won’t repeat what I’ve said about it there since you can read it for yourself.

Instead I will say that I felt very privileged to be able to watch a great bunch of developers working on code in a such a supportive, open and enthusiastic manner and seeing them have a helluva lot of fun at the same time. It was an excelllent night overall and I’m so looking forward to when we run the next one!

The point of this is that it also reminded me again of why Alt.Net exists in the first place.  Let me quote the ozalt.net site:

The Australian Alt.Net Community is a self-organizing, ad-hoc community of developers bound by a desire to improve ourselves, challenge assumptions, and help each other pursue excellence in the practice of software development, obviously with a strong emphasis on development using the Microsoft.NET platform.

The emphasis in bold is mine.  Tackling a coding dojo and attempting to solve it using different techniques and technologies is an awesome way to improve yourself, challenge your assumptions and in group situations gives you the opportunity to help others improve as well and this was very much in evidence last night.

Ask yourself this; when was the last time you deliberately tried to improve your skills or challenged yourself and the way you do development?  When did you last try to help someone pursue excellence?  I’m hoping it was last night or even today, but if it wasn’t then don’t despair.  Make today a day where you do just that. Where you do improve and where you do help someone else to improve.

For me, I love continual improvement. It’s the reason why I write this blog (thanks for stopping by!), why I run the Sydney Alt.Net group with James Crisp, why I started the Talking Shop Down Under podcast, why I do public speaking, why I contribute to open source and why I do consulting.

Obviously you don’t have to do what I do, but I would encourage you to seek continual improvement and to do so in a practical manner.  Reading books and watching videos is great, however you do have to do something otherwise everything you learn is just academic head knowledge and you won’t understand the pitfalls and potential gotcha’s in something unless you try it, and unless you try it for yourself how will you show others how it works?

So at lunch today or on the commute home, try working on a kata with the aim of either learning a new technique or language or honing your skills. Or organise some “brown bag” lunch time tech talks with your fellow developers to show off things you’ve learned recently, or answer some questions on stack overflow or other tech forums, or write your own blog about things you’ve learned recently.  Just make sure you do something because it’s in the act of doing that you truly learn things and bring about improvement and change.

Mar 24, 2010

Personal Time Management and Agile

Agile frameworks and approaches put a high degree of attention on getting things done quickly and efficiently.  The end goal being to get software into production as efficiently as possible with a level of quality that makes the customer happy and provides a good return on investment.  You will often hear people talking about agile (and lean for that matter) also talking about waste and using “inspect and adapt” to minimize wasted effort.

One of the things I see teams doing regularly is taking a day to day approach to development that completely ignores personal time management.  A team may estimate a task to take, say 8 hours, and generally it will get done in or around that timeframe (it is an estimate after all), but if you actually watch how people approach completing that task it soon becomes apparent that the 8 hours spent on that task isn’t really 8 hours of good solid effort at all.

The task may have had 8 hours elapse between when it was started and when it was finished – but the actual time spent on the task is typically somewhere between 4 and 6.  Where did the other 2 to 4 hours of time go?  Sure there’s toilet breaks, coffee runs and helping out others on the team out, but that’s not 2 to 4 hours each and every day is it?

This lost time is what teams typically refer to in planning meetings as their “focus factor”. Some teams have a focus factor of 50%, other teams a focus factor of 75%, whatever.  Either way, teams are looking a potential performance improvement of between 33% and 100% right in the face and doing absolutely nothing about it! In fact, they are institutionalising low productivity and calling it good planning. Really, all they are doing is admitting that change is hard and giving up before they even try and improve things.

This is where a team doing retrospectives and wanting to improve can really make a big gain.

As an example of this lost time, let’s have a look at just two things that tend to suck up those non-development hours.

Email is the Great Evil of Our Time!

Maybe that’s going a little too far :-) However the next time you get an email from someone, see how long it takes to put your response together.  If you write a response that has more than one or two lines in it then I’m going to guess that it will take you a LOT longer to write that response than it would have if you had just talked to the person in person or over the phone.

In fact if you really want to scare yourself, go grab a copy of ManicTime and use it see just how much time you spend in your email client of choice. In fact, do it anyway.  Download it, install it and run it just for one day and look at the results.  You might just find that your focus factor of 75% was too high!  Maybe that explains the difficulty you’re having getting sprints completed well.

Oh, if you’re in one of those organisations where email is used as the ass-covering tool of choice, don’t forgo conversations and revert to email just to cover your butt.  Use email as a confirmation tool and note down bullet points from your conversation – during the conversation – to later send through a “just confirming what we talked about in our phone call” email instead.  It’s much quicker.

Multitasking and Self Induced ADD

Multi Tasking is the other great way to slow yourself down.  The cost of task switching for humans is nasty – our brains just aren’t wired up the right way to be able to swap in and out of context quickly.  We may convince ourselves that we can, and we may try to lie to ourselves about how the tech generation are all skilled multi taskers, but really, it’s all bubcus and an excuse for being unable to concentrate for more than 2 minutes at a time.

squirrel In fact all we really do when we have multitasking as our modus operandi  is become really good at starting things and become really terrible at finishing them.  Why? Because constant task switching trains our brains to have short attention spans.  Short attention spans mean that we have a problem whenever a squirrel shows up.  We’ll get distracted and go chasing after it and to get back on track we have to sniff around what we were doing before and try and piece back all the various things we had in our head before the distraction showed up in the first place.

Short attention spans create an illusion of being productive through the act of being busy. We generate lots of movement and energy when we’re busy, but in reality all that movement just creates a big dust cloud that masks just how little progress we make.

For us humans, the best way to finish tasks as quickly as possible is to do them sequentially.  This costs us a single context switch between tasks instead of a context switch each time we change from one task to another.  For us developers locking in on a single task also gives us the opportunity we need to get us into the zone – that magical place where high quality code just seems to fly out of our fingers, where we flow from one thing to the next with ease, and where we get stuff done ten times faster than we would have normally.

Sure it sounds great, but development has so many chances for distraction.  Not sure how to do something?  Google it, see something else interesting and go investigate that instead.  The task we’re doing is boring? Let’s take a little break and play solitaire for a few minutes.  This compile is taking more than 5 seconds?  Maybe we’ll just check email while we wait.  it’s all self induced ADD and we need to learn to stop.

So What’s The Answer?

It comes to this: Personal time management, discipline and focus.  How do you, yourself, personally, manage your time as an individual? How do you maintain focus? How long do you maintain it for? When do you take a breather since all that concentrating can be tiring?  How tired are you right now?

First up, let’s deal with some simple distractions.  Have a look around you right now at all the possible distractions you have – twitter, facebook, rss feeds, email, news sites, instant messenger, a side conversation you could join in on, that delicious smell coming from the kitchen, txting, flash games, the list goes on.  Things like twitter, outlook and IM in particular can be really nasty because of their interrupting “new message” toaster notifications and beeps.  Turn those notifications off.  Do it.  Go into settings and turn them off.  Right now.  It’s OK to leave those apps running, just delay checking for new tweets, emails and messages until until you finish what you’re doing.

What if you’re waiting for that compile or CI build to complete, what do you do? Press Alt+Tab and go read a blog entry or 5 for the next few minutes?  It’s easy for that few minutes to turn into 10 or 20.  And yet the compile itself only took 3 minutes to complete. That’s a lot of wasted time and a definite mental context switch you have to deal with.  Yet watching a compile is mind numbingly dull. So why don’t you think about some refactoring you could apply, or the next test that you could write, or the design for the next task that you’ll get started on next.  There’s plenty of non-keyboard activities you can do that keep you focused on the task at hand and not chasing squirrels.

This is also where techniques such as the Pomodoro Technique and pair programming can help.

Pairing provides a focus boost simply because you have someone next to you who is also focused on the same goal as you. The two of you keep each other on track.  I’m not going to delve to much into pairing here, however if you consider what it does for our focus factor you can see how teams that use pairing can easily get a return on the supposed cost of putting two people onto a single task,  simply because they won’t get as easily distracted and can thus complete their tasks faster.

imageFor individuals not in a pairing situation, the Pomodoro Technique is a simple process they can follow and works like this:

1. Choose a task to be accomplished
2. Set the Pomodoro to 25 minutes (the Pomodoro is the timer)
3. Work on the task until the Pomodoro rings, then put a check on your sheet of paper
4. Take a short break (5 minutes is OK)
5. Every 4 Pomodoros take a longer break

Quite simply it says focus on just one task until either the task is complete or 25 minutes is up.  When that happens, give yourself a mental break.  It’s effectively a series of short, sharp personal sprints.

When you’re working on your 25 minute pomodoro you don’t open email, you don’t look at twitter, you don’t check news sites, you don’t get a coffee or anything else.  You just work on the task.  All those other things are for filling those 5 minute breaks you have.  And if you’re in an organisation with a plethora of email – then one of your pomodoros should probably be spent dealing with that email!

Oh, don’t worry if you don’t have a clock that looks like a tomato either.  Just grab yourself one of the many pomodoro timer apps, such as FocusBooster, and use it instead.

You may find this hard at first, but once you do it a few times, you’ll find it becomes easier and easier to do.  You’ll find that without any changes to technology, skills, work hours, or otherwise that doing this will result in an increase in team productivity and velocity – and all you’ve had to do is be a little more disciplined and a little more focused on the task at hand.

Let’s work smarter, not harder, right?

P.S. The irony that a long post like this isn’t likely to be read all the way through by people with short attention spans isn’t lost on me! ;-)

Good luck!

Mar 16, 2010

New Gadget: Blue Snowball Microphone

As part of my desire to improve my podcasting techniques (for the Talking Shop Down Under podcast) I’ve just gone and purchased a Blue Snowball microphone.  Here’s a few pictures of what it looks like:

IMG_0054

IMG_0055 

What surprised me was the size of it.  From promo photos on the web you can’t really get a feel for the size of it, but the impression is that it was about half the size it actually is.

To try and get a feel for the sound quality difference, I recorded some audio using my Logitech headset, a Guitar Hero World Tour microphone, and then the Snowball, using each of the 3 settings.

The audio is completely unedited, including all my ums and ahs and clicks as I flick switches on the back of the snowball so it should give you a good idea of what it’s capabilities and sound levels are like.  I should mention that the snowball audio sounds a little echoey simply because I recorded in my kitchen area and there is nothing to deaden the sound so it’s picking up audio reflected off the walls and floor :-)


Download mp3

Mar 11, 2010

Rethinking the IDE

Aymeric posted a link on the Readify internal tech list today showing a fresh approach to navigating code in an IDE. Here’s the link: http://www.cs.brown.edu/people/acb/codebubbles_site.htm

And here’s the YouTube vid to save you clicking through.

It’s a really novel and interesting idea and one I would absolutely love to see working in Visual Studio 2010.  Given that 2010 uses WPF under the hood and has a great extensibility model, I think it’s entirely do-able, though not something I’d take on myself.  I wonder just how much it would change the way we approach common conventions such as one class per files when the IDE effectively removes the whole source file concept allowing you to focus solely on your classes and their methods.

Kudos to Andrew Bragdon for coming up with this. It begs the question then… If you had to rethink the IDE what crazy, out of the box ideas would you come up with?

Mar 4, 2010

MSTest Sucks for Unit Tests

Inflammatory title?  Maybe. But I'm not the only person to complain that MSTest is bad and should only be used when no other alternative is available.  But those who don’t know better will say that when you look at all the unit test frameworks they all do much the same right? So how can MSTest be that bad?
Well, first up, MSTest is slow. To be fair, MSTest when run from the command line runs quick. From the command line you won’t notice much difference at all between MSTest and the other unit testing frameworks, but who runs MSTest from the command line?  Most people run it from within Visual Studio, and when you do, it is really really sow. It does all that assembly copying behind the scenes, it waits for the test results window in the IDE to update and then, finally after all that is done, only then does it run the tests. If you’re writing and running lots of unit tests (you are, aren't you?) then this startup delay is real hindrance to flow and after a while is a major pain in the butt. So much so that many people stop doing tests after they hit a few hundred or so, simply because of the time it takes to run them.
But if speed were the only issue, then maybe the other features would make up for it.  After all it has those cool data driven tests right?
Well, lets consider an example.  Let’s say I’m doing the bowling game kata and I want to use a data driven test to check a number of scenarios.  Here’s what I’d have to do:
1. Create an XML file to act as a data source
<?xml version="1.0" encoding="utf-8" ?>
<Rows>
  <Row>
    <Scores>0123456789X</Scores>
    <Results>0,1,2,3,4,5,6,7,8,9,10</Results>
  </Row>
  <Row>
    <Scores>935345XXXX</Scores>
    <Results>9,3,5,3,4,5,10,10,10,10</Results>
  </Row>
</Rows>
2. Now create a data driven unit test using MSTest
[TestClass()]
public class ScoreEngineTest 
{ 
    private TestContext testContextInstance;

    public TestContext TestContext 
    { 
        get
        {
            return testContextInstance;
        } 
        set
        {
            testContextInstance = value; 
        } 
    } 

[TestMethod] 
[DeploymentItem(@"TestProject1\BowlingScores.xml")] 
[DataSource("Microsoft.VisualStudio.TestTools.DataSource.XML", "|DataDirectory|\\BowlingScores.xml", "row", DataAccessMethod.Sequential)] 
public void ConvertStringToScoresTest_DataDriven() 
{ 
    ScoreEngine target = new ScoreEngine(); 
    var scores = (String)TestContext.DataRow["Scores"];
    var expectedData = ((string)TestContext.DataRow["Results"]).Split(',');
    var expected = new List<int>();
    foreach (var value in expectedData)
    { 
        expected.Add(int.Parse(value)); 
    } 
    var actual = target.ConvertScores(scores); 
    for (int i = 0; i < expected.Count; i++)
    { 
        if (expected[i] != actual[i]) 
            Assert.Fail("Expected {0}, Actual {1} at element {2}", expected[i], actual[i], i); 
    } 
}

Quite verbose right?  Especially the fact that there is no inbuilt list equality checks nor is there an easy way to use list based data in the data source.  I had to take a string, split it and manually create a list.  Eew!

So let’s look at the XUnit version.

public class Class1
{
    [Theory]
    [InlineData("0123456789X", new int[]{0,1,2,3,4,5,6,7,8,9,10})]
    public void ConvertStringToScoresTest(string scores, int[] results)
    {
        ScoreEngine target = new ScoreEngine();
        var actual = target.ConvertScores(scores);
        Assert.Equal(results,actual.ToArray());
    }
}


Wow! So much shorter! And so much more intuitive. And an Assert statement that actually does equality checks across IEnumerables as you would expect.

So maybe now you see why MSTest gets such a bollocking by so many people.
To be fair, MSTest is improving, and things like Test Impact Analysis in VS2010 are quite nice, but still... the amount of code to writing a simple data driven test is ridiculous and completely unnecessary.

Mar 1, 2010

Twitual Studio

On Episode 2 of the Talking Shop Down Under podcast (go subscribe!) I was talking with Matt Hamilton and saying how it would be nice to have a Twitter client inside Visual Studio, given that’s where we spend a large amount of our time.

Well, I decided to not just talk about it, and actually do something about it instead.  So I hereby humbly announce the birth of yet another new twitter client, with the difference being that this one you should be able to use from within Visual Studio 2010.  Welcome Twitual Studio!

I’m rather time poor and my WPF skills are really bad, so I shamelessly borrowed code from Rich Stern’s WPF Tutorial and I’m learning as I do this.  That said, if this is something you want to use for yourself and you want to see something genuinely usable sooner rather than later, then I’d love you to help out.  The project is up on Codeplex and uses Mercurial for source control, so feel free to clone the repository, hack the thing to pieces and send your patches through to me.  I’d love to have them.

For the curious, here’s an early screen shot of what it looks like:

twitual studio