Richard Banks - Agile and .NET

When the Programming, Mother**** site first showed up some time ago I though it was kind of amusing. At it’s heart it’s an over the top response to people who claim to be doing agile but are instead forgetting everything agility is about, killing team productivity, wasting time, screwing over their customers and doing what they’ve always done but under a different flag. I also, mistakenly, thought that it would die down like so many other rant sites and then disappear. Instead it managed to hit a sweet spot for many people; people who missed the irony and who instead love to trot it out as an excuse for doing whatever they damn well please and ignoring what it means to be a professional software developer.

If you are one of those people who brings up the Programming, M**** site, even in jest then please, stop!

You only help to reinforce the perception that programmers are a gabble of childish, arrogant, self-centred malcontents who think they’re smarter than everyone else, that code is the only thing that matters and who then react with hostility when challenged about why they are doing something or when asked to do something they don’t feel like doing. One would think that as long as you write great code then who cares if it actually does what your customers or users need it to? Who cares if that feature you just took a week to perfectly code will never be used? At least you had fun writing it. Who cares if the usability of what you built is so horrible people would rather stab their eyes out with frozen prawns than use it? If you’re a Programmer, then you write code and that’s all that matters!

Oh, what’s that? You don’t care if anyone thinks you’re a professional? You think you already act professionally; it’s not your problem if the requirements are daft and the users are stupid? You just want to be left alone to write great code since other people just get in the way of doing the best you can? Being professional would stifle your creativity? Well, that’s your right, I suppose but I beg to differ.

Just pause for a moment and have a look at some of the epic fails across our industry and then ask yourself again wether we shouldn’t think a little more beyond the code we write. How about the 21 dead from a radiation overdose, or the woman killed when an ambulance respirator crashed or insulin pumps that are susceptible to remote attacks. And it’s not just software that can directly impact human life either. Think about the regular disclosure of personal information through poor security (too many to cite), regular air travel glitches, entire regions of Canada losing communications, people unsuspectingly racking up massive mobile data charges and a whole lot more. Software runs pretty much everything these days and while some blame lays in the way projects are run, much of what we’re seeing in the world these days can be laid at the feet of programmers who acted unprofessionally and forget their prime directive; helping their customers.

Everyone has the right to act as stupidly and childishly as they want on their own time, but when it comes to the workplace and being paid to write software other people will use then it’s high time to get over any sense of entitlement one may have and grow up. If you believe that knowing how to write code or that an understanding of how computers work somehow makes you special and that should be treated differently, then you’re dead wrong.

The only thing that will make you special is how much of an impact the software you build has on those who rely on it, and for that you’ll need to do a whole lot more than just writing awesome code and Programming, M****

• Labels:
• development


• 0 comments
• Leave A Comment

 

A number of Australian agile community people, including my colleague Steve Godbold, have decided to run a conference for Lean and Kanban approaches.

The interesting thing about this conference is that it is being funded and run using a crowd sourcing model and the organisers need to know if there's enough interest to run this thing.  Of course, this means they need you to get behind it and pledge something towards it and sooner rather than later.

What do you need to do? Two things:

1. Go to http://www.pozible.com/lkanz and pledge something towards the conference
2. Spread the word.

Simple!

• Labels:
• agile
• community


• 0 comments
• Leave A Comment

 

In Visual Studio 2012 Update 1 (VS 2012.1) Microsoft delivered a feature for the Ultimate edition called Code Map with the goal of visualising relationships in code.

In Visual Studio 2012 Update 2 (VS 2012.2) they’ve extended the Code Map experience to include debugging support and the ability to generate code maps on the fly as a debugging session is conducted.

If you saw the announcement then you may have had one of the following reactions. Reaction 1 would be something like “Oh. It’s in Ultimate. I don’t have it. I’ll ignore it”. The second might be similar to mine: “Is this really going to be that useful?”. After ignoring it for a bit I decided to answer that question for myself.

For the purposes of this post, I’m used the excellent RestSharp project. You can grab it from https://github.com/restsharp/RestSharp. Oh, if you’re not aware of what it does, it’s a library that help’s you build REST based client and server applications by taking away a lot of the plumbing work you would otherwise have to do.

Getting Started

To start begin by asking a simple question. How does RestSharp make a client request? I’d never looked at the internals of RestSharp before so I wasn’t sure where to look.

Fortunately RestSharp comes with a set of unit and integration tests that I could use to explore the code with. I started with the integration tests and tried to find a suitable test in there to use and came across the Handles_Non_Existent_Domain() test. That seems a reasonable place to start. Note that if you want to follow along at home you’ll need the XUnit.Net Test Runner for Visual Studio 2012 extension installed since the tests are written for xUnit.

First thing to do? Set a breakpoint on the first line of the Handles_Non_Existent_Domain() test and start debugging the test. When the breakpoint is hit open a Code Map for the debugging session by either clicking the button in the toolbar (highlighted in the screenshot), choosing Show Call Stack on Code Map from the Debug menu, or pressing Ctrl+Shift+` if you’re using the default keyboard mappings.

Visual Studio will now split the document window and display a second document pane with the code map in it. Initially the code map will looks like this:

Not very interesting, right? Don’t worry, it gets better. Let’s start stepping into various methods to see how this test works.

Stepping Deeper

Press F11 to step into the RestClient constructor. As you do, you will notice the code map updating. Continue to step through the code until the first call to AddHandler() has completed. Your Code Map should now show something like the following:

Note that as we step back up the call stack that the colours of nodes in the Code Map change to reflect that methods we have called but that are no longer in the call stack. It helps us keep track of where we’ve been, not just where we are now.  This is kinda cool. I no longer have to mentally keep this tree in my head, and can focus more on what the code is doing rather than where I’ve been and which methods might be relevant later on.

Depending on your resolution, you may also start noticing the zoom level on your Code Map keeps resetting. If you want it to use a specific zoom value then go to the layout options and turn off “Automatically Layout when Debugging”

What Happens When You Skip Over Methods?

The code map only updates when execution pauses. It means that if you step over methods the Code Map will not show you what happened in the code you stepped over. It also means that if you use multiple breakpoints and after hitting the first breakpoint continue execution until you hit the next one, then the Code Map will only reflect the call stack from when the breakpoints were hit. You won’t see anything related to what happened in between breakpoints.

It helps keep the noise in the map down, and presumes that if you’ve skipped over code you’re also not interested in seeing it in the map. That seems to be a reasonable assumption to me.

Anyway, let’s get back to the test we were stepping through and continue execution until we get to the line that calls the Client.Execute() method.

As you step into the method the Code Map will update. Look at the tooltip for the newly added node and you will see details of the method itself based on XML Doc comments, as shown:

This can be handy when you’re deep within the bowels of something and can’t remember exactly how you got to where you are or which specific overload of a method was called.

If we then step into the switch statement, we see that we’re passing in a value of Method.GET. It might be handy to remember that; especially as both parts of the switch statement call Execute(). We can make a note of that on the Code Map by right clicking the node and selecting Add Comment (or hitting Ctrl+Shift+K)

At various point you’ll notice that the some calls go through external code first. The code map will reflect this when it occurs by marking the fact on the call stack arrow, as shown.

Way Down Deep

If you continue to step through the code you will eventually get to the RestSharp.Http.GetRawResponse() method and your Code Map will start to look somewhat busy, as follows:

A lot of the nodes in the Code Map are not that interesting now that we’ve stepped through things and are improving our understand of how it fits together. It’s fast becoming noise. To organise the map better we could simply select nodes we’re not interested in anymore and delete them or we can choose to group them by selecting a few, hitting the mouse right-click context menu and choosing Add Parent Group, to get something like the following:

We can then simply collapse groups to hide items we’re not really interested in at the moment.

With a little bit of judicious grouping I produced a Code Map as follows and now I have something that helps me better navigate the internals of RestSharp and get familiar with it.

Wrapping it Up

I can add to this map over time as I explore the code further and step through other tests to see how it works, I can also get a feel for which parts of the code are called often and what happens in those methods.

If I wished I could also save the code map and share it with the rest of team, or grab an image of it and post it in the team wiki for documentation purposes or put it on the wall as a reference.

While Code Maps might seem a little gimmicky at first, I’m finding them fast becoming an useful tool in helping me better understand code I’m wading through and in improving my knowledge of what exactly is happening when I’m using an application.

Give Code Maps a try (assuming you have a copy of Ultimate) and see what you think.

• Labels:
• development
• Visual Studio


• 0 comments
• Leave A Comment

 

The Scrum Australia 2013 conference has just finished and I had the pleasure of delivering a session for Product Owners aimed at helping them improve what they do and identify some of the mistakes they may be making. A big thank you to those who attended and for making the session as interactive as it was.

As promised, I’m posting the slides from the session here. Just remember that the slides are an aid to the presentation and that the back half of the deck was designed for interactivity in the room, not for offline consumption. Regardless, here it is.

• Labels:
• agile
• presentations
• scrum


• 2 comments
• Leave A Comment

 

n 1981, Barry Boehm published information on the cost of change in software at various stages of the development cycle. The following chart shows this cost curve:
 
Boehm's Cost of Change Curve – 1981

This model has historically led the industry to believe that the most important thing we can do is “get the requirements right!”.  The thing is, the model above is somewhat incorrect. It assumes a traditional software development lifecycle is the only way software is built and that working software can only be used at the end of a project.  With the rise of agile development techniques this is no longer true and we can deliver usable software every week or two.

Also, from the chart, consider that bottom axis – time. Time here represents the length of the feedback cycle; i.e. how long it takes to realise a problem exists and that a change is needed. Time is the critical element in determining the cost of any change. The longer we go before realising we need a change, the higher the cost of that change.
In an agile approach, the short iterations of a few weeks or less result in a much shorter feedback cycle.

Scott Ambler published the following chart on the cost of change in relation to defect correction and the point in the development cycle where that defect is detected.  Again, the longer the feedback cycle the higher the cost of rectifying the problem.

Image via Scott Ambler - http://www.ambysoft.com/essays/whyAgileWorksFeedback.html

So by using Scrum and putting in place good engineering practices alongside a short feedback cycle we establish a number of mechanisms that help us rapidly detect mistakes in both requirements and their implementation. This in turn allows us to take corrective action and fix the problem while it is still cost effective for us to do so.

In the end, this helps us keep our application quality high and provides better value to our end users and customers.

• Labels:
• scrum


• 2 comments
• Leave A Comment