Bubble Girl

It really is true what they say; that adversity forces you to improve; whether it's physically, mentally, emotionally, or a combination of all three. Given the option I think I'd still prefer to avoid adversity at all costs, but short of confining myself to a giant impenetrable, sanitary bubble; I'm bound to encounter adversity in this world.

A few recent encounters with a particular source of adversity have forced me to really question why I religiously pursue a modular program design for all of my coding. Up until now, I probably did so because that's what my instructors repeatedly pounded into my brain throughout my education and that's what all the books I've read, written by brilliant, experienced software engineering minds, said was the right way to code. But none of those books ever did a very good job of explaining 'why' it is in fact a better way to code and I'd like to take a shot at it.

Let me start by saying that there is one unique situation in which a modular approach to software design will not be beneficial: A program that is completely error free, will never need to be modified in any way, and for no reason will ever need to be looked at or edited for the rest of its existence in this world. I'm gonna go out on a limb here and say that none of the programs you or I ever work on have or will meet that criteria.

Having established that, let's move on. I've had the opportunity, nay the pleasure, of working in multiple environments where one of my primary duties was enhancing and debugging code written by developers who are no longer employed within said company. Such code has broadly ranged not only technologies, but scales, and coding style (most of it very bad - see my Coding Kharma post below). My general response to encountering such code has been a negative one at best with enthusiastic communications to my superiors of my intention to remedy and rectify the current state of their code from this moment on. Surprisingly, I have met with some contention.

Why should I bother investing the extra time to ensure organized, modular code when the program's behavior and performance will indicate no difference between haphazard, uncommented, disorganized code?

I'll tell you why, it's simple math. When I open up a single page of your 8 page application and it's 4000 lines of code long, containing a total of 2 functions (each 800 lines long) and complete with embedded SQL and mystery session variables that suddenly and briefly appear before quickly and quietly slipping back into the black void that is your web-site state; consider for a moment the amount of time I am going to have to invest just to understand the general flow of your application, not to mention reach the granularity I need to in order to perform whatever task it is that I need to do. Now calculate the amount of time it would have taken you to incorporate a simple 3 tier (view, business logic, data access) architectural approach to your application complete with meaningful variable/method names and some simple comments indicating the business logic behind your commands, and I guarantee the first value will far exceed the second.

Software design architecture isn't about the amount of memory you're using or the performance of your application (although indirectly it can benefit these elements), rather it's about abstraction. Nobody would write a book that was just one giant string of text in random order. A book has a first page followed by a second page, further divided into organized chapters, paragraphs, and even sentences; so should your code!

Looking at the view component of your application should give me the visual elements (and that's it). Your business logic code should do just that and do it in a modular/functional way so that each individual task is placed within its own (short) function with a meaningful name. Scanning your function titles should be the cliff's notes of what takes place on the page itself. The Data Access layer should consist of nothing more than a bridge between your business logic and the database.

Knowing how to write code that works might make you programmer, but the ability to write code that can be effectively, efficiently, and repeatedly maintained and upgraded with little to no direct input from you the author, makes you a good programmer.