I have been using Specification by Example (a.k.a BDD, ATDD) for the last couple of years. This has helped bridge the gap between technical people and business people. It has also helped ramp up new members on our team, since we have a living documentation of the system. This isn’t always easy and we’re continuously looking for ways of improving the structure of our BDD specification files. There are some questions that help us spot improvement points:
- How easy is to have an overview of what the product does?
- What are the main business areas of the product?
- How easy is to find a specification?
- How easy is to find related specifications?
- How does this feature relate to that feature?
- If you just point a new joiner to the specifications folder, will she have a decent idea of what the system does?
In this blog post I hope to give you a few tips that might help answer some of these questions. These aren’t new ideas, but I find them pretty effective. Continue Reading
In a previous blog post we discussed why building the right product is hard and some tips on how to achieve a high perceived integrity. But if you’re building a strategic solution that should support your business for many years, this is not enough. With time, new requirements get added, features change and team members might leave the project. This, together with hard deadlines, means that technical debt starts to incur, and the price of adding new features increases until someone says it will be easier to rebuild the whole thing from scratch. This isn’t a situation you’d like to be in, so that’s why it is important to build the product right.
Building the product right
In their book, Mary and Tom Poppendieck define this dimension of quality as the conceptual integrity of a product. Conceptual (internal) integrity means that the system’s central concepts work together as a smooth, cohesive whole.
How can you maintain the conceptual integrity of a product during its lifetime? You rely on communication, short feedback loops, transparency and empowered teams. These are the same principles that can lead to a high perceived integrity. The only difference is that you apply them at an architectural and code level. Continue Reading