The Janitor Programmer's Website

I realize that this may not be a very glamorous name, and even a little silly sounding. Well, having been given code to maintain that looks like this is far from glamorous and a little silly.

q = 0
set oRS = Server.CreateObject("adodb.recordset")
oRS.open "Select * from Members", "DSN=SQLDSN", 2, 2
if not oRS.EOF then
	while not oRS.EOF
		redim preserve myarr(q)
		myarr(q) = oRS("name")
		oRS.MoveNext
		q = q+1	
	wend
else
	oRS.open "Select * from Members2", "DSN=SQLDSN", 2, 2
	while not oRS.EOF
		redim preserve myarr(q)
		myarr(q) = oRS("name")
		oRS.MoveNext
	
		q = q+1
	wend
end if

Yuck.

So what is a Janitor Programmer? If you have maintain what one of my former bosses would refer to as "A steaming pile of code", you are a Janitor Programmer. If you work in a large ISV where field people have written a lot of code and you get to maintain it and release it basically unaltered because management deems that this is good, no matter how bad the code base, you are a janitor programmer. If you’re the guy in the office everybody comes to when they need a one-off script in Python, Perl, awk (yes, some of us still use awk), etc. to count the number of translatable strings in a resource or to merge several complicated files into one cohesive and useable file, you are a janitor programmer. The overriding theme is that somewhere along the way you have been identified as being very good at cleaning up other people’s messes and generally speaking, you get things done.

Why this site? There are plenty of sites about good programming practices. How to code. What languages are best. Good practices for variable names, function names, comments, indentation, brace alignment, casing and a whole host of other things that developers pick up along their career paths. There are also several sites that seem to be dedicated to pointing out the more hideous pieces of code that have somehow escaped into the wild.

What I’ve found lacking is a single repository of information for handling maintenance problems. At one time or another in just about every developer’s career I know of, there is some story about some monster piece of code that is just plain bad. And they get to maintain it. It is brittle. It is hard to read. It is buggy in the quirkiest places. And you can’t scrap it because it is fundamental to how your product works, took five years to get to its current state and nobody is interested in completely starting from scratch.

From time to time I will be posting new articles here summarizing what I think are key points to being good at maintaining and extending an existing codebase, no matter how bad it is. There are discussion boards where people can discuss approaches, tips, tricks or just plain vent about horrible situations they are in. If you want to submit your own experiences or views for a feature article, please Please be aware that all submissions become the property of Janitor Programmer