Urs started with the idea and the category “why I like”… So I’ll steal his idea and go further with this category… This might be an expensive blog post because I need to pay license fees to Urs 😉
We adopted machine.specifications for our project approximately one year ago. We compared several context and specification frameworks but the overhead of the competitors was too high for our team. Also didn’t we have a product owner who was willing to write for example Gherkin language. So we decided to go with the developer centric machine specification from Alexander Gross.
We are heavily driving our software with the test driven approach. Currently we are writing the specifications after all components have been developed with TDD. My goal is to bring the team to the point where we truly write the specifications BEFORE the components and units. But this is still a long journey to go.
MSpec gives us the following advantages: The team and product owner has an executable specification which defines and describes the current state and behavior of the system regarding business workflows and boundary interaction (third party services, hardware integration etc.). The team gains trust in the system and has no fear of re-architecturing large part of the core infrastructure when necessary because we always have the safety net of the executable specifications. The specifications allow new project members to deep dive into the system from a high level perspective. Writing new specifications allows us the focus on the “bounded context” of the system.
Writing specifications is not an easy task. You need to design your software so that it is possible to pick certain aspects of the system and run it in a predictable and fast way. This is a huge challenge for the software architect/s of the system but also for the developers writing the specifications. Where do I cut the dependencies? What can be left out? What must be left out? How do I setup the system into the right state? How do I assert the state of the system at the right time? BUT it is certainly worth it because we gain deeper understanding and more trust in the system!
Hi Dani
According to Uncle Bob (Clean Coder), he prefers using Fitnesse and let the Product Owner write the acceptance tests in Fitnesse during the sprint; depending on the skills of the Product Owner, the developer will help him writing the acceptance tests.
Did you try this approach with Fitnesse?
I prefer MSpec over Fitnesse because it allows a very efficient ATDD cycle. We work acceptamce test first, and with MSpec I can run the acceptance tests within visual studio over and over again and very quickly (ReSharper + MSpec plugin). They provide better refactoring possibilities too because it’s all just dead simple code.
The drawback is that the test are developer centric. Other tools like Fitness or SpecFlow are more on the business side. It depends on the project setup and involved persons, which approach is more beneficial.
Nonethless, I made very good experiences with the report from MSpec. I take it into meetings with my product owner and other stakeholders and use it as a basis for discussions. Remember that Agilebis about communication and not perfect self explaining documents. Thevsame holds for specs as for requirements.
Probably I should write all this in my own ‘Why I like MSpec’ post 🙂
@Urs Enzler
Hi Urs
Not only in the agile world is communication key; nevertheless the drawback of natural language is, that it is not unambiguous, whereas the Fitnesse/MSpec specification is. I understand, that you as a developer like to write all of your code in one tool, but I would rather like to see the product owner write the acceptance tests. Of course it always depends on the project and I was eager to hear whether your team did use Fitnesse or another tool outside MSpec.
Maybe in a future article?