Technology Puneri Style

I had read about the behaviour driven development (BDD) quite some time back. However it was more in conceptual stage at that time. So I was looking forward to some new and actionable information to act on it.

For those who are new to BDD here are few links to get up to speed.

1. BDD Wiki Page
2. BehaviourDriven.Org home page
3. Dan North’s article on introduction to BDD

What caused me write this post was one of the recent tweets by the @ScottGu pointing to an article by Rajesh Pillai (BDD using SpecFlow on ASP.NET MVC Application) and also while searching for similar stuff, I found another article with same title but little more theorotical content by Steve Sanderson (Behavior Driven Development (BDD) with SpecFlow and ASP.NET MVC).

SpecFlow & Gherkin

I tried SpecFlow first. SpecFlow is based on a language for BDD called Gherkin. Gherkin is primarily used by BDD framework for Ruby called Cucumber. (Oh and we all swear Microsoft for their product names!) To make the matters simple, here is all this in short. Gherkin is primarily a syntax/style used for writing business scenario. It has few keywords/ concepts like Feature that has Scenario that has three sections called “Given”, “When” and “Then”. Each feature has multiple scenarios and each scenario is described using the three sections. Multiple conditions in these sections are combined with And. All the lines start with either of these keywords. Phew!

So the way SpecFlow works is that is helps convert the features into nUnit Test stubs. You can add meat to each test using your own code and you can drive your development using these tests. So it is BDD by TDD principles. Steve Sanderson’s article gives a good dope on difference between BDD & TDD. While reading his article I got link to another similar framework called StoryQ.

StoryQ

StoryQ uses the features of extension classes in .Net and makes writing the tests even simple. It does not use Gherkin. But the feature syntax is pretty much similar to Gherkin and I have requested them to be Gherkin compliant as well. Hope they will listen. StoryQ works with both MSTest and nUnit. They have a client tool to convert the story from single a test method stub to the entire class.

Comparing StoryQ and SpecFlow

StoryQ: Pros – No frills approach, Excellent Converter, Highly readable Code, Compatible with both nUnit & MS Test. Cons – Lack of integration of feature files within projects. Unknown – How to keep the changes in stories in sync with the tests and vice a versa.

SpecFlow: Pros – direct integration of feature files in both VS 2010 & 2008. Uses Gherkin which can ensure that the feature specs will work on other platforms if needed. Cons – Complex flow for generating method stubs (Run nUnit, Get the stubs from text output window one method at a time and copy paste it into VS – yuk!) No support for MS Test (coming soon as per team).

Summary

BDD is a much cleaner and easier to understand approach compared to TDD. As a developer I never was comfortable with TDD. BDD gives a fresh paradigm to look at basically same process but has more clear line of sight for what you are trying to achieve. Out of the tools, I like StoryQ better. Their codeplex site says that the syntax is completely customizable to any DSL that you want. It needs some work though. But both tools have to be given some time to mature and feedback from enthusiasts will help both of them grow in their own space.

When we start working at a project we are very focused on the process that we follow. For most of IT projects following waterfall model, phases of the project are quite the same. Requirements, Design, Development, System Testing, Acceptance. Even in large projects, we have a time sequence in forms of iterations, phases and within each phase we follow similar patterns.

Estimations are done before hand based on the high level requirements. Which get refined after the details of requirements in first phase are done. But rarely adjusted for actual work. Glen Alleman writes about confusion between effort and results. This is a good article which explains how to move the focus from effort to actual delivery of the project. What he suggests is to create the WBS based on completing a requirement rather than for a phase of the project. One of the advantage of this is that you can actually get a pretty good view of how much work you have really completed. This also helps you work out the dependencies between various features.

My experience with project management suggests use of UML for requirements management. I used Enterprise Architect UML modeling tool for the same some time back. One of the great use of this tool is to be able to model the requirements and be able to map them with actual code components. This gives us a clear traceability between various components and requirements. So when a change in system is required it is much easier to find the impacted areas.

However, I do not agree with some of the exclusion Glen speaks about. Some WBS activities are required to ensure that the product is delivered and the people issues are also well taken care of. We do need to have a holistic view of the product in the early work. We can not break the WBS in set of features before we have addressed some key architectural issues. Also the tooling required for the project is indicated by the design. If the tool has a wider effect on the project, it needs to be considered in the WBS. But apart from these all other points are very valuable for delivering the product.

Sometime back, I was a technical guy. Exploring design, architecture, getting hands on experience on new technologies. Today I am a pure Project Manager. For long time I have been in two minds. Whether I should move to project management or not. I always felt that management is not my piece of cake and I am more a techie than a manager.
Some of the questions I wanted to find answers were:
1. Project Management is all about people and technology is all about code, design and so on. Will I have to leave all the technical matters and manage only people, resources?
2. Overall impression is managers do not understand technology. Will I ever become like them? If it happens it is like seeing death of my own self. Will I be comfortable in this new borrowed skin?
3. Any management job is more generic and has longer usability. Specially in India, where all the technical profiles are dominated by young generation, will these people be willing to work with me when I turn 50? Or will they be more comfortable if I am their project manager?
4. In this world everything revolves around money and there is more money in management than technology. If I have to get a technical job at the age of 50 will it pay me the same money when there is a young engineer willing to take up the work at may be 50% of the cost?
5. Does gray hair really matter in technology? Can a younger person be a full replacement for an experienced developer/designer/architect?
6. Will project management be as interesting as development? What keeps the managers going? Where does the job satisfaction in management come from?

As I move on this track I will be exploring to get answers to these questions. If you have any please post comments on this blog.