The new version features more details and pictures related to the Moose analysis platform, and it shows a diagrammatic representation of the assessment process:

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:

• Always question the status quo, even when it appears perfect.
• Never stop researching, even when it is not in the job description.
• Identify the wrong assumptions, especially when they are obvious.
• Demo your ideas, even when they seem hard to implement.
• Listen, even when you do not agree.

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.

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.

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.

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:

• New meta-meta-model: FM3 implemented in Fame
• New FAMIX 3 meta-model defined using Fame
• New query interface for FAMIX
• FAMIX extensions for Java to support annotations and exceptions
• Glamour: new generic engine for scripting browsers
• Merlin: a new framework for defining wizards
• MooseAlgos: Improved generic algorithms for graph and data manipulation
• PetitParser: a novel framework for defining modular parsers
• Improved Mondrian engine for scripting graph-based visualizations
• Arki: a framework for fast creation of custom reports

Improved user interface:

• Extensible Moose Finder based on Glamour with integrated visualizations and query facilities
• Moose meta-model browser
• Wizard-based importers for Smalltalk and Java (with inFusion)
• Customizable System Complexity visualization
• Customizable Distribution Map visualization
• Several dedicated browsers and viualizations

Better technical infrastructure:

• Hudson-based integration server
• Metacello project versioning
• Fame lint rules

Improved documentation:

• The Moose Book: http://themoosebook.org

Other applications:

• The Package Blueprint visualization
• Enriched DSM (eDSM): a suite of tools for detecting dependency cycles
• SmallDude: duplication detection engine
• Distribution Map engine

External applications:

• Aspect Maps: a visual tool for understanding Java aspects
• Spy: a Smalltalk dynamic analysis instrumentation
• AutoMoose: an integration of Moose with the command line
• Moose JEE: a set of tools dedicated to the analysis of JEE systems
• CAnalyzer: a parser and a set of visualizations to analyze C systems
• Tighter integration with inFusion for Java parsing

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

The booklet is available under Creative Commons Attribution. This is the first version. It will evolve in the near future. I will release new versions as they appear.

Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.

In other words he stated that the shape of the organization dictates the shape of the system. There are many implications of this law. For one, it makes it apparent that the design of the system starts from the very moment the organization is created, and that certain classes of designs are essentially rejected before the actual work starts. This is already thought provoking enough, but my favorite consequence is that if you are to understand a system, you also have to understand the organization that created it. And if we take it a step further, we can get a glimpse of the organization by looking at the system.

My favorite story comes from an early experiment on understanding how developers communicate by using Ownership Map. The Ownership Map is a visual approach to reveal what parts of a system are changed by which developers at what point in time. The picture below shows an example: a horizontal line represents a file in time, a dot shows a commit, and a color designates an author. Several authors work on this system for a longer period of time: red and cyan mostly working on the upper part, and green, blue and red on the lower part.

There are a number of collaboration patterns that we extracted from this kind of visualization, but for this discussion I would just want to draw your attention on the bottom left. While in most other areas we can see collaborations between multiple authors (shown by commits of different colors next to each other), in this area green worked basically alone for a significant amount of time. This was awkward and we got curious. It turned out that green did not have a second chair next to him, and thus he ended up working alone.

Conway was right. The organization does influence the shape of the system. But, he was incomplete^{tiny note}.

His law only reveals half of the story. We know from physics that any action generates a reaction. My father, who is a physics teacher, uses a simple experiment to convince 12-year old pupils of this: he asks them to hit a table with their palm and then asks them if they feel any pain. As the table inevitably hits back, he successfully makes his point.

Conway says that the organization exercises a force that shapes the system in a way that mirrors the structure of the organization. But, just like the table hits back, so does the system. The organization is influenced by the system, too.

Before entering the research world, I worked as a software engineer at a 25-people software company in Timisoara. The company basically fed from one large project that kept most of its engineers busy. The project was a couple of years old.

As I got to know my colleagues more, I heard stories about how the company started with only a handful of people. Even if at the time they were all working in a small apartment, they had fun. Each person had a clear role (e.g., architect, developer or tester) and the project advanced well.

A couple of years later the situation was significantly different. The room turned into a cosy house with a nice garden, but the fun was pretty much gone, at least from this project. No one had clear roles any longer. Instead, they were all doing pretty much one thing: bug-fixing.

What happened? Even if the project started with the best of intentions, as the system grew larger it got a cranky personality and the team suddenly found itself spending almost all the time fixing bugs. Did they actually want to fix bugs? Not really. They would rather design new things and implement cool features. It was the system that forced them to do something else than what they wished. In other words, the system impacted the organization.

In general, when systems are small, we can shape them exactly the way we want without feeling their reaction. As they grow larger they have a say in what is happening.

Conway was right, but he was incomplete. Here is my law:

Both the organization and the system it produces evolve continuously as a consequence of a complex bidirectional interaction.

In other words, if you want to understand what is happening and to figure out what to do about it, you might want to look at the problem globally, because it might very well be that the actual problem is on the other side of the fence.

^{tiny note} Ever since I heard "Adam Smith was incomplete" from Beautiful Mind, I too wanted to say that someone was incomplete.

The battle was not easy. It took a decade of agility to make tests gain their rightful place. And it’s not even a close chapter as we can still find skeptics pointing their finger to the costs of writing tests, and how this takes away from overall effort that could otherwise be spent on active programming.

Even if at first writing tests does involve extra costs, we know they save us great pain later on, because we know that as we write more code we unwillingly break assumptions from the existing code. In other words, we favor the possibility of not being able to control all the details of the system, and thus we ensure that the computer will be able to do it for us. And, the funny thing is that it turns out that thinking of tests makes us better programmers, too.

But, what exactly does make unit tests so useful? First, the ability to run them continuously makes for a fantastic feedback machine. And second, because they tend to be extremely contextual, they provide the kind of feedback that can lead to immediate actions.

While testing is important, it concerns but one aspect of a software system, namely the expected functionality. However, there are many other aspects that require similar attention. The internal quality of the structure of the system is as important. The interaction between the different technologies used is important. The traceability of features is as important. The conformance to external guidelines and constraints is as important. The performance is as important. The security issues can be as important. Even the cleanness of the build system can be an important issue.

How important are these? For example, various reports claim that up to 50% of the development effort is actually spent on understanding code.

Given that 50% is quite large, you would expect a significant amount of tools to be geared towards this side. In practice however, developers mostly rely on code reading. Granted, modern IDEs do provide some help, but software systems are large and complex, and thus relying on reading them just does not scale when we want to understand them as a whole. For example, a person that reads one line in two seconds would require approximately one month of work to read a quarter of a million lines of code. And this is just for reading the code.

So, do developers actually read the entire code? Not really. They typically limit the reading to a part of the system, while the overview is left for the drawing board from the architect’s office. Thus, most decisions tend to be local, while those that are global are mostly based on inaccurate information.

To rectify the situation we need tools that help us crunch the vastness of data. However, not any tool does the job. Many tools exist out there to deal with various aspects of data and software analysis, but most of them take the oracle way: they offer some predefined analyses that provide answers to standard questions. That is great when you have a standard question. However, it turns out that most of the time our questions are not quite standard. In these situations, regardless how smart the analysis is, it is of little use for the analyst.

We need customized tools that provide contextual feedback. One reason regression tests are so useful is that they provide contextual feedback. It would be great to create assessment tools just like we now create tests. The only trouble is that the cost of building such tools is too high. Or at least it is perceived to be, especially if you have to write them from scratch. A middle ground can be found by having a platform upon which these tools can be built. Drawing from the testing parallel, we would need the correspondent of an xUnit-like platform.

Moose is such a platform that was conceived exactly to ease the building of complete and customized assessment tools. While Moose tackles the problem of assessment globally, depending on the goal you can have other solutions, too. For example, for querying you can use text-based ones like grep or more complex ones that deal with AST information like PMD. Using platforms like these makes tool building practical.

Once you control such an infrastructure, building a tool costs almost zero. That is especially if you compare the building costs with the costs saved by using the tool.

However, one cost still remains and it should not be taken lightly. Just like in the case of unit testing, the greatest challenge is to shift your state of mind from what you do, to how you do what you do.

At first it might be clumsy, but as you get used with continuous and contextual feedback you you will get hooked.

Just give it a try. Leap. I promise that you won’t want to go back.

Waterfall is the best process, only not for humans. We just cannot think everything through. Even when we think we did take everything into account, we learn that we missed at least some details. The main reason is that our capacity is limited and thus we can only process a reduced amount of data. It is only logical that we get to miss details. Another reason is that we all perceive reality in different ways, and as soon as more people need to work together, the issue of communicating adds to the problem.

As a consequence, a more humane process is one that embraces our limitations. Agile processes do that. Instead of striving to conceive the perfect solution upfront, they promote iterations, feedback and the ability to react and correct the current situation.

However, to be able to react, you need to know what to react to. To take the right decision we need to be able to assess the situation accurately at all times, and given the fast development pace, we need to do it in a timely fashion, too. Effective assessment requires the relevant information to be available as fast as possible.

The only tiny problem is that software systems are large and complex and they handle large amounts of data. Thus, they present many details that make difficult the identification of the relevant information.

Approaching the problem in an ad-hoc manner does not benefit us. For example, when it comes to assessing software systems we mostly rely on code reading. Granted, modern IDEs do provide some help, but this solution does not scale when we want to reason about a system as a whole. To put it in perspective, a person that reads one line in two seconds would require approximately one month of work to read a quarter of a million lines of code. And this is just for reading the code.

Various studies report assessment to account for as much as 50% of the total development effort. Assessment is an important activity and it should be addressed explicitly in the development process. Especially in an agile development process.

On the one hand, we should have tools that do the grunt work, and that allow us to focus on the relevant information (yes, Moose is a great such a tool :)). On the other hand, we need better techniques and practices. Tools are great, but they are just tools. We should not forget that assessment is a human activity and the goal is taking better and timely decisions.

1. You land in a foreign city. You have no map and no compass, but you have access to a huge set of detailed pictures of all the streets and buildings from around you. Now picture yourself needing to find the way to the hotel on the other side of the city. How would that be for an experience?
2. You land in the middle of a software system. You have no map, but you access to a huge set of text files with all the details of the system. Now picture yourself trying to figure out where the center is. How would that be for an experience?

In the first case, we figured out a long time ago that we could do better. We constructed compasses. We came up with the sextant. We built maps. Lots of maps, not just for finding our way, but for figuring out where everything is. And we did not stop there. We went to great trouble to send satellites in space just to help us get an up-to-date picture. We developed smarter systems that figure out the best paths for us, and built GPS systems to make sure we know at all times where we are and where we are heading. We then figured out that personalized maps are even better than generic ones. So we built huge systems that allow each of us to craft these maps that highlight selected things. And more is happening every day in this area. All in all, great expenses. But it was all worth it.

In the second case, we are still mostly stuck with a sea of low level details. We could and should do better.