Thursday, January 25, 2007

Dealing with Crap Code

Who doesn’t? Only those who are lucky enough to work on small dedicated teams.

I think it would be an interesting article to face the fact that crap code and low-level developers are a staple of corporate development. The leaders in our industry whine about this a lot but it is a fact of life and it won’t improve due to economic forces. As long as a corporation can pick up a six-pack of developers from Walmart that will work for 50% of what a talented and experienced developer would work for there will be crap code. It doesn’t matter that statistics show the project will take 10x as long or that maintenance costs will be through the roof. I’ve yet to meet a corporation where those concerns matter to anybody above IT manager (if that). Long term maintenance is usually not a planning concern and is part of some other department's budget anyway.

A sad truth is that the majority of crap code performs similar to quality code so many times it is hard to argue for a decent refactoring. I’d be interested in figuring out how to use existing frameworks to better localize the crap code to small crap islands (crapplets?). Early n-tier development did this by letting the so-called junior developers do the 5000-line-per-JSP programming while the experienced developers worked on the server. This was great until people started expecting more usable web interfaces. Now the UI might have as much JavaScript and AJAX magic as the business side of the application.

I have yet to see a software process or framework that tackles this issue realistically. They have “roles” but they don’t specify degrees of capability. When 80% of your team thinks threading concerns are when your clothes start to wear out how do you best place them within a project?

I think it would be fascinating to see a software framework that specifically breaks apart concerns so that you can use your A, B, C, and D developers to the best of their abilities while minimizing the impact of the crap code that the less capable will crank out.

I don’t want to hear any feedback about how you should just get rid of the junior programmers. They have families, they have to eat, and realistically, if downsized, the more expensive developers will get the boot first. Our industry has to figure out how to best utilize the majority of its C and D-level developers. We can’t make them all project-managers.

No comments: