Clean Code, Quality

How do you manage dependencies in your project? Since an image speaks a thousand words, I’ve always been a fan of visual management. Unfortunately, Visual Studio Professional doesn’t provide a way to do this. In the Premium and Enterprise editions you can visualize code dependencies on dependency graphs. But I don’t think this is enough. An architectural diagram with every assembly or namespace in my solution doesn’t tell me that much. It contains too much information.

Fortunately, there is a tool that can help you manage dependencies in the .Net world: NDepend (there is also a Java port – JArchitect). NDepend is a static analysis tool that, among other things, allows you to visualize dependencies. After I first ran NDepend on a project, I was overwhelmed with information. Then I took some time to play around and discover what can it tell me about my solution. NDepend integrates into Visual Studio quite nicely and points you in the right direction through tool tips and links. This is useful for people who prefer learning by doing. Aside from giving you information, it also tells you what to do with that information.

NDepend has two main views for managing dependencies: the Dependency Graph and the Dependency Structure Matrix. Apart from these, there is also an Abstractness vs Instability report that can be helpful. In this blog post, we’ll discuss some of the things that these views can tell you about your solution.

Continue Reading

Quality, Specification by Example

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

Quality

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

Quality

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.

Building the Right Product

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.

Continue Reading