Michael Dowling's Whispers

I’m going to share with all of you an interesting timeline related to the Gulf Oil Spill.

4/12: Halliburton buys an Oil Cleanup company Boots and Coots (http://bit.ly/dmYXVE)

4/19: Halliburton performs repairs on oil rig (http://yhoo.it/cLih3W)

4/20 (AM): BP warned to slow down operations, management orders otherwise (http://bit.ly/aZ0UJc)

4/20: Oil rig explodes, gushing gallons and gallons of crude oil into Gulf

TODAY: Guess who’s available to clean it up? Halliburton via Boots and Coots (http://bit.ly/a6qkML)

This blog post was inspired by Christopher McKay, who did most of the research online and put together the timeline. I feel the need to pass it on. Please do the same.

Boy, have I been busy the past couple months! And now, I’m comfortable enough to announce what I’ve been working on – my first major open-source project:

Spectacular: An Acceptance Test Driven Development tool for teams who like and/or must write official specs and who do not want to be constrained to a single ATDD tool.

Spectacular is an Acceptance Test Driven Development (ATDD) / Behavior Driven Development (BDD) tool that aggregates several different types of testing frameworks into 1, and it also introduces the idea of Executable Use Cases (EUC) – if you have to write use cases, you might as well make them Not Suck.

The idea is that a Business Analyst (BA), Quality Assurance engineer (QA), or Developer can write a spec in any way they feel comfortable with, including diagrams and business rules if necessary. They can write tests in the form of Executable Use Cases, BDD-style tests (Gherkin/Given-When-Then scenarios), and/or FIT-style tests all within the same document. The tool will run through the document, “detect” test cases, execute them, and print out the results in the same format as it was input.

Why build Spectacular?

I work at a large financial services company, where compliance with Sarbanes-Oxley (SOX) and Office of the Comptroller of the Currency (OCC) rules and regulations is of utmost importance, specifically with the audit requirements.

I suspect that there are many, many organizations out there who have to comply with the same set of rules, so I took what I learned about SOX and OCC audit requirements, combined them with what I learned at Elisabeth Hendrickson’s AMAZING ATDD course, and created Spectacular to make writing requirements more natural while also making those same documents executable, and not restricting any team to any single tool.

Also, I found through practical application of various ATDD tools that they are all pretty amazing and useful, but it was really annoying to use all these various tools to write specs and tests in different ways located in different locations depending on the tool being used. Plus, I would suspect that most teams would prefer to write story tests in a single document in a single format rather than having them live all over the place.

Isn’t this whole idea… un-Agile?

I don’t think so. Actually, I think something like Spectacular will help any large organization with an established corporate hierarchy and previous experience writing specifications in a use-case format adopt Agile more easily, especially those with “hardened” quality-assurance/quality-control groups. In my experience, these large organizations can be like “steering the Titanic with a small rudder” when it comes to transitioning to a more Agile process – allowing teams to continue writing requirements in the form of Use Case flows and documenting the tests in the same document will let them experiment with the various ATDD best-practices while remaining compliant with their regulatory bodies.

Spectacular helps those teams constrained with writing full-specs by allowing those teams to write the specs with tests embedded in them. Agility is introduced because those specs – written in a format they are used to – are now executable. A core Agile practice IMHO.

Use Cases? Really?

Yes, really. Use cases can tell a lot of the “story” if written well. Use cases, just like implementation code when written after a unit test is written, can be written well if there a constraint of execution behind it. Also, traditionally use cases have been taken to a far extreme of complicated. Not necessary IMHO.

To me, Use Cases fill the role of “Epic Spec” in an agile process. I’m a huge believer in the practice of Story Mapping and Persona Development (from Jeff Patton and Dave Hussman, respectively. Two of my personal geek-heroes). While doing your story mapping workshop, the high-level “activities” that you decompose into stories can very easily be Use Cases. In fact, in my experience writing Use Cases to explain the high-level activity (or “Epic”) can help to decompose it into discreet stories. And as such, each level of requirement-granularity (from Epic/Use Case to the Story) requires a different way to test it.

As such, I use Spectacular myself to execute Use Cases against Epics, and BDD/Gherkin and FIT tests to execute Stories.

Enough already. I get it. Show me how it works…

I don’t know about the rest of you, but I hate it when I stumble upon a useful open-source tool only to find that the documentation is poorly written. Now, I’m not saying Spectacular’s docs are amazing, but I did spend some time writing a good amount to make sure people could pick up Spectacular and use it relatively quickly. All of the docs are located at the Spectacular Wiki on Google Code. I welcome all feedback so that the documentation can be improved!

But here’s an example. Given a document:

Activity: Registration

(Executable Use Case)

Business Rules:

• Username must not exist in system already
• Email must not exist in system already
• User must be 18 years or older
• User must supply a username, email address (well formed), birth date, password.
• User must confirm password before proceeding

Story: As a new user not already registered I want to register myself so that I can use the system.

(BDD/Gherkin Executable Test)

Story: As a new user not already registered I should not be able to skip any data elements so that…

(FIT executable test)

With these requirements written, Spectacular will run through this document and parse out the tests (basically, anything contained in a table and fitting particular patterns) and execute test fixtures for each of these. While for version 1.0 Spectacular only supports Java (using JBehave) for the BDD/Gherkin and FIT tests, Executable Use Case fixtures can be written in Java, Groovy, Ruby (experimental – using JRuby), and Selenese (to directly drive a browser using SeleniumRC). The ability to write fixtures for BDD/Gherkin and FIT in other languages is coming soon! (I’d really like to be able to write BDD/Gherkin tests using Cucumber as the engine if possible)

• How to write a fixture for Executable Use Cases
• How to write a BDD/Gherkin fixture
• How to write a FIT fixture

In Conclusion…

Try it out! I hope the Agile community finds some use out of this tool like I have. If you have any questions, you can leave them here in comments or join the users & dev lists.

Attribution

Much of Spectacular is based in part or whole from the following projects:

• JBehave
• FIT
• Cucumber

As well as from the teaching/writing/works from the following people:

• Alistair Cockburn (Use Case guru)
• Aslak Hellesoy (original author of Cucumber)
• Elisabeth Hendrickson (amazing ATDD instructor and mentor)
• Dan North (the BDD guy at ThoughtWorks)
• Liz Keogh (the JBehave gal at ThoughtWorks)
• Dave Hussman (agile Persona development)
• Jeff Patton (Story Mapping)

Read on Bob Lee’s blog about a new collaborative effort to “standardize” dependency injection via annotations:

@javax.inject.Inject at Google Code

Neat!  I’m very happy to see this came about as a collaboration between the 2 competitors.  I use that word a bit loosely here of course, as I switch between using Spring and Guice depending on the project and its needs, and (to me) they serve different types of applications.

Congrats guys!

From MacRumors:  Apple’s Cash Hoard Triggers Acqusition Rumors

So, this scares me just a little bit.  It was not that long ago when Apple was bleeding – nay, hemmoraging – money from every pore.  It had piled up wads of money in previous years which pretty much kept it alive  long enough to buy back Steve Jobs and rescue the company from its failed product strategy.

I’m hoping the rumors are just that – rumors.  IMHO Apple, while making amazing products and therefore making amazing money right now, could just as easily fall out of favor with finicky consumers and find itself in an all-t00-familiar position all over again.  It will need that hoard of cash to reformulate and adapt, just like it did before.

I’m all for dividend distribution in general as well, but not for companies like Apple.  Or Microsoft, for that matter.  These companies are not in a business that is constant or stable – technology is still ever-adapting and ever-competitive, and realignments are common.  That takes cash.

Besides, WTF would Apple do with Twitter anyway?  Honestly, I’m still at a loss for what Twitter is exactly for, anyway.  Marketers tell me it’s an amazing channel, but people don’t go to Twitter so they can be marketed to, they go there to communicate.  Just like on Facebook.  Just like they did on MySpace.  MySpace fell out of favor, as will Facebook, and will Twitter.  I would say Twitter is well on its way, now that “tweeting” is a mass-market phenomenon and no longer a tool of the hipsters only.  That’s usually when these things start to become boring.

Electronic Arts?  That kinda makes sense.  MacOS has always had a big gap in its games category.  Most popular games are developed for the Windows platform (though recently EA has committed to developing for the Mac, and of course World of Warcraft (Warcrack?) is on the Mac, thankfully).  But I think that gap can be filled without spending the savings account.

My $0.02 on the matter, FWIW.

From InfoQ:  Scrum Alliance Asks User Group to Sign Licensing Agreement

Yikes.  Upon first reading the headline of this article all I could think was “oh crap, this marks the beginning of the end for Scrum.“  At this point, the Lean zealots are throwing their hands in the air exclaiming “I told you so!“  Ha, perhaps.

What I like about Scrum is the overall process components it gives us.  It tells us to use a backlog, but it doesn’t tell us what those backlog items must be.  It is common to use User Stories as backlog items, but I’ve worked with teams who use bug reports as backlog items.  Scrum gives us the concept of the “Planning Meeting” where we estimate the backlog items and commit to work during the Sprint, but there is no defined agenda for the meeting.  It is common to use XP’s model for planning (“The Planning Game“), among others.  Same with the demo, the retrospective, and the sprint itself.  Heck, even the sprint length is negotiable!

The point is, we get carried away with the notion of “pure Scrum.”  I find the whole certification practice around Scrum to be completely ridiculous, as groups rarely implement “pure Scrum” because it doesn’t exist.  The components within Scrum tend to be customized by the team, especially during the retrospective.  And it is even more common to use Lean techniques for doing so (which is why I find the fight between Alan Shalloway and his group of Lean folks and Ken Schwaber and his Scrum folks to be equally stupid as Agile certification programs), making Lean and Scrum obvious cooperative processes.

Also, need I remind the Scrum folks that the word originates from a Rugby move?

I will still practice Scrum for the foreseeable future, as I’ve seen so many amazing improvements to teams that I have implemented Agile with.  In each of these teams I hold the expectation that the basic process of Scrum will be modified to fit the needs of the team, which is exactly what I tell them. Besides, some of the most common question I get when I coach teams in Agile is “what about testing?”  “What about development?”  Again, other Agile practices being brought into the Scrum team negate the whole idea of “pure Scrum” and therefore no one organization can own the process.

I’d like to see them try.

I’ve always been a huge believer in using Code Coverage tools (such as Clover, CodeCover, EMMA, gcov, etc) as a way to report on how in-depth your unit tests are.  Generally, I use them with Quality Assurance/Quality Control groups to determine where to focus any additional testing efforts during a Sprint.  While we tend to benchmark required coverage at 85%, this is always a general rule with the understanding that every project (and, therefore, every project’s code) is going to be different, with different needs.

An interesting post at InfoQ talks a bit about the need to be careful about using a required coverage metric during TDD:

Out of the gates, Gruber’s primary statement is that TDD proponents do not suggest code coverage as “a one true metric”, that it is useful but only to degree and taken in context with other sources of feedback. He denounces Pang’s claim that “(Pang) 100% code coverage has long been the ultimate goal of testing fanatics”, stating that “(Gruber) high code coverage is a desired attribute of a well tested system, but the goal is to have a fully and sufficiently tested system”.

I completely agree with this statement.  Code coverage is, again, a tool for determining where additional testing time can be spent, as well as identifying any risks of releasing code into production that is not currently covered by unit tests.

The following quote sums it up nicely:

code coverage [in the context of TDD] is a great way to notice that you screwed up and missed something, but nothing else

More information can be found on InfoQ’s post.