February 2011 Archives

Measure ProductivityToday, more than ever, analytics are the keys to success.  One of the areas that is still very hard to measure is the productivity of your application development teams.

While finding out how productive your teams are might seem scary, it is far better than not knowing. In this post I will provide three steps and some resources to help you start down the path to understanding the productivity of your application development teams. Once you have a means to measure and monitor, then you can iteratively improve your application development productivity.

1. Make the case for a metrics program

Measuring just for the sake of measuring isn't very useful. The real benefit of having metrics is gaining insight on what can be improved. Not only that, metrics also help you set objectives, what I like to call ultimate goals, and then focusing your team on achieving this goal.

Some of the best advice I have found is from the analysts at Forrester. This "Metrics for Application Development" article by Liz Barnett (UPDATE: Seems like the article is no longer available on the Forrester website. Here's an interview with the author on the subject), discusses why metrics for application development are important and gives some good advice on what you need to measure and why automating the measurement process is a good idea.

2. Measure your productivity

From my own research and experience, function points are one of the best mechanisms to measure application size and team productivity. As stated by the International Function Point User Group (IFPUG) using this metric for application development focuses measuring functionality delivered to the business, rather than how big the application is internally, how complex the code is, or what language was used to write the application.

Function points have been around for a long time and are a tried, proven and standardized approach.  There is a wealth of resources on how to measure function points, and I personally liked this PDF from a SoftwareMetrics training course and this 5 step process for counting function points from devdaily.

3. Compare to a baseline
After measuring your productivity, you need to determine how your team performs compared with other teams: poor, average or better than average.  There is good news - you can find benchmark information in numerous places. The one I like best is ISBSG.  They provide function point metrics from across the IT industry and with their data you can compare your results and act accordingly.

Go for it!
So, what are you waiting for?  Get a small team to spend some time coming up to speed on counting function points for your organization or go find a third party resource to count for you.  The investment will be worth it when you can accurately assess your application team's productivity and make decisions based on this knowledge.

At OutSystems we got our customers bootstrapped on this process by measuring their performance with something we called the OutByNumbers project. You can take a look at the results from that study here and see how we automated function point counting. I have to say the results are pretty surprising!
VISourceCode.PNG
It is now widely accepted that source code is not an asset, but rather a liability. This is a very strong idea that has a lot of impact across the IT industry and in the way developers view and perform their day-to-day work.

One of the earliest articles on this subject was published on "Object Mentor". The article is really good, but while reading it I spotted something I really can't agree with:

"The problem doesn't go away if you artificially reduce the code. (...) Moving it into metadata and models and other forms doesn't make it any smaller, and often makes it worse. Hand-crafted code is almost always more readable, smaller, more optimal, more focused, more literary in its style than generated code or funky data tables. 

Models will help!
I'm a strong believer in Model Driven Development (MDD). I think models are a great way to abstract low-level code, and can make software much easier to understand and change.  I'm not talking about using models as an intermediate stage to generate a portion of your code. True MDD means the entire development process is done on top of the model. Much like you use C# or Java instead of assembler language, in MDD you use models instead of C# or Java.

This may not completely fix the problem: following the article's reasoning, at some point the model will become the liability. But it will greatly reduce the risk of this liability for a very large part of your software. Why?  Models mean abstraction, which equals less objects to know and manage thus reducing complexity. Models let you focus on the business problem and not worry about all the plumbing to deliver a scalable, robust application.  Models reduce risk when change is needed and speed up the delivery process.

Hand-crafted code is beautiful... for 5 minutes!
The best guy on the team (you!) builds this really amazing beautiful code. It's totally optimized, and it's so wonderfully written that angels weep as they read through the lines of code... And then things change.

The code is handed out to the maintenance team, the requirements change, and assumptions used to build it turn out to be wrong... it really doesn't matter what the reason is, someone will have to touch your perfect code. And it's all downhill from there.

Blame complexity
It's not that other developers who will touch your code are idiots. It's just that the context surrounding your code is huge, documentation is typically inadequate, and although they think they get it, more often than not they miss something. The system is just too complex.

Once again, MDD provides a huge help in making the system look simpler. It makes it much easier to see the full picture, and it really improves knowledge sharing between developers. Of course there will always be problems so complex that even the model is hard to understand, but fixing the vast majority of situations is a big plus! 

Some words of advice
As you probably noticed, I'm a big fan of MDD. But you do need to be careful when picking your tool of choice. A whole article could be written on that subject, but let me just leave you with three tips: Make sure your tool supports the full development lifecycle, prioritize fast change higher than fast build, and make sure the application generated by the model is based on standard technologies, is fast and scalable.

My final advice: quit piling up the debt and start investing in MDD now.  

Happy modeling!

OutSystems® Platform

Build your next great Web App today: Take a tour of the OutSystems® Platform