The cost of technical debt: 3.61$ / line of code

We've all heard of all kinds of metaphors regarding technical debt, but until recently, I never knew of any study that could put a price tag on it.

 I guess I'm not the only one unaware of the existence of such a study because I've heard of developers almost crying (before flying away from there) because businesses are not keen on writing tests or refactor code, mainly because the cost of this walk on thin ice is not quantifiable in money.This is an issue of the past, because this study from CAST exposes millions in very well hidden IT costs.Some conclusions from the above article:

• technical debt costs companies $3.61 per line of code
• outsourced and in-house developed applications didn’t show any difference in structure quality
• neither did onshore and offshore applications
• established development methods such as agile and waterfall scored significantly better in structural quality than custom methods
• waterfall scored the highest in transferability and changeability (a surprise from my point of view)
• government systems tend to be the lowest in maintainability (I thought this was expected only in Romania)
• the more frequently the code is released the higher the technical debt (another surprise for me)

In recent years I've seen an increased interest from companies in paying for QA - rapidly moving from manual testing to more automated testing.

I believe that until recently (the last 5-10 years), since most applications were desktop based, an app was either rewritten in its entirety in order to make it look&feel modern, or replaced by a competing, good looking one. 

Since the web got traction, a company gets a much lower cost in just changing the UI and keeping adding features in the backend than rewriting the whole app. 

One issue with this, is that there are pretty small chances that code that is 10+ years old is up to date with the latest technologies (like for example, using Memcached for keeping context). 

Every developer that has to interact with that code, has to work like 10+ years ago - what developer wants that? (maybe COBOL developers, who might consider code of that age as being bleeding edge )

On the other hand, 10+ year old code brought money and it still does - who would risk the business in order to rewrite that? (I wouldn't allow such a risk on my software)

The solution is to have unit tests for all the code you intend refactor so that you can be almost sure that the changes you make don't have negative side effects.

Is this a personal impression or we really getting an ascending trend regarding automated testing?

Update:

This post is mentioned in the Perl Weekly Newsletter - there Gabor asks some good open questions regarding potential conclusions like what should we do :

• Throwing away the old and partially broken code?
• Adding automatic tests to the existing application? 
• Nothing?

I'd conclude, that first of all, we should have a general impression regarding the price we have to carry on with us because of the technical debt. I have written a follow-up article regarding possible ways to get a cost for technical debt in Perl . 

I think it is possible to get an application to a stage in which is much more profitable to rewrite the whole application or parts of it instead of continually paying interest for the debt. 

With a technical debt calculator, we could take much more pertinent decisions to questions like:

• Is it profitable going on like this, or we should do a rewrite?
• Why we pay so much for maintenance instead of bringing new features to market?
• Why in the early life of the application 2 developers were bringing 3 features per week, and now, 5 developers get out 2 features in 3 weeks?

And the questions could go on and on.

Read More

Perl Teasing Challenge

I am pretty new to Perl - will have 2 years in August 2012 - and I am in love with it. From those 2 years, I spent 8 months on a project which although was written in Perl, was in maintenance mode and I didn't have to code too much.

 I feel guilty and some kind of selfish because I don't have a short list of stuff that, showing to other developers would persuade them into start using Perl and finally making them reach the euphoria and Zen that we, the Perl Monks, have.

Having read Gabor Szabo's post I recalled to create this teasing short list of stuff that Perl will offer you.

So, if I were to create a Perl promotional presentation (a thing I hope I'll be get the time to do in the near future ) I'd go like below

The Structure of the Promo Presentation

• don't delve too deep into the syntax and only show the different type of variables that Perl has.
• reference some of the many freely available Perl Tutorials
• show some easy to understand yet useful Perl one-liners. Get inspired from this list
• introduce the often imitated(ruby gems, python's PyPI) but never duplicated CPAN

Go on with practical, hands on stuff

• the law mandates a scraping example in absolutely every Perl presentation
• going with yet another Perl trend setter WWW::Mechanize is a safe bet
• scrape the site in parallel with Parallel::ForkManager and your audience will start salivating
• keep the coolness on the ascending trend and include a demo of how straight forward it is to integrate popular services - for example the Google Spreadsheets API, with Net::Google::Spreadsheets
•  you could create a Spreadsheet form and use your Perl script to give an aggregated overview of the answers 

After showing the above, your audience should be pretty convinced that Perl has a great power as a backend language - now it's time to show them how they can glue all of those components, package them beautifully and deliver great products:

• take the above Spreadsheet integration and wrap it in a Mojolicious or Dancer web application - no need for webserver configuration, filehandler settings in Apache or other time consuming setup tasks
• you could use the Mojolicious Boilerplate in order to have out of the box neat and shiny, production ready web application

At the end of the presentation if the people in the room are not coming to you like

to ask for that list of Perl Tutorials, they should be suggested that a career in flipping burgers at McDonalds might be a viable alternative for them.

Conclusion

We are all hurried people, we are all in shortage of time and besides that, unfortunately, for many of us learning new stuff is done when we are out of school. What will motivate a person in taking action and learn something new, is something that will offer sex, fame, money or power. 

Giving a concise, easy to follow presentation, emphasizing the short path from idea to the final product will help your audience become more productive, helping them to spend less time coding and more time innovating and who knows, maybe when they'll achieve success, they'll have a job offer for you as a CTO, so talk to as many people as possible about the awesome Perl ecosystem.

What do you think are the characteristics of a highly efficient Perl Teasing Presentation?

PS: I managed to help myself from using the word Awesome, although I was tempted to in almost each phrase

Read More