Wednesday, July 28, 2010

Mountain Living Considerations

A friend of mine is considering moving up from the plains along the Front Range of Colorado to the higher elevations such as where I live. Here are a few things I think anyone contemplating such a move might want to know...
  • It gets cold in the mountains so house orientation, big windows for passive solar heating, a good heating system, woodstoves as backup (and even primary heating source since they are cheap) and quality home construction/insulation are important
  • Snow slides off metal roofs, asphalt not so much.
  • New houses have new septics, old houses may not. They are expensive to replace.
  • You want a good well, i.e. one that has a good flow. Don’t compromise.
  • Mud drives are muddy in spring for weeks. Stone chippings can hide this a bit but ultimately, it seems, you will still get muddy unless you bank on frequently topping up the chippings. Asphalt drives work but look completely out of place to me.
  • Steep drives are a pig to clear of snow. Although you could contract somebody to do it that somehow defeats the sense of independence one gets from living here.
  • Limited cellphone coverage. AT&T where I am and much of Gilpin.
  • Check broadband internet availability
  • Having lots of aspen trees on the lot is awesome because you might lose pines to beetle…
  • Note where school bus routes are since those roads get plowed by the county first
  • Surrounded by trees, by creek/pond/lake, with a view. Pick one, or prepare to pay a premium….
  • Housing styles vary from Front Range bedroom community transplants to super rustic cabins. This may or may not be important to you but some people don’t care for houses that look way out of place. Personally I favor a home that looks like it belongs in the mountains.
  • Steep narrow roads aren’t as bad as you think in winter with 4WD and snow tires. They are much more exciting in spring with the constant thaw/freeze cycle. You do need those snow tires though.
  • Winter is undeniably longer, but it’s still sunny up here just like the rest of Colorado. You can get your warmth fix by going on vacation to the plains a few thousand feet below.
  • It may take a bit of getting used to, but actually not having Safeways, Target etc. just around the corner is kinda nice. A little more planning to avoid meal disasters perhaps, but its not too bad.
Lastly, something I read years ago that left me eager to move to the mountains is this primer on mountain living from Gilpin County. You'll either read it and want to move tomorrow, or it will scare the crap out of you and you'll never entertain the idea again.


Monday, July 26, 2010

Autonomy. Mastery. Purpose.

Many thanks to Steve who helped out with this. I actually re-purposed our internal post for here and left out 99% of his work (no offense, just wanted this to be "my" post rather than posting your stuff Steve without permission...and I'm too lazy to ask ;-)

Here's my list of recommended best practices for the three different roles in scrum:

Scrum Master

Product Owner

Team Member

Yes that’s right. The lists are empty. Well, why is that you may wonder? Funny you should ask…

First of all "best practices", besides being a rather hollow business-speak term, are things that don't really work everywhere for complex pursuits like software development. Principles can help guide you, examples of what other people have tried might prove inspirational. But "best practices" as typically bandied about today are not really right for broad Scrum adoption in a corporate setting. Go ask any of the signatories of the original Agile Manifesto.

Standardization and one-size-fits-all mentality is a very command-and-control approach to applying Scrum and completely at odds to what it’s really trying to tell you. Most intelligent, thinking people (that is the kind we want working here, right?) don’t "own" things that are foisted upon them. They might tolerate them. We want people to own things. That’s how good stuffTM gets done.

Experimentation, discovery, retrospection and continuous improvement are at the heart of scrum.

Let's have a quick reminder of the Agile Manifesto (www.agilemanifesto.org) where we value...

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Really we’re missing the point if we try and find and mandate best practices for Scrum within a large corporate environment.

So what should we be doing?

Again, funny you should ask...

In his book, Drive, Daniel H. Pink explains how intrinsic motivation is key when it comes to work with even the most rudimentary cognitive component. People are looking for three things: autonomy, mastery and purpose. Given what my company does (help bring novel drugs to market as quickly and safely as possible) we should not be short on purpose. We just set things up to afford people as much autonomy and opportunity for mastery as we can and we’re golden. There's no point writing more on that when instead you can watch this excellent presentation of the research behind this in the following short video.

If you’re sitting there wondering if you can spare the 10 minutes needed for this video just watch it. If you play any role in managing or influencing teams of people creating software, watch it. If you care about how to truly motivate them, watch it. If you still think that we should be adding more and more process and templates and documentation and best practices to “enforce” adoption of a “standardized” form of scrum, watch it.

We have to trust the teams to learn and grow, not dictate exactly how they will implement Scrum.

OK, if you really want a best practice for Scrum here is one: DON'T BE LATE TO THE DAILY SCRUM!

Friday, July 16, 2010

Cucumbers, and why it suddenly matters that I suck at regular expressions

This week I have been playing with a new testing tool. Well, sadly not all week as my wonderful HP 8710 laptop snuffed it on Monday morning and despite my best efforts could not be coaxed back to life. This blog post (and my playing with the new testing tool) comes to you from my new Lenovo T410. It’s a bit “toy sized” but it does boot in under 10 minutes (a welcome contrast to the HP) and the build quality is better (although it’s hardly got the aesthetics of a MacBook Pro.)

Anyway, the new testing tool I’ve been playing with is Cuke4Nuke which allows Cucumber to work more easily with .NET projects. That sentence probably is pretty baffling so let me back up and explain what all this Cucumber-y themed goodness is about.

You have (hopefully…) heard of Test Driven Development (aka TDD) as an approach to developing software. For those not too clear what it is, a quick explanation goes like this: Instead of writing your application code and then writing a unit test afterwards (you are writing unit tests, right?) you start out writing your unit test first. Now, this may at first blush sound somewhere between stupid and impossible. If you’ve only heard that one line explanation you’re missing a subtle but key point: when you start writing that unit test first, you need only write enough for it to fail. Then you go remedy that fail by writing production code. Obviously at the outset that point is reached pretty quickly…the moment you reference the class under test (which doesn’t exist yet!) your test will fail. You can’t even compile it:


public class TestWidget
{
public void Widget_Assemble_Success()
{
Widget w = new Widget(); // can’t compile
}
}


So then you switch to your application production code and implement the class under test. But (and this is important) only enough to make the test succeed. At the outset that doesn’t require you do any more than simply create the class:


public class Widget
{
//implementation to be done
}


At this point your test will now compile (and pass, kinda) and you can work more on the test until, once again, it breaks or fails. In the example here that’d be trying to call the Assemble() method on the Widget class. Again we couldn’t compile as this method doesn’t exist in the production code class. We’d remedy that over there and then finally add some kind of Assert into our test, which would fail and then finally we’d get to the meat of implementing the method under test.

That little “dance” back and forth between the test and the class under test may sound a little convoluted and unnecessary, but it’s what helps tease out the initial design of your class under test. It’s what puts the “test driven” in test driven development. It really makes you think about the API, the method signatures, naming etc. of your class under test and after you have the “aha” moment that comes with this approach it’ll all fall into place. Suffice to say I’ve found it really helps not just with driving the design but also with maintaining focus too. Trying to write sizable amounts of production code before unit tests was always liable to lead to me wandering all over the place. That could just be me of course.

OK, back to Cucumber. Cucumber is not in fact a TDD tool or framework. But it’s related. It’s a BDD (behavior driven design) framework. This is a step forward in the evolution of test first development, and for me brings together a number of interesting threads:

  • user stories

  • specification details, acceptance criteria

  • customer/product owner involvement


There’s a (sometimes unpopular) truism in software development: it doesn’t really matter what the requirements say, the software does what it does. The truth is in the source code. That is the only artifact that is up to date and can unambiguously (hard to read code aside) tell you what the software does.

Now what’s really cool here as far as I’m concerned is that Cucumber (and other BDD related tools) let you bring the specification in alongside your source code. Not just in a “store the requirements doc in version control” sense, but something much more useful. Your specifications in Cucumber are written as a series of features (think stories) along with some scenarios (think concrete examples of expected behavior) which then get hooked up with some glue code to the actual production code to test that they work. In other words, the plain English requirements are now an executable specification. With the click of a button you can test which of your features are correctly implemented.

This makes a boatload more sense than deriving tests from a requirements document. The tests *are* the requirements document.

This elegant brilliance (yes, I gush) comes at a price however.

Firstly, your feature requirements have to be written in a particular format. This doesn’t actually seem to be too onerous, and results in some pretty readable material. Here’s an example feature for a system designed to act as a database of hiking trails:


Feature: Search for trails
As a hiker
I want to find nearby trails
So I can go for a hike

Scenario: Search for trails nearby
Given my location is "Rollinsville"
And I'm willing to travel up to "10" miles
When I search for nearby trails
Then "Crater Lakes" is listed in the results



The key part here is the “given, when, then” section. This is what we will end up tying to an automated test. Above it, as you can see, is our user story in conventional format providing background and context.

You can imagine that we might have additional scenarios here related to finding trails that allow dogs, disallow mountain bikers and ATVs etc.

Despite the constraint of the specific structuring required here (and there is more richness available than this simple example) it seems to me that you could get a long way with this approach, and it’s not beyond the realms of possibility for these features to be directly authored by the Product Owner or business analyst.

The second portion of the “cost” of this approach is implementing the code to tie these scenarios to the system to test it. This is where regular expressions (regex) and my weakness with them come in to play.

If you’re not familiar with regular expressions, they basically provide a very succinct means of performing pattern matching operations on strings. See http://en.wikipedia.org/wiki/Regular_expression for more information.

To connect the scenarios up involves writing regular expressions that match the text in the “given, when, then” stanzas and pulls out the key inputs to the tests. In the example above this would be the location (Rollinsville) the distance the hiker is prepared to travel to a trailhead (10 miles) and the success criteria (Crater Lakes).

Those regular expressions, which are wrapped up in C# Cucumber attributes on methods to identify the given/when/then processing look like this:


[Given("^my location is \"(.*)\"$")]

[Given("^.*travel.*\"([0-9]*)\".*$")]

[When("^I search for.*$")]

[Then("\"(.*)\" is listed in the results")]



All of which may or may not read easily for you, depending upon your experience with regex. Mine amounts to little more than a fairly limited quantity. I’m pretty excited about the possibility of executable specifications, BDD and testing applications this way and plan on trying it out in anger over the coming months.

And this is why it suddenly matters that I suck at regular expressions.