Concerns about NBehave

square_round This is an attempt to answer Scott Bellware’s concerns and questions about NBehave.

Scott, first off thanks for posing the question I really appreciate open honest feedback.

I want to make sure that everyone understands that I don’t treat Agile as a prescriptive process that has to be rigidly followed. The contextual nature of Agile and its supporting practices require that individuals analyze and determine the best tools to use for the job.

“Stories are intentionally malleable. They can be split, joined, negotiated, re-negotiated, and changed. And ultimately, they’re totally disposable. Once they’re done, they can be torn up and thrown away.”

Speaking of my specific context, I work for a financial institution that has heavy Government regulatory oversight concerning software development, in particular requirements traceability.

I agree with Scott that Stories should be malleable and the simplest mechanism should be taken in order to determine business value out of the software you are creating. When I was first introduced to Agile we started off with XP practices during the planning phase and came up with stories on index cards. It wasn’t till our auditing department became more aware of certain regulatory constraints (that I am still contesting to this day) where we had to look at more heavy weight measures of documenting our stories (requirements). As you can imagine this became source of contention amongst the team as some of the BA’s and testers wanted to immediately go back to a heavy weight approach of requirement authoring. My remediation to this was to create the requirements goal form and feature cards seen below. This at least got me away from IEEE 830 style requirements, that we all know do not work!

 

Requirement Goal

Date 01/01/2007
Desired Implementation Date 04/01/2007
Business Analyst Susie Que
Executive Sponsorship Jack Marshal, Regional Director

Goals:

The user would like to log into the ATM by first swiping their personal ATM card issued from the branch office and then key in a 4 digit PIN. When the user creates their pin we have to make certain that their pin does not match the last 4 digits of their SSN that we have in the system. If the PIN does not match then store the PIN in the system and associate it with the ATM card. If it does match then display an error message with the following text “You may not use a PIN that matches the last 4 numbers of your social security number”

 After the user logs into the ATM they should be presented with a home screen that displays a welcome message and their name. The client should then be able to see a menu list with the following options.

Balance Inquiry

Withdrawal

Transfer

Benefit:
By implement ATM machines in our branches our company will be able to offer a competitive advantage over our competitors.

Detriment:

If we fail to implement ATM machines in our branches our company will be forced to stay open till 10 PM increasing resource cost by 35% nationwide.

Feature Card

Card No: 052205

Name: Branch 4 Digit PIN number creation

Summary: The client will create a 4 digit pin number in the branch.

Type: Customer

Requirements Uncertainty (erratic, variable, regular, stable): Regular

Dependencies: None

User Acceptance Tests:

Given that the client is creating a 4 digit PIN number

When the client has keyed in a 4 digit pin that does not match the last 4 digits of their SSN

Then the PIN is stored in the clients account profile.

This is a Positive aspect

Given that the client is creating a 4 digit PIN number

When the client has keyed in a 4 digit pin that does match the last 4 digits of their SSN

Then the client is presented with an error containing the text “You may not use a PIN that matches the last 4 numbers of your social security number”.

This is a Negative aspect

As you can imagine this worked great up until we had a change to the Goal or the Feature. Then the traditionalist threw up the change control flag and I cringed. But let’s talk about why they threw up the flag in the first place.

  • · Is it because the code that was being affected was difficult to change? No
  • · Is it because the testing team had to change their acceptance test that they didn’t have automated at the time and only documented steps within a spread sheet? Yes
  • · Is it because the business had to go back and make sure they properly documented the changes in the feature and in the requirement goal form? Yes

So you see it is not that the development team that was not welcoming the change, in fact it took the development team 10 minutes to make a change, where it took the documentation and testing efforts several hours to make a change on average. The point I am trying to make is that Agile methodologies in general (software practices aside) engage teams to find a way to solve perceived complex issues such as change control and find a simpler solution to enable change.

In the scenario above Automated Acceptance Testing was the logical choice to curve the acceptance testing documentation since now it would be housed in a tool that propagated changes and had auditing features built in. The requirements goal side of the house was, is still a contention point since such a simple form is still not updated. There is talk about more enterprise methods of governing the requirement goals but I am not one to promote enterprise level product suites that cost hundreds of thousands of dollars.

Then one day I came across Dan North’s post on rbehave. What a concept, story authoring at the source code level! This made so much sense to me I quickly found a hackish way to make it work in C#. To my amazement it worked and I started to ponder the benefits within my organization. The key was to make the framework as easy as possible for a product owner to author the story within the source code. Bring the focus and the continuity around the source code as point of reference to the inception of the domain concepts. Utilizing the Visual Studio IDE and ReSharper you could really ask the question to the code, “why is this FeeTemplate object here?” you can than quickly trace back to a story and see why it was created. If a domain object doesn’t trace back to a story, you should question the validity of that domain object.

So it has two benefits Domain Validation and requirements traceability. Not to mention that if a product owner wants to make a change to a story they simply check out the story make the change with the developer and tester on hand, check in the story to the source code repository which prompts the developer and the tester to make the appropriate changes.

NBehave is still in a beta state so I can’t call it a success or a failure yet but I will say that it has tremendous potential for organizations that have instituted Agile but have to deal with more formal regulatory constraints.

Having said that, I would like to point out that all Agile Practioners should take a step back and question the tools they are using? Does NBehave make sense for small or medium size shops where you don’t have to worry about formal processes, probably not. Start with the simplest mechanism, in the case of story authoring that would probably be index cards. If you find that you need more control over your story authoring evolve to the next level of simplicity. If it leads to NBehave great! If it doesn’t even better! The point is remembering the first core value of the Agile Manifesto.

Individuals and interactions over processes and tools

Look to the left before you leap to the right!

And Scott thanks again for making me think if what I was doing is worthwhile.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Joe Ocampo

My personal philosophy is simple: "Have a good strategy that sets the environment for success through the enablement of the whole. Be agile but with a mind towards pragmatism. Delegate to the best qualified individuals, but don’t be afraid to involve yourself in all parts of a job. Treat everyone with respect, humility, and with a genuine pursuit towards excellence." Respected business and technical leader with expertise in directing organization towards effective results driven outcomes. Proven ability to perform and communicate from both technical and business perspectives. Strong technical and business acumen developed through experience, education and training. Provides the ability to utilize technology, harness business intelligence and execute strategically by optimizing systems, tools and process. Passionate about building people, companies and software by containing cost, maximizing operational throughput and capitalize on revenue. Looks to leverage the strengths of individuals and grow the organization to their maximum potential by harnessing the power of their collective whole and deliver results. Co-Founder of LosTechies.com
This entry was posted in BDD (Behavior Driven Development), Domain Driven Design (DDD). Bookmark the permalink. Follow any comments here with the RSS feed for this post.

5 Responses to Concerns about NBehave

  1. Dude, we’ll have to talk about this more in-person when you come up to Austin next.

    You’re trying to force traceability onto processes and artifacts that aren’t intended as traceability mechanisms and possibly damaging them in ways that might remain inaccessible while doing so.

    I’ll eat my hat if there’s someone in your compliance and auditing organization who has specifically told you that you need traceability from user stories to code in the form of the NBehave API and a specific abstraction that represents a User Story.

    I appreciate the research and development aspect of what you’re trying to pull off, but you’re performing surgical experiments on parts of the agile practices organism that should be kept healthy at all costs while you’re depending upon them for the life and health of your project and your team.

    You can find a good place in your architecture (not necessarily the software architecture) to introduce an anti-corruption layer that supports compliance but insulates your programmers from the incursion of its insidious tendrils into code artifacts.

  2. Geovanny Tejeda says:

    Damn, pretty weird that there’s only one comment in this thread…

    I have to say that i felt in love with the concept (BDD), it is true that it has not reached its potential, but i applaud the fact that practices and experiments like these are carried out; how else would you be certain you’re doing the best you can do to the best of your knowledge if these concepts are not constantly contested? and although i understand where Scott is going (and i personally don’t entirely disagree), we (at least i) have to keep trying to find alternatives that at least “make sense” in software development.

    My first personal weeks learning and experimenting with both camps have been intellectually fantastic, there’s a lot of debate and concepts on the table and there’s more to read, but hey, it was not until i tried BDD on a project that i personally realized of TDD’s value for me and my team.

    Thanks to both of you who definitely help the software community by bringing these open discussions to the table.

    I personally hope the BDD initiative is continued and matures… if fibonacci was right, the next iteration should be exponentially better ;)

  3. Joe Ocampo says:

    @Scott

    I am curious on how the traceability mechanisms can be damaging to BDD?

    I don’t know if I captured this in the post but what I am trying to do is capture the contextual inception of the behavior. To me BDD is nothing more than TDD with a contextual nature. Sure the TDD covers the functionality and design but are the behavioral aspects of the domain applicable within the contextual nature of what it was intended to solve?

    Given {some context} this object {should behave} {this way}

    But what gave “this object” that {context} and this is where I feel one of NBehave’s greatest strengths lie. It allows any team member to query the code to determine where the context originated from. There have been plenty of times during the maintenance phase of a project that we enhance a service or entity and can’t remember why it behaves a certain way and should it? We ask the business and they can’t even remember why? Don’t get me wrong the site functions as expected but when you have a solution with over 40 projects and over 6000 unit tests, management of the test takes on a whole new dimension.

    One would argue, does it matter that you can’t remember since your code works and the acceptance test pass? Simply create a new story that changes the behavior and work through the behavioral aspects of the new story. To that statement I would answer, it depends. ;-) To save time in a modeling session we revisit older models to understand the changes to new enhancements. Some features are so huge that they were comprised of 30 stories or more to complete. At times we had to figure out why certain functionality was behaving a certain way and looked to the old story cards to provide us detail on the value aspects of the feature. How often did we do this…maybe once an iteration. Was the return on looking up the old stories that high? Sometimes. Did it help? Yes!

    The side effect to this is that it generates traceability for me! Yes selfish me!! LOL and your right Scott no one specifically told me that I have to map the stories in the source code to do this. For me it just makes sense. The ability to capture the inception of the behavioral context of the domain is huge. So your hat is safe. 

    Having said that, you could just as easily wrap the constructs of the story narratives and behavior within a standard Unit test as most BDD practitioners are doing today.

  4. Joe Ocampo says:

    @Geovanny
    Thanks for the comment. Just like children growing up is hard to do.

    Contestation is a great when it comes to Agile because it causes us to think and make certain what we are doing is sound and valuable. I understand Scott’s concern having been on the evangelistic band wagon for a while it is harder to undo misunderstood concepts than it is to bring forth new ones. TDD has served the Agile community for quiet sometime and has proven to be an invaluable practice. We as a community have to be very cautious that the values of Red, Green, Refactor that lead to a supple design, persist in any new Agile endeavor.

    Courage is one of values of eXtreme Programming and is often executed in a number of ways. But even beyond XP, courage I believe is founding principle of Agile as any practioner can attest too. Stretching the boundaries of software engineering requires great courage but an equaling harmonizing principle is Humility which I value much higher than courage. Learning to balance both is an art form in and of its self.

  5. Colin Jack says:

    I personally think being able to see why the domain models behavior is the way it is could be very useful, even if it isn’t I think the NBehave style of testing is a good way of helping you focus some of your testing effort on the externally visible behavior of the domain.