As I’ve said in a previous post, I don’t like estimating. So I decided to have a look at Vasco Duarte‘s No Estimates book.
While reading this book, I had 4 questions in mind:
So, let’s first have a look at the book and then we’ll see how it helped me answer these questions.
Continue ReadingWhen I started programming, people were talking about Domain-Driven Design. Being a junior, I gave more attention to the tactical patterns. I kind of got the idea behind repositories, entities, value objects, etc.. Six years later and I still see people paying more attention to the tactical patterns. Even Eric Evans says that he has overemphasized the building blocks. So, in order to get a better understanding about what is Domain-Driven Design, I decided to read the book that introduced it. The main purpose was to gain more knowledge about the strategic patterns of DDD.
User Stories are at the heart of agile delivery, yet creating user stories is a hard skill to master. I think everyone working in an agile project has battled with stories either too big or too small, too technical or without business value. Fifty Quick Ideas to Improve your User Stories by Gojko Adzic and David Evans provides solutions to many of these issues. This book helps readers to be more agile, instead of doing agile. It challenges ideas like using numbers for estimations and using velocity for capacity planning or for measuring value.
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.
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
If you ask a hundred developers to define software quality, you’ll probably get a hundred different answers. There are a lot of ways to categorize quality, but one that I find most useful is building the right product and building the product right.
First we have to make sure we are building the right product. The most performant and secure product, having the cleanest and most extensible architecture, covered with unit tests and acceptance tests is in vain if nobody uses it.
In their book, Lean Software Development: An Agile Toolkit, Mary and Tom Poppendieck define this dimension of quality as the perceived integrity of a product. Perceived (external) integrity means the totality of the product achieves a balance of function, usability, reliability, and economy that delights customers.
Traditionally, when customers want to build a product, they talk with business analysts and write down the requirements. These documents are then handed over to architects, who then define the high level architecture and pass the design documents down to programmers who start implementing. There’s a gap between each step and as we go through the process, we lose more and more information and our chances of building the right product get slimmer.