A new version of the booklet describing humane assessment is now available for download.
The new version features more details and pictures related to the Moose analysis platform, and it shows a diagrammatic representation of the assessment process:
Meeting real deadlines is a hard and stressful job. It’s a job that typically eats all resources available, because when we know exactly what the best way is, we want to go full steam ahead. After all, we want to utilize our full productivity. Except that we typically do not know the best way. We know a way and we get comfortable with it.
While the status quo can be comfortable, it is certainly not perfect. There always is something to improve. However, when entrenched in a routine we typically have no clue of what that something is and how to improve it.
How can we rethink the situation? How can we find that something?
As you might know, I spent some time in research. Research is a fascinating environment because it challenges you to challenge the status quo. If you do not do it, someone else will.
During this experience, I noticed a handful of techniques that do not depend on the topic:
Why should we care about this? Because it affects everything we do, including the design of our software system, understanding our clients’ requirements, or managing our team. And because the solution is simpler and cheaper than we might think.
I will give a talk about this topic at the SCRUM Breakfast in Bern on June 30, starting with 08:00.
Whether under the name of annotations (in Java) or pragmas (in Smalltalk), developers use them increasingly as a means to encode extra information in the source code.
This information is typically orthogonal to the intention of the annotated code. For example, annotations can be used to identify the attributes that need to be persisted (like we do in Moose, or like Hibernate does to express mappings on tables), or they can be used to denote the methods that should be displayed in the user interface (like we do in Moose).
At first sight, this powerful mechanism comes at zero cost: you get to have more behavior without inferring with the base code. It’s not so, or like the saying goes: “any promise that is too good to be true, it probably is".
Every annotations adds a logical dependency between the places that define it or those that use it. Furthermore, annotations do not come alone. Typically, we get groups of annotations that work together or that offer similar behavior. It is true that the base code does not have anything directly to do with annotations, but the overall
To get an idea of what happens when we introduce annotations, I created a visualization called Annotation Constellation (available in Moose). The labels show annotations, the small squares represent classes, and the lines connect annotations with the classes defining the respective annotations. The spring layout reveals islands of annotations and related classes.
The picture below shows the shape of the default Pharo annotations (version 1.1). We can see that there are a handful of annotations, only few of them being connected.
The most used pragmas are #primitive: and #primitive:module:. Both of these annotate methods. The interesting thing is that in some classes, you get only usages of only one of these two, but there are also classes that use both.
A slightly different situation, can be seen with #version: and #version:imports:. These annotations are consistently used together.
If the base Pharo looks pretty clean, after we load Moose in it the landscape changes dramatically, as can be seen in the picture below (the image is available in larger resolution if you copy it locally). First, there are more annotations. Second, these annotations are grouped in complex clusters showing that they work closely together.
You might think that this situation is specific to Smalltalk. Please take a look at what happens in a JEE system.
The goal of the visualization is to reveal part of the extra complexity introduced by annotations in the system. I say part because there are several things that are not taken into account, like which classes depend on the defined annotations. But even this visualization shows that we cannot afford to ignore annotations if we want to understand a system as a whole.
Assessment is an act of reasoning. It is what we should do before taking a decision. However, when large amounts of data are involved, assessment gets complicated because we are just not equipped to handle many details.
Data is here to stay. Whether in the form of software systems or otherwise, we will only get more, so we better get good at dealing with it. We need tools to deal with the vastness of data, but these tools should bend around humans, rather than requiring humans to conform to them. Moose is such a tool. It offers an extensive, flexible and open-source platform for analyzing data in general and software systems in particular.
Tools are important, but we need to recognize that assessment is a human activity, and that we have to tackle it as such. Analysis tools should merely assist analysts by crunching data only when and how it is required. I call this approach the humane (or agile) assessment.
I recently launched http://humane-assessment.com, a site dedicated to it. Currently, it features only the booklet below. More will come in the near future.
We just released Moose Suite 4.0!
You can download it from: http://moosetechnology.org/download
This is the first fully open source release of Moose: it is based on Pharo 1.0 released under MIT, and all its components are available under a BSD/MIT license. Some of the most significant developments are listed below.
Core developments:
Improved user interface:
Better technical infrastructure:
Improved documentation:
Other applications:
External applications:
The list of 269 issues fixed in this release can be found at: http://code.google.com/p/moose-technology/issues/list?can=1&q=status=Fixed%20milestone=4.0