Friday, November 25, 2011

They way your work is structured has impact on customer quality...

Software Dependencies, Work Dependencies, and Their Impact on Failures
http://dx.doi.org/10.1109/TSE.2009.42

While reading this article from TSE I've realized that this is a very important aspect in software development. It has been discussed how team dynamics influence the spirit of the organization, but this paper looks closer at the work dependencies and coordination requirements.

What I like in particular about this paper is the recognition of coordination as one of the factors that can influence the quality of code. To put it in simple terms - if coordination is required, but not realized, then there are a lot of assumptions in the code. The assumptions are risks and can lead to failures.

Since it is a TSE article, it contains a lot of useful links to related work and is based on solid data collection methods.

Interesting reading, although perhaps not for friday evening....

Wednesday, November 16, 2011

Is continuous integration enough? Not... one needs to push the boundaries (paper review)

Pushing the boundaries of continous integration (paper review)
http://dx.doi.org/10.1109/Agile.2008.31

I was asked recently the following question If continous integration is not the last thing to do, what else is there left? which got me thinking.

There is the deployment, sure, but it often is part of another project. Then I thought - testing - and I've looked for articles about test automation and I've found this nice experience report from BT. They extend the CI with robustness testing and durability testing.

This is a really nice example of how to improve CI. What I like about it is the toolsuite which they have evaluated - all open source.


Sunday, November 13, 2011

Two tools for continuous deployment...

Since measuring the continuous integration and deployment is an important aspect in contemporary software engineering, I've looked at one (or two, depending how you count) tools that stimulate this.

Hudson and Jenkins, are two tools which automate jobs and provide statistics on how the result of these jobs look like.

What I like about this tool is the fact that it can automate all kinds of batch jobs, not just building via makefiles.

I will try to use this tool in our work for executing measurement systems, status of builds, but also sending e-mail to customers with links, link statistics (if coupled with Google Analytics).

Particularly the last one is very useful for continuous deployment - the system sends out links and then looks at the statistics which software links were used - i.e. how many installations we have.

Can't wait to play around with the tool a bit more.

Wednesday, November 9, 2011

Metrics Functions for Kanban Guards

Metrics Functions for Kanban Guards (paper)
http://dx.doi.org/10.1109/ECBS.2010.43

I've been recommended this paper to read by a colleague. First I was rather skeptical to it - no automation, conceptual framework. However, after I've read the paper I realized that these ideas are actually quite easy to implement.

What I like about this paper is the "Lean thinking" in the context of software development. Measuring "design debt" is also a very solid and good idea. I'll try to use that myself in my research projects - I hope to write a post on how it went after a few months (yes, months, it will take time to set things up).

Sunday, November 6, 2011

R&D Performance and metrics

Metrics for R and D organizations (paper)
http://onlinelibrary.wiley.com/doi/10.1111/1467-9310.00115/abstract

Quite often we get to see measurements at a high-level. A level so high that it is actually hard to see what should be measured. R&D or innovation is one of those things. How to measure innovation? What is a good R&D? What makes Google so good?

The last question cannot be answered by this article, but it can certainly be hinted. What I like best about this particular article is the distinction between a function and an organization in the context of R&D.

This distinction is crucial for defining effective metrics for organizations. One should first think about that the function of the organization has and then how well the organization supports this function. This is a really interesting reading...

Friday, November 4, 2011

Measuring continuous deployment

Doing the impossible - deploying 50 times per day
http://timothyfitz.wordpress.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/

This article shortly summarizes the challenges of continous deployment - how to measure it? Well, look at their diagram: the software is complete when all test cases have passed. The diagram shows a summary of passing/failing test cases for all test machines.

Wednesday, November 2, 2011

Contextualizing Agile Software Development (paper review)

Contextualizing Agile Software Development (paper review):
http://onlinelibrary.wiley.com/doi/10.1002/smr.572/full

Philippe Kruchten has written a very interesting article about adopting Agile methods in the context of companies that do not have the "ideal" grounds for it.

Kruchten presents a set of factors to consider when defining the context of the company and a set of "thresholds" for each of these factors. Nice....

I would like to quote a paragraph in the introduction which I really liked:
"An analogy [MS: to the definition of Agile] could be the definition of a road. Would you define a road as something made of crushed rocks and tar, or define it as a surface that is black rather than white, flat rather than undulated, and with painted lines rather than monochrome? Or would you rather define a road as a component of a transportation system, allowing people and goods to be moved on the ground surface from point A to point B? And then let the properties or components of the road be derived from this functional definition, allowing some novel approaches in road design, rather than defining it narrowly using a common recipe."

Think about it for a second - if we defined roads like we define Agile - would we be able to get anywhere? I think that this sums up a lot...