Questions and answers at Liip

The other day, I gave a talk at Liip, a cool company doing web agile development. The talk was about humane assessment. It was brief, and was focused on the method and its place in software development. After the talk, we had a heated discussion. They raised some interesting issues.

Issue: You seem to be saying that developers do not do assessment and that they do not build tools. This is not true. For example, I do build tools.

Developers do spend a lot of energy on assessment, only in most cases they do not do it explicitly. It can very well be that some developers do build tools, but this is not the norm and it is not often not done consistently.

Issue: You talk about multiple things at once. On the one hand, you show us analyses that are relevant for developers. On the other hand, you show us tools that we can click on to communicate with management.

Indeed, these are different scenarios. But, they are both served by the same underlying set of skills and tools. Actually, this is what makes assessment a valuable investment. Once you master it, you can leverage it in several ways.

Issue: You seem to have two crusades: on the one hand, you want developers to start building analysis tools, and on the other hand, you promote Moose. Which one is more important?

It's the method, not the tool that is the most important. Moose is around for people to see what can be done. You can see it as a teaching vehicle. Of course, I am confident that once people play with Moose, they are likely to stick with it a little longer. But, that is secondary. The key is to get engineers to understand the role of assessment and the opportunities it opens.

Issue: Moose is around since 1996. How come that it is more successful?

First, Moose was built in research labs and its main goal was to support top research in software and data analysis. And in this area, it is highly successful, being one of the long living platform that produced some more than 200 scientific publications.

Second, we started to look seriously into getting Moose in industry since about 1.5 years. This is about the time I created humane assessment.

Third, value is never the only driver for success. Marketing is important, too. We know our solution is both different from what is on the market and more valuable. But, if you are still skeptical, it means that we still have to learn :)

Issue: We do believe that it is worth investing in tools, but why should we use Moose?

Moose is a teaching vehicle to show you how assessment can be different than what you might be used to. With it you can experience how it is to have a rich object model representing your system, how it is to accommodate new data, or how it is to program visual interactive tools in a matter of minutes. If you combine this with the ability of answering daily questions about the system, you might start to like it.

Issue: Why should I use Moose? Grep works just fine.

Grep is indeed a nice and versatile tool. The advantage is that it can accommodate any piece of text. The disadvantage is that accommodate only a piece of text. When you want to build slightly more elaborate reasonings, you benefit from smarter models and query possibilities.

Issue: On the one hand, these tools get developers more productive. On the other hand, they will also get them lazier and less concerned with keeping the system under a manageable order.

I must admit that I did not understand the question at first. Developers will not get sloppier. Instead, they will become more free to care about high level things without worrying that much about tedious details. The problem is the amount of details. There are literally millions of them even in a medium size system, and we can manipulate consistently at any point only a handful of them. From this point of view, the ability to choose the focus freely is important.

Furthermore, the act of thinking about what the rule should be is what gets you to think about the inner structure of the system. This very act makes things explicit in our heads and because of this everything becomes easier: communication, documentation, and debugging our assumptions. In the end, it leads to simplicity.