Benchmarking for Agility (paper review)

Benchmarking for Agility (paper review)
http://dx.doi.org/10.1108/14635770110389816

Benchmarking in the software engineering industry becomes an issue. Companies want to compare their operations across sectors and see whether they can be better. Telecom companies want to benchmark their practices against automotive companies, aerospace companies against telecom companies, and so on.

I've looked at this article to see what kind of aspects are important in benchmarking. I must say that the title does promise much, but does it deliver?

In general - yes - but in particular - no. I expected to see metrics which one could use for benchmarking, but instead I've read that one should have "appropriate metrics" and "approppriate tools". In order to find the tools, I needed to look at the sources - and there they were.

However, I must say that the paper offers a number of measures in the categories like:

• Technology: market shares
• Demand: Product variety - number of product line families
• Process change: levels of management or cost to relocate processes

I recommend this paper when one needs "food-for-thought", but not as a definitive guide. It is way too abstract for that.

Understanding motivators... (paper review)

Understanding Motivators and De-motivators for Software Engineers – A Case of Malaysian Software Engineering Industry (paper review)

DOI: 10.1007/978-3-642-22203-0_18
Link: http://www.springerlink.com/content/w562524642r27624/

Recently I've got quite interested in the social aspects of software engineering. Why do people work as programmers, designers, testers...? What is it that is so challenging about this jobs? If we compare that to other engineering fields, software is never seen. When it comes to cars the look and the performance is what sells the car and that's what makes people work for car companies - they can do something cool.

So, recently I've come across this paper and it looks like the motivators in the SE field are exactly the same as in other fields - technical challenges, recognition, etc. It is the same what Humphrey noticed in Managing Technical People.

Impact on experimentation: quite often we see papers where authors try to assess the experience of software developers when completing a task in an experiment. Many use Likert scale-like measures and try to capture competence. In this paper, we can see a number of interesting aspects that we should measure - are people satisfied with their jobs? if so, they will do better in the experiment than people who are not motivated. Do we promote experiements as broadening activities? or as something that has to be done?

I think this paper opens up on a number of considerations in relation to empirical methods in software engineering, we should be better in capturing that!

Real analytics...

Real analytics (by Deloitte):
http://www.deloitte.com/view/en_US/us/Services/consulting/all-offerings/hot-topics/technology-2011/858746e243a0e210VgnVCM1000001a56f00aRCRD.htm

Business intelligence tools has been proven to work very well and very poor - depending on who uses them. Just like Alice, when asked where she wants to go - "I do not know", and getting the answer - "Then it does not matter which way you choose".

This article describes one of the modern trends in measurement in IT, and in SE in particular. The authors postulate that the era of traditional BI is over, and what comes is:

• predictions and simulations - companies want to play with what if ... scenarios
• social networks and data collection from those - companies recognize that sheer numbers are often as good as social trends and word of mouth

What I particularly like about this article is the implication on such fields as automotive analytics - what the analytics tools should do is what the cars do today - predict and avoid accidents, not inform about them.

Appropriate Agile Measurement...

Appropriate Agile Measurement...
http://doi.ieeecomputersociety.org/10.1109/AGILE.2006.17

A very interesting article about how to measure business/customer value in the context of Agile software development. A few interesting aspects:
- they distinguish between metrics and diagnostics (just like metrics and statistics)
- they focus on measuring outcome and not output (i.e. result and not process)
- they postulate automation and easy to collect as guiding principles

I would also like to point out that this article, in contrast to many others, talks about customers and value explicitly - this is not a very common approach.

What I lack is the relation to ISO/IEC 15939.

Comparing SW metric tools

Comparing software metrics tools
http://dx.doi.org/10.1145/1390630.1390648

I was looking for a paper the other day that would describe metric suites and I found this one (by accident). I've read it and it looks like it should be an inspiration for many master students. I see tons of thesis proposals that want to compare tools in one way or another - this is the way to do it.

There are a few things that I wanted to stress about this paper:

• The method of comparison: they've turned a rather straightforward task into something interesting - defined a hypothesis and made a quasi-experiment to evaluate it
• The metric suite - although metrics are well known, this paper shows that still the measurement method (ISO/IEC 15939) differs a lot between the tools - nice!
• The link to quality aspects (although not perfect) - makes the comparison much "deeper" than just a dry number-cruncher.

Finally, I think that the use of ISO 9126 is a bit too old - wake up: ISO/IEC 25000 has been released!

Motivations and measurements in an Agile case study (paper review)

Motivations and measurements in an Agile case study (paper review):
http://dx.doi.org/10.1016/j.sysarc.2006.06.009

This is a very interesting paper for those who would like to know more about transitioning to Agile. The paper lists and evaluates a number of measures used in Agile teams. It looks at both sociological factors (like Team education level), technological aspects (like Number of changed classes) and more.

What is good about this paper is the fact that the metrics which are used in the case study, could be used to control trends in Agile/XP teams. I would be very interested myself to see whether the team education level and the number of changed classes are correlated. How about the defect count vs. team experience? I guess I would need to find another paper about that, though...

What is very good about this paper is that it is an experience report - not a scientific/theoretical thing - a real deal. One might criticize, but it is better to learn from it.

The paper is worth reading and worth using:)

_M

The Mythical Man Month - Anniversary edition

The original book - very good. The add-on - overrated and not worth it.

The author have spoilt the whole book by adding a reprint from the book and making the book worse than the original. Being a scientist one could very, very easily have had a coffee with two-three colleagues and come up with the same conclusions.

The only thing that is for the authors: Congratulations for making a good book worse! and to the people (like me) who bought this book - You have been fooled!