I just got back from RubyConf a few days ago. I was really excited by David Chelimsky's and Dave Astels' talk, 'Behaviour Driven Development with RSpec'. The plain text story runner is a great addition and will be available in the next release which is coming out soon.

In a nutshell, it allows you to create plain-text, executable stories such as:

Story: Daily hour calculation

As a user
I want to be able to enter my time in and time out into my time sheet
So that I can track my hours

Scenario: calculate whole hours
Given a time in of 2007-07-09 19:00
And a time out of 2007-07-09 21:00

Then the hours should be 2

Scenario: 0 minutes is 0 hours
Given a time in of 2007-07-09 19:00
And a time out of 2007-07-09 19:00

Then the hours should be 0

The results of running this story looks like this:

denethor:stories $ruby day.rb
Running 2 scenarios:
Story: Daily hour calculation
As a user
I want to be able to enter my time in and time out into my time sheet
So that I can track my hours


Scenario: calculate whole hours

Given a time in of 2007-07-09 19:00
And a time out of 2007-07-09 21:00

Then the hours should be 2
.
Scenario: 0 minutes is 0 hours

Given a time in of 2007-07-09 19:00
And a time out of 2007-07-09 19:00

Then the hours should be 0
.


2 scenarios: 2 succeeded, 0 failed, 0 pending

A really neat thing is that the output can be saved to a file and executed.

David and Dave presented some really neat ideas around the story runner. One particularly interesting one was the potential of e-mailing to a remote story runner and getting the results e-mailed back. Lots of interesting possibilities lie here.

To get more details, check out David Chelimsky's blog.
Note that at some point the RubyConf talks will be made available online, although I am not sure when and where.

I recommend pulling the latest code from trunk (svn checkout http://rspec.rubyforge.org/svn/) and giving it a spin.

Set-Based Design and Effective Risk Management

Set-based design is an empirical approach where a problem space is explored simultaneously through the investigation of various solutions so that the most optimal solution can be chosen at the last moment that the decision needs to be made.

There are a few benefits to this:

1. The longer that you can put off make a decision, the more informed the decision will be. Of course, you cannot procrastinate. It is important to first decide when you must absolutely make the decision.
2. You generate a better understanding of the problem space by tackling it from different angles.
3. By investigating multiple solutions to a problem in parallel, you are more likely to have something functional and ready to deliver in the end. This is effective risk management.

When is it appropriate to exercise set-based design? When you have an irreversible decision to make or when you are facing a deadline which cannot be missed.

Some may consider this as a wasteful practice. Why invest so many resources in solving a particularly problem. However, in most cases the cost of missing a deadline or making an ill-informed decision is significantly higher. Even then, this may be difficult for some people to grasp when they are deep into the task at hand. When this happens, step back and consider the long term goals of the company and the product being development. I bet you will find the investment will be worth it.

You may come across customers who are hesitant to compromise on scope even when a deadline is set in stone and it is pretty clear to you that the current scope is not achievable by that deadline. Instead of running for the hills as some have suggested, consider set-based design. More often than not, the budget is there for it since the organization is more than willing to bring in as many people as it takes to get the job done. It could just be what is needed to get the customer to identify what feature-set is absolutely required to get the product to market.

To learn more about set-based design, have a look at the following resources:

• Bill Wake's Xploration on Set-Based Concurrent Engineering.
• Implementing Lean Software Development, From Concept To Cash by Mary and Tom Poppendieck.

Mylar...Why should you get it?

The Mylar plug-in allows you to associate a context of work with a particular eclipse task. What does this mean? Well, after 'activating' a task for the first time, you are provided with a clean slate view in terms of classes, configuration files, etc... in your project. As you begin to navigate the code-base while working the task, the classes and methods you interact with become part of the task's context. The benefit of this is that it reduces 'conceptual overload', therefore, making you more productive. The best way to understand this is to see it in action. On top of that, this 'external navigational memory' is constantly changing based on your code interactions. The context adapts to your current code usage pattern as you are working the task.

The task context can even be shared between developers on the team and associated with various issue tracking solutions (Bugzilla, Trac, Jira). I have yet to try this since my current project does not use the supported issue tracking implementations, but it seems very cool.

I have to admit it, I have been putting off installing this plug-in for some time and I regret that. I think it is one of those things that you need to experience to fully appreciate. If you do any development with Eclipse, get Mylar now!

I just wanted to let folks now that I will be blogging all future XNA-related content to my new blog XNA Zen Garden. Pop on over and you'll find it's inaugural post on C# partial classes.


I moved my previous XNA-related posts to the new blog as well.

But it works...Isn't that good enough?

Well, it depends. However, more often than not the answer is no, it is not good enough.

Imagine your working on implementing a 'fix' for a 'show stopper' issue under an 'aggressive' dead line. I bet this does not sound too far fetched?

I would bet that you are not particularly comfortable cranking out a quick work around solution, yet I am sure that you find the quick fix so damn tempting.

Why is that? For one thing, the client probably wants this issue fixed yesterday! Deep down, they may not care how it is done. The bottom line is the sooner the better. Of course, doing it right is implicitly assumed but, this is usually sacrificed in the spirit of the Now. In fact, we are often rewarded for getting things out fast. Perhaps there are financial incentives for getting things done on schedule? In my opinion any sort of incentive tied to a schedule is a smell indicating that the schedule is just not right.

My colleague Dmitri Dolguikh recently pointed me to a great article concerning how costly quick fixes can be. I found the last two paragraphs particularly interesting:

It comes down to a matter of professional ethics. Software developers are often disparaged for being sloppy, slow, and unreliable. Whole IT departments and product develoment teams carry the weight of appearing incompetent and moribund. Why? Because they succumbed to the seductive idea that quick and dirty solutions are faster in the short term.

True professionals don't work that way. True professionals keep their code clean at all times. True professionals write unit tests that cover close to 100% of their code. True professionals know their code works, and know it can be maintained. True professionals are quick and clean.

I whole-heartedly agree with this, however, the reality is that being a true professional is not easy and, depending on the environment, may not be realistic 100% of the time. There are too many opportunities lying in wait to distract us from this ideal. In my view, a true professional is analogous to the notion of a responsible developer. To quote a recent post by Kent Beck on the XP mailing list:

I try to do an excellent technical job but I also work to make sure that what I am doing fits into the larger business...If the technical concerns and the business concerns appear to conflict, I work to find a mutually beneficial solution but finally I follow business imperatives over technical ones.

We work within the constraints of our current environment. Although the true professional definition as put forth by Bob should be an ideal that we continuously strive for, it may not always be achievable. In those cases, does that make you less responsible or professional? I don't think so.

We cannot solve all the problems of an organization, but we can do our best to help steer them in the right direction. Sometimes this requires a compromise.

Rules of Engagement

Effective communication is not spontaneous in nature, it takes commitment from all contributors.

So, you have set aside time for reflection. Now what? How do you proceed? To a degree this depends on the situation, however there are some general principles that can prove beneficial. The key is to explicitly establish rules of engagement that maintain trust across all contributors so that they can add effectively to the pool of shared meaning while maintaining focus on the overall goal in order to generate actionable results.

Goal

Before beginning any dialogue, it is important that a goal is put forth that is accepted by all contributors. This formally establishes the problem space that people will be thinking within. It also helps the group maintain focus.

For example, If one of your teams main problems is quality, start the discussion by stating that the purpose of the dialogue is to discuss the quality issue and how quality can be improved. In this particular case, blame has no place in the discussion and this should be made explicitly clear when the goal is communicated.

Safety and the Pool of Shared Meaning

During the discussion it is critical to maintain safety within the group. If people do not feel safe, they will not contribute effectively to the conversation which means the pool of shared meaning will not be as full as it could be. There are a couple of implications of this. Firstly, detail is lost because the entire group is not sharing their opinions. Secondly, and more importantly, Those who do not contribute because of safety issues are less likely to be bought in to any decisions that come out of the discussion. This could lead to the second-guessing of decisions and become an obstacle to improvement.

When is safety likely to be an issue? Any dialogue that can be classified as a crucial conversation where stakes are high, there is a difference of opinion and emotions are involved. The safety issue can be further exacerbated when one of the contributors has a strong, aggressive personality.

Actionable Results

Finally, we want to come out of the discussion with actionable items. If not, any feedback that led to the discussion is not feedback but noise. This is a critical concept that has been stated before:

Feedback without action = noise.

In the end, if the purpose of the discussion is to institute change that will hopefully lead to improvements, then action must be taken. Talking about it is only half the work.

In Conclusion

As I stated at the beginning of this post, effective communication is hard and takes work. I have been reminded of this many times over throughout my career and I have found these principles to be effective. In a future post, I will bring up some of the practices that can be used to support these principles.

If you are interested in becoming a more effective communicator, I highly recommend the book Crucial Conversations. I have found it to be an invaluable resource and it was a major influence of this post.