Writing code is hard. Luckily, the world is full of resources to help us with the task. Books, conferences, seminars, university courses, magazine articles, blogs, Web sites – all promise to teach us how to write programs. But the luxury of writing programs represents, in my estimation, the smallest part of the software developer's career. Far more commonly, we inherit responsibility for someone else's program code. And on this topic, the development experts are lamentably unhelpful.
It's a shame, because this job – maintaining, correcting, documenting, updating, completing, and extending existing code – is much more difficult than writing new programs. It is, after all, harder to read code than to write it.
My first programming job centered around an inherited codebase. I was first called upon to write little patches for the bugs that halted the existing application now and then. Eventually I began adding features. After some months of this, I had a vision of what the app could be if it were fundamentally restructured in a new release. I sold the vision to my employers and got permission to rev the app. It was only after that rewrite was complete that I won permission to create a completely new app.
I imagine this sounds familiar. This is what a career in software development looks like.
It's all wrong, of course. Maintaining and extending a body of existing code is much more difficult than writing new code. We should assign our most experienced and efficient programmers to maintenance. But that would lead to a revolution, wouldn't it? Because we all want to exercise more creativity on the job, and there are more opportunities to be creative in writing new apps.
Search the Web for advice on maintaining an inherited code base and you'll find two sorts of information. You'll get articles that look promising, but turn out to be advice on how to write new code that is more maintainable and extensible – useful, important advice, but not relevant to the task at hand. Or you'll get advice on refactoring.
Don't get me wrong, I'm all for refactoring. But how many of us have the luxury of spending months making small improvements to the underlying design of inherited codebases, without making a single change in the software's functionality? Where does one find such an unlikely confluence of management enlightenment and budgetary largesse?
Years ago, CASE tools promised to read source code and create navigable graphic representations of the code's workings. You could look at a high-level diagram to explore the application's main functionality and zoom in to see the individual modules, classes, functions, and lines of code that instantiated that functionality. I thought those tools had real promise.
Alas, the tools have not kept pace with the reality of modern apps. They worked well enough for applications that were built of a single source-code file. But today's apps, as you well know, are built in modular fashion of libraries, subsystems, Web resources, and code files written in multiple languages. I don't know of a visual tool that can cope with such complexity. (I would be delighted to learn of one.)
So here we are, stuck. We arrive at the workplace full of great knowledge about how to write new programs and find ourselves challenged with a harder task that no one warned us about.
It's just one of the reasons I think our so-called profession is a mess. I'll share more in future posts.
Web recommendation: The good folks at whitehouse.gov – yes, the President's Web site – have added a feature called We the People. It's a page where any user can launch a petition, and where visitors can virtually sign petitions if they find themselves moved to. Officials promise that petitions receiving 5,000 or more signatures will get replies, and perhaps even move the administration to action. I learned about We the People because I got excited e-mail from correspondents who wanted me to sign a petition calling for a ban on software patents in the U.S. I'm not going to post a link to the petition because the proposed ban is not sufficiently detailed, and it is wrongheaded to boot. Software patents do more good than harm. I do appreciate the Obama administration's little experiment at populism, however. We the People may not be the most efficient or well-implemented scheme of getting people involved in politics, but I think its creators have their heart in the right place. J.D. says check it out.
J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He recently relocated to a small town outside Belgrade – stop by if your travels take you through Serbia.