Evolution of Programming Rules for the Road
It has only been 13 months since I worked on my last multi-million dollar project with more than a hundred thousand lines of code. Even in Internet time that is not that long ago. It has also been less than five years since a slammed out an 80,000 liner in 6 months. (I had help-one other guy-but that is a lot of code for a delivered application.) I was wondering would it be possible to start a dialogue on how much our opinions and beliefs evolve over the course of five, ten, or twenty years. (Not counting ROM Basic code in the 1970s this is my 23rd year writing code.) It was around 1990 that I began writing micro-computer based code, so I will start with some basic beliefs around that time and compare them to what I think today.
In the early 1990s I was writing a lot of C++ using the Zinc library, coding for MS-DOS, exception handlers didn't exist, Windows was in its infancy so multi-tasking, multi-threading, and distributed applications were future innovations.
In the early 1990s here are some the things I did when writing code:
Coding standards debates - Hardly productive, often subjective, more often a sign of a death march beginning Assert the world - a large percentage of conditional code had assertions Tracing - Tracing was used to log the application flow Trapping - Trapping was used to make sure all significant code paths flipped the trap; that is some scenario tested all code paths Scaffolding - Wrote about and used scaffolding routinely; scaffolding is building small test applications around discrete chunks of code Small, well-named methods - small methods with informative names beat the heck out of monolithic functions no matter how well they are commented Commenting - Commenting everything is an exhaustive waste of time Invention is sometimes necessary - I created an approximation of an global exception handler by writing a hard error handler for interrupt 0x24-a basic BIOS error service-in Turbo Assembler; you could take a floppy out of the drive mid-write and not crash a precarious DOS application Reuse - It was much more fun to invent than reuse Third party code - Third party code was sometimes necessary and sometimes cool; TurboPower components were cool, but the Zinc library was a little challenging to use Design - Design was often ad hoc, white boarded, or little more than a brief discussion
In the first half of this last decade, some of the techniques I used had changed and some maybe not so much:
Coding standards debates - can you say death march Assertions, trapping, and tracing - Get tedious if used every where, but are still useful if hunting bugs Scaffolding - Scaffolding is called unit testing now. Unit testing is all goodness Small, well-named methods - SWMs still work great Commenting - Commenting everything is a pain in the neck and tedious Invention - is still sometimes necessary just comment clever code carefully Reuse - Invention is still fun but can kill profitability Third Party Code - Writing everything from scratch is often penny wise and pound foolish Design - UML rules (but no one uses it and hardly anyone really understands it) Refactoring - What a great concept - finally the subjectivity of what constitutes good code will no longer be open for random debate (This is starting to remind me of Walt Disney's Carousel of Progress.)
In 2010 here are some techniques I employ with some tweaks here and there:
The beauty of a blog is that everyone knows it is opinion based or one person's recounting of the facts. A blog is sort of like a conversation starter at a party. One person opens up a small conversation and if no one is interested you move on to the next subject, you, through the powers of persuasion and charisma get people interested, or you sit alone (at the party). It is sometimes fun being at the center of attention, and sometimes you sit alone for a while.Have rules of the road for programmers changed significantly, evolved slightly, or skewed radically? (Or is this a party conversation starter that leaves one sitting alone?)