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.

Here is the abstract:

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 productivity to the maximum. Except that we typically do not know the best way. We know just 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.

In this talk we distill some lessons learnt from the time we spent in the research world and in helping companies rethink their approaches. It turns out that the path to follow is not dependent on the domain, and that a set of simple steps can get you quite far:

• Always challenge the status quo, even when it appears perfect.
• 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.
• Enable new things to happen.

Of them all, focus on the demo. Relentlessly. Much of the rest will follow. This is the simplicity and power of the demo-driven way.

Why is this relevant? Because it affects everything you do, including the design of your software system, understanding your clients’ requirements, or managing your team. And because the solution is simple and cheap.

What is new:

• New editors for scripting browsers and visualizations
• New parser for SQLite
• New Glamorous Inspector for working with Smalltalk objects
• Improved Glamour browser building engine
• Improved EyeSee charting engine
• Improved FAMIX API
• Improved FAMIX to support Java and C++
• Improved external importers to support Java and C++

A list of issues addressed in this release can be found at:
http://code.google.com/p/moose-technology/issues/list?can=1&q=status=Fixed%20milestone=4.6

The audio and the picture was done through Skype, while the screen sharing was achieved through TeamViewer. It was fun to do it remotely. From and experience point of view, there were at least two things that made for a interesting experience:

• I did not see the audience. This was tough. During face-to-face demos, I spend most of my time looking at the audience as I try to understand what works, what does not, what needs repetition, or what needs to be told in a different way. In this case, it felt like driving blindfolded: dangerous and thrilling.
• Slow interaction. If during face-to-face demos I can react in real time to the points raised by the audience, in this case, the communication was less real-time. This was both a problem and an opportunity. On the one hand, this lag induced a low interaction. On the other hand, because of the lag, I had more time to think.

All in all, it was an interesting experience. At least for me.

The company was located in a large house with a nice garden. When I joined, I was given two options for where to have the office. One was in a quite corner of a small room. The second one was in the lobby which was rather windy due to the several windows and doors, and rather noisy given that this was the place everyone was traversing through. I chose the second one.

After poking around a little while, I decided that I want to introduce some new things in the company. And, I did not make it a secret either. Of course, not many took me seriously. I was still a student still struggling with my final exams.

I knew I could not do it alone, so instinctively, I started to look for allies. To find them I needed first to construct a map of what was going on in the company to understand who has what skills. The first strategy was to ask around, but proved to not be successful because talking was perceived as a waste of time, and as everyone had real work to do they did not have time to talk with me.

So, instead of asking for something in particular, I decided I will simply listen to whatever they will have to say whenever they will want to say it, without me pushing any agenda onto them. To get them to do their talking around me, and not in another place, I installed a honey trap. Only it did not have any honey, and it was not a trap.

My formula was: peanuts and coke. Every day, I brought with me a large bag of salty peanuts and a couple of bottles of cold coke. As my office was in the lobby, I simply put the bag on my desk and invited passing people to have a bite. Peanuts are special because of two reasons. First, you spend more time working on getting the peanuts out than you spend on chewing. So, what do you do in the meantime? You talk. Second, you can hardly eat just one. You have to have more than one. And if you combine their saltiness with a bit of cold sweet coke, you simply want more. And so, in the end, you talk more.

This might seem like quite a manipulative trap. But, it is not so if you tell it openly. Every day I told them that I give them the peanuts exactly because I want to listen to what they have to say. I even explained how it works. And they still continued to choose to be there.

Not everything they said was important, but interesting enough everyone did have something interesting to say. After a short while, eating peanuts from my desk became a small thing and people would form groups to do it. In about a month I built my map, I found my allies, and together we started our little grass-roots projects to introduce concepts like automatic builds, continuous integration or project planning.

In about a year, people changed significantly the way they developed software. Do not get me wrong: It is not because I changed them. It is because they changed. I merely started the process by proposing alternatives.

The moral of the story: I am not sure if peanuts and coke are essential, but given a chance, people do seem to want to be listened to. And, it is also apparent that listening to people is a good start towards finding ways to improve the situation. Especially when it is them that have to finally carry on with the improvement.

You can find more information and a registration form on the SwissICT website. The attendance is free.

You can keep up to date by following @humaneA on Twitter, or by registering to the humane assessment RSS feed.

In the future, my assessment related posts will be featured mostly on that site, and not on this blog anymore. This blog will remain about presentation, representation and the rest (minus assessment).

• the home page paints a brief overview of the reasons and ideas behind the method.
• the MiniBook offers a description of the context, of the method and of how to make it practical by integrating it in the development process, in the organization and by using appropriate tooling infrastructure. The minibook offers several diagrams that are also available in PDF form, and that can also be used as standalone flyers to ease communication.
• the success stories describe real examples of using the method in practice.
• the courses and services pages provide an overview of practical means to adopt the method in companies.
• the humane assessment blog will become the hub of news and information.

Stay in touch with the news by:

• following @humaneA on Twitter, and
• subscribing to the RSS feed.

Feedback is always welcome. Leave a comment on the blog, or simply contact me directly.

Me: What do you want to see?
Him: The structure of my system.
Me: In terms of what? Class hierarchies?
Him: Yes.
Me: Here it is.
Him: Nice. And what does it tell me?

If you do not ask the right question it is improbably to get a satisfying answer.

Here is the abstract:

Software systems are large and complex. Various studies report as much as 50% of the overall development effort being invested in understanding them. To deal with the vastness of data we need tools.

And tools do exist that deal with various concerns from programming idioms checkers (e.g., PMD or Checkstyle) to visualization and reporting tools (e.g., Sonar). While these tools have a place, their use is limited because they tend to 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 software systems are special and our questions are not quite standard. In these situations, regardless how smart the analysis is, it is of little use.

We need customized tools that provide contextual feedback. Moose is an extensive platform that was conceived exactly to ease the building of customized analysis tools. It is a free and open-source project started in 1996 at the University of Berne. Since then it became an international project and it is increasingly used in industrial contexts.

The design of Moose is rooted in the core idea of placing the analyst at the center and of empowering him to build the analysis, and to control it every step of the way. It offers multiple services ranging from importing and parsing data and source code, to modeling, measuring, querying, mining, and to building interactive and visual analysis tools. It especially offers dedicated solutions for systems written in Java.

In this talk I introduce Moose and I show live demos of building dedicated queries, visualizations and complete interactive browsers. The talk is best suited for technical people that are interested in retrieving the knowledge hidden in their software systems.

More information about Moose can be found at:

• http://moosetechnology.org
• http://themoosebook.org