Why developers hate bad code

Ok, this post is about what I do for a living (job, pastime?). That is developing software. It might turn out to be really boring for those of you not in the trade, but then again it might not

.. you have been warned.

So I was reading another developers blog recently and it got me thinking. Basically Peter is pointing out something that I think most experienced developers would agree with, we spend a lot of time reading code rather than writing it.

Actually I think it's kind of similar to how lawyers spend a lot of their time reading prior cases. The reason is that the goal is similar in both cases; to take the existing system and make your feature/position fit inside. You need to find the hooks, you need to watch out for the repercussions of using those hooks.

So I think Peter's got it dead on, except he makes a point and fails to touch on how it can really be applied. How do you make reading code easier? Well editors can help some by allowing you to navigate through the code. A good find feature is the first step, but things like the Call Browser in Visual Studio can step it up a notch.

On very large projects I also index the entire codebase in a Desktop Search tool. I would like to see this integrated into IDE's so that their internal find tools utilize the desktop index. Also it would be nice to see all of this integrated into version control systems too, so that they will maintain an index of their content. Being able to find what your looking for is the first tool of reseach, which is essentially what reading old code is.

Update: Microsoft has actually implemented this, see this MSDN article on Windows Desktop Search from inside Visual Studio.

However after making search, faster, more precise, and more accessible I would turn my eye on how to make new code better. Why? Reading code would be soooo much easier if the code isn't .. well hmm crap? It's always fun to blame this generally crappiness of old code on the original developer, and sometimes it's deserved, but sometimes it's just the result of the shit that developer had to deal with.

I'll focus more on the problems that result from limitations in tooling encouraging or forcing developers to write unreadable code. In truth even when encouraged to make a mistake a developer should avoid it, but I think asking this is a futile suggestion. Sure you can affect those immediately around you, especially if your in a leadership position, but there is still a huge amount of code outside your influence. Railing on about how all this code should be better is somewhat akin to a asking a group to "be nice". Sounds great, but pretty useless.

So what can be better in tooling? I would like to see better representation and correlation of code to the actual intent. Design by contract I think is very attractive, like found in Eiffel (not all of Eiffel, please) or a better example might be Spec#.

Another area I think we need to get out in front of is in concurrency. The current model for writing multithreaded code is just not good enough. It's insanely complex and never really represents the actual intent. A far more declarative model is required here. I cringe when I think of how much greif would be caused by the rafts of locking code that developers might start using when they realize that computers have 2, 4, 8 or more cores and they aren't using them.

I could go on, but I won't, at least not tonight so Ciao.

Oh did I mention I'm going to Italy later this week? I'll have pictures next month..