By Steven "Steve" Kendall, Software Engineer

Nearby our office lies a (perhaps only temporarily) closed pizza shop named "New Pizza Town 2".  I walked past this pizza location while mulling over the history of one particular corner of one of the codebases we work with, and why no one had bothered to reimplement it.  I took a moment to reflect upon New Pizza Town 2 and could easily imagine an original "Pizza Town".  I wondered what went so wrong with the great dream of a town made of pizza that it had to be reformed into New Pizza Town.  Perhaps it had been pitched as "Pizza Town, done right".  Maybe New Pizza Town was necessary.  Maybe internally within that particular pizza zip code everyone was on the same page about this.

But I couldn't wrap my head around the "2".  Did this happen all over again with "New Pizza Town"?  Is pizza history so long that we forgot the pizza past and fell into the same pizza mistakes? Did they regret the naming convention of "New Pizza Town"?  Am I looking at what would more properly be termed "Pizza Town 3?"

Software grows and shrinks to fill new needs as time passes over it, and in some cases it can become inappropriate to try leading old software into a new role.  This can happen slowly, as the needs for software bend and bend, until some breathing, lunch-eating person notices that what they have and what they need aren't quite the same.  In these cases it can save a lot of headaches to consider other paradigms for solutions than the one that currently exists.  In some large organizations, the number of people who are supposed to be thinking about such things rather than implementing a new widget in the widget-muck down below is rather finite.  Many "future-proofing" acts add complexity yet still make assumptions about just what the software will be up to.  The net effect is that sometimes code exists which is poorly suited to fulfill its current functions.

There's a tendency I've observed with roughly equal frequency which works against the above that I've heard most commonly termed "Not Invented Here".  Individuals and groups like stuff they did, and don't like stuff they didn't do.  Rather than try to learn about code that already exists, it's only natural for folks to see something done differently than their preference and announce "I wouldn't have done it like that!"  At that moment the dream of a rewrite begins.  For me this problem is made worse because reading code doesn't inherently feel productive.  On some level, I want to push the clicky keys and implement a linked list or something.  Then I could write tests for that linked list.  Then I could document it.  I'm talking about a pretty great afternoon, here.  But the joy and sorrow of computer science is that problems map to other problems and that the world probably doesn't need my special snowflake of a linked list even if it implements cows-over-the-wire or is named with a really topical witticism.

I've been programming for a few years now and have seen some nice ways to deal with changes in software.  I'll only blather about one for now: I prefer chunkier modularity to finer-grained.  That is, I would rather have a module that fulfills a small, but appreciable task such as "converting a .ini file to .json" to trying to make really serious contracts between individual classes, the individual roles of which approach meaninglessness and are much more likely to change.  My reason for this is touchy-feely: I think modules of the larger size mentioned above are still small enough to be rewritten, and I think it's easier to see when an individual module is no longer well-suited to the company's problem.  In the example mentioned above, we may convert from a different file format.  By making the modules larger and more clearly feature-centric, I've found it to be easier to know an individual piece of code can be cut.  If something is named AbstractFileConversionBlob but actually is only required for a process specific to .ini files, one must read much more closely to recognize that class may be removed.

I came into programming from an English background.  When I was first learning to code, I remember how remarkably objective the whole business seemed to be.  Years later, I tutored some students and observed several encounter a program which, for the first time, would compile yet still not solve the problem they wanted it to solve.  Their impression of their first logic error, rather than syntax error, was universally that they were now in a real pickle.  To me programming has been filled with such thresholds.  I don't think when I first started I would have guessed I would spend so much time reading existing code, or thinking about naming things.  

While I can't predict the pizza future, I hope the restructuring of New Pizza Town 2 allows it to better face today's pizza problems.  I'm just saying I wouldn't have named it like that.

Comment