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:

Coding standards - if you are selling source code then pay the equivalent of an intern/editor to tweak the source product, try to get people to use a similar style (good luck), and hope for the best. Don't debate. Dictate. Assert, trap, trace - These are useful tools when things go wrong; add them if you get a sticky bug and leave them once added. Don't write them every where; you shouldn't need to. Debugging Techniques - Code like JavaScript that can exhibit weird bugs because it is so loosey goosey needs debugging aids more than managed code like C#, using techniques like the debugger; statement are useful Small, well-named methods - SWMs still rule. If can GROK a method at a glance then it probably isn't going to cause you significant headaches Commenting - unless you are writing a framework or publishing your code, an SWM beats a comment any day; if you are writing a framework, can you say ";comment intern"; Invention - still love it, still doesn't pay unless you are in the business of inventing stuff Third Party Code - I refer to now as ";Other Party Code";; let's face it, no matter how much code you write most of the code you are using is other party code. Buy what you can as often as you can may help you meet deadlines and make a profit Refactoring - After a decade since William Opdyke published his thesis it'd be great if people wrote Refactored code out of the gate Design - UML for every aspect of a project seems impracticable, but if it is important {like tanks, planes, people's money, death, or taxes} then it is probably a good idea

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?)