I am happy to announce that on June 2-3 I will give a public Moose apprentice course. The course is organized at the University of Bern, Schützenmattstrasse 14, Room 107, and it is free of charge.
This is an introductory course on how to use the Moose analysis platform for putting humane assessment into practice. It is dedicated to software engineers, and the concepts covered include model navigation, querying techniques, code metrics, and visualizations. The course sessions are accompanied by hands-on exercises.
If you are interested in registering, please contact me directly.
I while ago I met a company of some dozen developers that were working on a new part of a system. The team was quite motivated, and it included both senior and junior developers.
This new part was implemented in Java EE, and they were working on it for a bit more than half a year. Given that the development was quite at an early stage, the system barely totaled 1500 classes (both client and server side), which for Java is not that much. During an assessment workshop, I gave them the following task: List from on top of your head all the service classes that you provide on the server side. This basically boiled down to enumerating the session beans they had.
To make it easier I also told them that it is not important to get the names precisely correct, and that in fact I will be doing a union of all the item they list. After a couple of minutes, we got to 12 items on our list. And they seemed content. Then I asked Moose to tell us how many classes are isAnnotatedWith: 'Stateless' and the result was 20.
Of course, when they saw the complete list, they did recognize all the other 8 services. And they also found reasons for why they did not list them in the first place: some were not used for most use cases, and some were simply implemented early in development.
These were competent developers that cared about their system. Still they only got 12 out 20. And this was a coarse-grained question about a medium-sized system.
The problem is simply the amount of data. As soon as we are talking about more than a handful of details we should remember, the fancy mechanisms in our brain will kick in and help us focus on what seems more important. Essentially, we scale by not remembering everything.
Why is this an important issue? Well, most modern engineering practices rely on putting the right people in one room and expect them to find the best solution. But, when the facts are not in that room, how are we to expect to get to the best solution?
The size of the systems and data you have to deal with is increasing every day. This changes the game rather profoundly. To keep this game under control, you have to change the way you approach it.
Testing works great, especially when it drives the work of transforming specs into code. But, testing is just about functionality. And functionality is just part of the story that makes a software system.
Let's take an example. Suppose you are writing a system that has a server side based on JBoss. And suppose you want your system to rely on the clustering possibility of JBoss. How would you test that the system works in a cluster as expected? For a complete test, you would need to do something like this:
- setup a cluster with at least two instances of JBoss running,
- create multiple clients and lookup all the session beans that you want tested from the cluster,
- make sure you get a connection to the first node,
- take that one node down, and
- check to see that the requests to the already acquired session beans is not failing.
This test would work nicely for the current set of beans. When a new one is created we would have to extend the test with that particular session bean. However, even if we would develop test-first, we might could easily forget to test the clustering requirement simply because it is not a functional one: from a purely functional point of view, a use case could be satisfied even without the clustering in place.
It is not impossible to setup a test for our problem, but it is expensive from multiple perspectives: it is difficult to setup, it is not straightforward to extend it, it takes long to run the test. But, the worst part is that when the test fails, it will be unclear what exactly went wrong.
What is the alternative? First, let's see what does it take to specify clustering in JBoss. It turns out that all you need to do is to annotate the interesting session bean classes with @Clustered. If you accept that JBoss does work as expected, the only thing you need to test is that you have the right annotations in place. This can be checked structurally. With Moose, the check would look like:
model allClasses select: [ :each |
(each isAnnotatedWith: 'Stateless') and: [
(each isAnnotatedWith: 'Clustered') not ]]Using this rule on a system results in a list with all (stateless in this case) session beans that do not have the required annotation. As long as the list is empty, you are fine. If the result is not empty, you know you have a problem.
The direct cost of building this rule is significantly lower than the one associated with the functional test. But, the best thing is that when the structural rule fails, it provides an immediate pointer to what needs to be fixed.
Testing works great, but only for problems that are best described functionally. For the other problems, you are better served by different analysis tools.
On June 26, I will be giving a talk at SET/Jazoon 2012 (in Zurich) about Why you should care about software assessment.
Here is the abstract:
What is assessment? The process of understanding a given situation to support decision making. During software development, engineers spend as much as 50% of the overall effort on doing precisely that: they try to understand the current status of the system to know what to do next. In other words, assessing the current system accounts for half of the development budget. These are just the direct costs. The indirect costs can be seen in the quality of the decisions made as a result. That is why you should care about it.
What can you do about it?
- Make it explicit. Ignoring it won't make it go away. By acknowledging its existence you have a chance of learning from past experiences and of optimizing your approach.
- Tailor it. Currently, developers try to assess the system by reading the source code. This is highly ineffective and it simply does not scale to the size of the modern systems. You need tools, but not any tools. Your system is special and your most important problems will be special as well. That is why generic tools that produce nice looking reports won't make a difference. You need smart tools that are tailored to your needs.
- Educate it. The ability to assess is a skill. Like any skill, it needs to be educated. Enterprises need to understand that they need to allocate the budget for those custom tools, and engineers need to understand that it is within their reach to build them. It's not rocket science. It just requires a different focus.
All in all, assessment is a discipline. More information about our view on assessment can be found at:
http://humane-assessment.com
The talk is targeted equally to software engineers and managers, and it exemplifies the above points through several case studies.
Moose is a tool. Humane assessment is a method. A smart engineer asked me the following question:
You seem to have two crusades: on the one hand, you want developers to make assessment explicit, and on the other hand, you promote Moose as a tool. Which one is more important for you?
Moose is a novel tool. Its novelty stems from its focus: it's actually not a tool, it's a platform. Instead of providing ready-made generic analyses, it aims to make crafting custom ones cheap. Still, Moose is just a tool. And like any tool, it requires a method to produce actual value.
There are plenty of analysis tools out there, but they all tend to fall short. That is because to drive them, you need knowledge. And, as long as you do not invest in building up this knowledge, nothing major will change. The industry focused on the technological aspect, and forgot about the human aspect of the equation.
Which one is more important? The method.
Ask more questions via @humaneA, @girba, or by email.
