Ahhhhhhhhh. The Stay Puft Man

I once knew a man, father of a friend of mine, who remarked that one of his sons "costs me a lot of money"; private school and all that.  Applications designed to be difficult to maintain are a lot like prodigal sons, the money just seems to fly out the window.  Coders remain adamant that their API's are what make software easy to maintain.  Baloney.  The proliferation of code, much as it was in the 1960's (when COBOL was going to make application development so easy, a manager could do it), is justified on the grounds that the latest New Thing in coding will make all the angst go away.  Hasn't happened, now has it?  Perhaps we should stop looking to bloatcode for the answer.

SQL Server Central has an article on maintenance.  I was moved to post a reply, herewith entered for your approval.  Another opportunity to ring the bell for SSD/BCNF systems.


In the world of commercial/business software, aka database systems, the answer to maintenance costs is to embrace SSD/BCNF.  Why, you may ask?  Let me count the ways.

1) by putting the data and its integrity logic in one place, the server, letting the client code be responsible only for screen painting and data input; one small group of smart database geeks keeps the data under control.  compare to the human wave approach of client-side coding.  in fact, embracing SSD/BCNF means the data is utterly agnostic to the client code.  could not possibly care less whether it's a java screen, or VB screen, or csv file.  makes no difference.  I offer xTuple as an example; not yet a SS application, not that this matters much.

2) by embracing SSD/BCNF, maintenance amounts to adding columns/tables/rows (a row is a business rule, remember) to the schema.  the data hangs together on the RM. 

3) by embracing SSD/BCNF, client side code can be generated from the schema.  not saying it has to be, or should be (well, yeah, it should), but it can be.  at the least, clients should interact through SP.

4) with significantly (and soon to be, massively) parallel servers available for small bucks, what's the most adept application for such machines?  well, the relational database engine, of course.  client code, not so much; as client coders are discovering.

5) by embracing SSD/BCNF, the byte footprint is an order of magnitude less than it is with the flat-file storage so beloved by C#/java/VB/COBOL coders.

6) as Celko (at least) has written (in "Thinking in Sets"), using auxiliary tables to implement constraints makes maintenance still simpler:  just add (or delete) rows to update constraints.  for that matter, authorized users can update check constraints and the like from screens; such constraints are just text stored in the catalog.


That should do it for now.  Remember, the cost of maintenance is *directly* a function of the code/data structure.  The more obscure that structure, the higher the cost.  Historically, for those that have been paying attention, coders view life (largely because those that employ them are dumb enough measure them so) as a LOC exercise.  Anything which increases the LOC future is good; likewise, anything which decreases LOC future is bad.  Those that employ them often take the same view, though few will admit it.  The reason is that such organizations are inherently bureaucratic, and in that environment the one with the deeper org chart gets more money ("I manage 5 managers and 100 staff, you've only got 3 and 50").  Efficiency and productivity really aren't the goal.  The hardware and software to solve the issue, in the commercial world, has existed for decades, yet the COBOL/VSAM paradigm persists; only the syntax has changed.  That's not an accident.  The RM and RDBMS are actively opposed in many shops just because fewer coders would be needed, to do all that maintenance that CIO's complain about; which fact keeps the CIO's org chart growing.  Hmmm.  Curious.