<< September 11, 2006 | Home | September 13, 2006 >>

Gathering Evidence

While working on a previous project, before I had a blog, I remember an incident with a particular boss at a company which thrived on a blame culture. No one cared if software was late or crap. All they cared about was whether another department was to blame.

So once we screwed up on a project and his response was "Can't you find an email showing its the customers fault?". In this case, the answer was "No, it was our fault. I screwed up and misread the requirements." Being a good boss, he didn't want to shit on me. "OK, but surely you can find an email that shows its the customers fault? Thats all I need to copy to his boss." He didn't care about the impact on the business. Didn't want me working over time to fix the problem. Didn't want me to accept responsibility for the problem. He just wanted to blame some other department for the problem. And this was the way he worked project after project. Find evidence. Copy the head of the other department. Threaten to escalate...

He wasn't alone either. Every department worked in the same way. No one had accountability. It lead to people being scared to make mistakes. Perhaps that was why the company was a market leader? But it wasn't a very nice place to work.

Social Bookmarks :  Add this post to Slashdot    Add this post to Digg    Add this post to Reddit    Add this post to Delicious    Add this post to Stumble it    Add this post to Google    Add this post to Technorati    Add this post to Bloglines    Add this post to Facebook    Add this post to Furl    Add this post to Windows Live    Add this post to Yahoo!

SLOC

SLOC is "Software lines of code" and is an old measure of productivity when taken as lines of code written per day. There is lots of debate about its use, whether its good etc. But when comparing like for like, it should give valid results.

I once worked out that there were something like 20 lines of code a day developed in EAI at my last client (with say 300,000 lines of code in total). We said it wasn't too bad, compared to the old days of OS development quoted as around 5 LOC per day...

I'm reviewing a project here with around 160,000 LOC (thats an assumption that the GUI is the same as the back end, which is around 82,000 LOC). It was developed in 5 months over 820 man days. That makes around 200 LOC a day, so ten times more quickly developed than on the EAI project. It includes generated code, but probably as much as the EAI tool gives you, showing that if you want to build an SOA, that old EAI tool is slow to develop with.

I then took a look at the maxant demo I did. It has around 36,000 LOC (again an assumption that the GUI has the same amount of code as the back end which is around 18,000 lines), and I did that in around 70 man days. So that's around 500 LOC a day.

Both the project I'm now reviewing and the maxant demo have 150 lines per class helping to show that they are comparible (as well as them both being SOA, J2EE and three tiered).

What is also noteworthy here is that the EAI project did not have much budget for testing, but did have a large budget (forced on the customer!) due to bug fixes, changes and production support (due to poor error handling that was never fixed). The other two projects had large amounts of testing before release, and hence little production support and few changes or bug fixes. To me, this indicates that doing lots of testing certainly increases the productivity when measured as LOC per day, compared to a little amount of testing which is known to cause more effort at the end for bug fixes and unplanned changes.

Finally, the reason for maxant Demo being more productive has less to do with me being clever, than it being developed using a single developer. It is well known that the fewer lines of communication there are, the more efficient projects run, and it cant get more efficient than with one developer who is the architect, project manager and customer as well! So the lesson here is to design your systems as components which are as independant as possible. This is exactly the reason OO was invented and "design by contract" became popular.

Social Bookmarks :  Add this post to Slashdot    Add this post to Digg    Add this post to Reddit    Add this post to Delicious    Add this post to Stumble it    Add this post to Google    Add this post to Technorati    Add this post to Bloglines    Add this post to Facebook    Add this post to Furl    Add this post to Windows Live    Add this post to Yahoo!