Communicating with Stakeholders - Cucumber and a new Cucumber learning resource

Here at 7digital, we see the relationship between the customer and the developer as one of the most important aspects of software development. We treat software development as more of a craft than an engineering discipline. Craftsmen back in the day would have constant communication with their customers, receiving regular visits from their customer to discuss progress and alterations as the item takes shape.

Over the last twenty years, the agile software movement and extreme programming in particular has championed this with its short iterations, customer showcases and active customer participation in the creation of features.

Processes like Behaviour Driven Development (BDD) have attempted to bridge the gap between craftsman and customer, giving developers processes to guide software development based on the desired behaviour of the system rather than through more traditional software engineering disciplines.

Tools, such as Cucumber, actualise this process. Cucumber (and similar, older tools such as Fit, Fitnesse and Storyteller) provides an interface between the customer and the developer by providing a human readable specification of the software that is also understood by the computer. Based on the description, the computer executes the software accordingly. The customer can then see immediately if the software behaves according to the specification.

Of course, translating human text into instructions for a computer isn’t easy. While modern programming languages on the surface do read like English, and tend to use English words, it takes a certain amount of experience to appreciate what the actual behavior of a piece of software is just by reading the code. The skill in using tools like Cucumber is in translating what the customer understands into something the machine can interpret.

If you’ve been looking for some time for a resource that offers a good grounding in using a tool like Cucumber then you’ll be pleased to hear that one has arrived courtesy of Matt Wynne and his Cucumber School.

The Cucumber School is a series of video tutorials for learning and practising how to do this. Matt Wynne takes you on a journey from the initial planning session with the customer through developing an application (‘Shouty’ - a social networking app). Throughout he highlights potential pitfalls that many teams using this tooling hit the first time they try it out. He does this with wit and aplomb. The videos are lovingly animated and include advice that Matt has built up from his many years of using and contributing to Cucumber. All this advice is condensed into six 20 minute chapters and it is advice that would otherwise take you hours and hours of trawling through blog posts and talks to discover.

Cucumber School covers just about everything you would want to tell developers about BDD in a little over 2 hours. To get a flavour of the style of the course the first video is available for free at the Cucumber School website and in itself demonstrates the power of BDD as a communication tool.

At the heart of successful software development is constant communication between the development team and customers with a business problem to solve. Cucumber provides an effective way of taking these conversations and turning them into a set of automated specifications that describe the software built. Introducing Cucumber to your development process can initially seem daunting so to get you started try The Cucumber School, which will help you to get well on the way to making it a useful and valuable part of your development process.

About the author:

For nearly two decades Leon Hewitt has been creating software to solve people's problems. He has worked at 7digital since 2012. When he's not waxing lyrical about software you can hear him chat about his favourite television programme Doctor Who on the Never Cruel or Cowardly podcast. @DocLeon

Somewhere in the 7digital.com web site infrastructure there are classes that override the default controller and view factories (it is an ASP MVC project). Why did we do this? In our opinion, the default project layout is a hindrance to code readability.

The idea is explained by Uncle Bob in his concept of “screaming architecture”. i.e. if you glance at the program's folder structure, what is the most blatant thing about it, what is it “screaming about”?

If there's a folder full of controllers, and a folder full of views, and another for models, then it's screaming “I am an ASP.Net MVC project! I do ASP MVC things!”. If there's a folder called “Artists” and another called “Genres”, each containing controllers, views and other classes related to that feature, it's instead saying “I am a music catalogue on the web”.

I personally feel that “screaming architecture” is a very poor name for a very good concept. The architecture isn't having a crisis. It's not running around with hair on fire shouting “aaargh!!!”. Maybe Uncle Bob has more positive associations with the word “screaming”? With his meaning of “screaming”, every architecture is screaming about something, but what is the important thing.

Everything we do should be driven by clear business goals and objectives. Where they are lacking we should go and find them.

We expect business needs to be provided as problems that need solving with clear expectations and measurables without prejudice towards the implementation.

Release Early and Often; Fail Early and LOUDLY!

It’s essential we can respond quickly to changing business requirements. The best measure of our effectiveness in doing so is via frequent predictable releases through a steady rhythm of working. Things need to be easy to change (maintainable) and delivered at a sustainable pace.

It’s far more preferable to get something in production as soon as possible and develop iteratively based on feedback than to get bogged down in speculative analysis or a fear of not making all the right decisions up front (be that regarding technology choices or requirements).

Failures are expected, and welcome. When projects fail, we learn about other routes that might work. When software fails, it tells us about invalid assumptions we’ve made. The earlier and louder the failure, the more valuable that information is.

Servicestack is a comprehensive web framework for .NET that allows you to quickly and easily set up a REST web service with very little effort. We already use OpenRasta to achieve this same goal within our stack, so I thought it would be interesting to compare the two and see how quickly I could get something up and running. The thing that most interested me initially about ServiceStack was the fact that it claims out of the box support for Memcached, something we already use extensively to cache DTOs, and Redis, the ubiquitous NoSql namevaluecollection store.

Getting cracking

I set myself the task of creating a basic endpoint for accessing 7digital artist, release and track details. Whilst taking advantage of ServiceStack’s ability to create a listener from a console window so I didn’t have to waste time attempting to set it up via IIS:

Over the last month we've started using ServiceStack for a couple of our api endpoints (go to the full ServiceStack story here) . We're hosting these projects on a Debian Squeeze vm using nginx and Mono. We ran into various problems along the way which we'll explain, but we also managed to achieve some interesting things; here's a summary. Hopefully you'll find this useful.

Nginx

We're using nginx and fastcgi to host the application. This is good from a systems perspective because our applications can run without root privileges. For the communication between mono-fastcgi and nginx, we are using a unix socket file instead of proxying through a local port. This makes configuration much easier, as you map applications to files rather than port numbers, so the convention rules for this are much more straightforward. (Besides, you may be hit by a memory leak if you don't use unix socket files.) Furthermore, using files instead of ports has made our life easier for automated deployments because: