Wednesday, October 25, 2006

500% productivity increase

Recently, I received an invitation to a Users' Conference that was dedicated to one RAD (rapid application development) tool. In other words, it was going to be a product presentation.

New technologies and ideas are always interesting. So I browsed Internet for some additional information about the product, and was very surprised when I found the following statement on the tool home site: ... is for developing, generating, and maintaining applications with an increase of productivity of up to 500%.

Of course, I didn't support that event...


It's a pity, that year to year IT people continue believing in some easy magic solution that will help them to upgrade their coding style, and start developing software products much faster than everyone else. Tom DeMarco and Timothy Lister wrote about the same problem in 1987... It's about 20 years ago, and nothing changed in this area.


Let's make some calculations.

Software development process consists of different activities including requirements analysis and documentation, programming, user documentation, testing, data processing, communication, management, and so on.

Industry statistics give different results, but usually programming part varies between 30 and 50 percents of total project cost.

It means that even if we automate programming process completely and it won't require any human effort at all, the project cost can not be reduced more than twice without improving other development process stages. So up to 500% productivity increase should be read as up to 42% of a project cost saving.

42% of a project cost saving? It would still be very very good, if it is possible!

A lot of developers are conservative enough, but almost each company has some enthusiasts who bring news to their teams. And if they finds something extraordinary, all team members will hear about it shortly.

So, to be 6 times (500%) away from some modern published technology, your development team has to be about 450% behind average industry programming speed. If it's the case, then it's easier to change the team than to try new technology ;-)


The following table lists some SLOC /Funtion Point values(the information is taken from QSM Function Point Programming Languages Table). A lot of languages are not being extensively developed during last years. They are quite stable and even corresponding frameworks and libraries do not grow as fast as before. At the same time, up-to-date SLOC/FP values show that these languages can compete with their more modern competitors. It's one more argument, which confirms that average software industry productivity is not increasing as fast as someone dreams.


















Programming LanguageSLOC / FP
Smalltalk35
Visual Basic50
JSP59
C#59
Perl60
Java60
C++60
ASP69

No comments: