Working on Someone Else's Code Base: Why Applications are Easier to Write Than Maintain
Writing greenfield code is easier (and more fun!) than maintaining an existing application. But that doesn't mean it's a good idea.
Software development is full of paradoxes, especially when compared to seemingly analogous tasks in the physical world.
MYTH: It's easier to maintain a working application than to write a new one from scratch.
The reality is that so-called "greenfield" development–where you are writing a brand new application–is easier (and more fun!) than maintaining an existing application.
Now, by "easier" I should clarify that I mean it is less mentally taxing and requires less skill. It does NOT mean that it is a good idea to rewrite an entire working application (though it does help explain why developers are always itching to rewrite someone else's code). In fact, rewriting a working application is one of the things you should never do in software development as Joel Spolsky wrote about in his article, "Things You Should Never Do, Part I":
Joel Spolsky
My Father-in-Law's Barn
My father-in-law restores classic cars like the '55 Ford panel truck pictured above.
The barn in the background of that picture is his workshop. He has the tools and supplies to complete any restoration job, including:
- A clean room for painting parts
- Sheet metal cutting, bending, and shaping tools
- A metal lathe and drill press for machining parts
- Tools for debugging electrical problems
- Supplies for custom fiberglass work
- Et cetera, et cetera, et cetera
Restoring cars is his hobby, though, not his vocation. While he's very good at it–and the various side jobs it requires–he doesn't have the same level of experience as a full-time professional. However, he could easily out-perform the world's best machinist...if one of the rules of the competition was that the work had to be done in that barn.
For context, the barn looks like it was staged to be a real-life hidden object game:
The professional machinist would spend hours combing through the barn to find the tools he needed to do his work. My father-in-law on the other hand would have to waste no time. He would simply know that his tap-and-die set is under the moving blanket by the bottle of fiberglass resin because he lent it to his buddy that does fiberglass work a few months ago and hasn't needed to use it since then.
My father-in-law can work efficiently in his barn because he knows where everything is, even if it makes no sense to an outside observer.
A Method to the Madness
What appears to be random and haphazard on the surface often has an underlying logic that's hard to discern at first glance.
I know this because my own woodworking shop is organized just like my father-in-law's barn: in a way that only makes intuitive sense to me. For example, my adjustable crescent wrench is next to the Titebond wood glue bottles because it's the perfect size to provide leverage when the cap is glued shut. (And the cap is always glued shut.)
I assume his tools are arranged to provide this same type of efficiency; that is, an efficiency which is unique to the way he works.
Individual vs. Team Development
Access applications tend to evolve much the same way as my father-in-law's barn or my woodworking shop.
They evolve to maximize the efficiency of their creator.
Note that I use the singular form of the word "creator." That is intentional. Access applications are overwhelmingly the work of individuals for (at least) two reasons:
- The single-file format makes team development difficult
- Individual developers can build complex applications quickly in Access
The upshot is that Access applications take on the personality and idiosyncrasies of their creators more than applications developed by teams of programmers in other languages. Team development by its nature requires a certain amount of consensus and buy-in from each developer.
Sole developers rule themselves with an iron fist.
Anything they say goes. No idea is too bad. No decision is too short-sighted. And everything fits together in a way that makes perfect sense...to them as creators.
Unraveling the Mystery
When you take over maintenance of an existing Access application you are walking into someone else's barn or workshop.
Starting out you will never be as efficient as the original developer because you don't know where to find anything. You don't know how all the pieces fit together. It takes a lot of time to approach the level of comfort the original creator had with the software.
And even if you become fluent in how the system works, you will never think about it the same way as they did. It will never be intuitive to you. You will always feel like a tourist wandering the streets of an unfamiliar city.
Documenting how the system works can be helpful, but it is time consuming and requires meticulous attention to detail. After all, the only thing worse than no documentation is bad documentation.
Growing Pains
For users of an existing system, the initial learning curve that comes with "breaking in" a new developer (or development team) can be infuriating.
With Access applications, it's not unusual for the original developer to stick around to maintain an application for many years. In such situations, users become accustomed to requesting new reports and features and having them built within hours or days (did I mention that Access is a really good rapid application development environment?).
Users often assume a new developer that can't match the original developer's efficiency is proof that they are less capable. While that can be true, of course, the fact that it takes a new developer longer to accomplish similar tasks as the original developer proves no such thing.
Maybe the new developer really is no good.
Or maybe the new developer simply doesn't know to look under the moving blanket for the tap-and-die set.
UPDATE [2023-10-16]: That's a 1955 Ford panel truck in the featured picture, not a 1957. I deeply regret the error and am thankful my father-in-law has no idea this blog even exists so my secret is safe.
