They are missing the creatieve use of your version control system.<p>First, make sure none of your commits actually build out of the box; forget a file for a few revisions, accidentally check in a corrupted XML file, etc.<p>Create a "trunkV2" directory, and keep committing to both trunk and trunkV2. Add a third trunk inside the "branches" tree (/branches/featureX/newTrunk; I have seen this n practice, with random customer branches sprinkled in)<p>In the tree of the service that your program calls, do something different, for example by starting with a simple tag 'V1 frozen', adding the revisions of the V2 version and then occasionally unfreezing the V1 one by committing a combined "undo everything since V1" and "tiny fix to the v1 protocol that we thought was frozen", followed by an "undo that, and do something else" commit. Make sure to comment those commits as "version for customer X" and "bug fix #3 for customer Y"; do not mention "V1" or "V2".<p>Also, make sure that "customer X" has both V1 and V2 deployed, so that future developers cannot learn that "customer X" implies "version 2".
They've missed the liberal use of dependency injection, triggers, or anything that can create a side effect of an event without being documented in the function being executed.<p>Much fun to be had there. Even just setting up PostgreSQL partition tables can defeat the most diligent maintainer (as they suddenly find RETURNING id_column fails everywhere).
There's only one rule:<p>1. Don't write fast running behavioural tests that verify the software is working as required.<p>With fast running tests I can maintain any old crap. Well, technically speaking I can rewrite it, but no-one will mind.
I've thought a particularly effective approach is actually to do the "right" thing but take it to ridiculous lengths - the "Enterprise FizzBuzz" that was posted on HN recently being a good example of this.
Also a later version at <a href="http://www.stateslab.org/HowToWriteUnmaintainableCode-Green00.html" rel="nofollow">http://www.stateslab.org/HowToWriteUnmaintainableCode-Green0...</a> which includes that crazy offbeat language, JavaScript (which was, amusingly, my contribution).
> E.g. on the screen label the field "Postal Code" but in the code call the associated variable "zip".<p>If you support multiple countries this is probably an inevitability. Same with province vs state, potentially others.<p>I guess you could have one variable called "postalCode" and one called "zip", but that seems potentially more confusing.<p>Also, sometimes your UI shifts - should all your code change then? Because the boss wants to call something different in the UI? "We were calling them admins, now we want to call them CSR." Is it time to write a regexp to rename everything?
My favourite one must be number 20. Best ever quote of Thumper I've seen...!<p>"Never document gotchas in the code. If you suspect there may be a bug in a class, keep it to yourself. [...] Remember the words of Thumper "If you can't say anything nice, don't say anything at all". What if the programmer who wrote that code saw your comments? What if the owner of the company saw them? What if a customer did? You could get yourself fired."
How about obfuscated MUMPS?<p>P R I N T S (A,L)=1,(S,T)=I N G
G I V E N A
O F A=L:L:S Q:U=A R E S B=E L O W (A*A),!
I S (U,R,E)=T H 1 N K I T=S G O O D
And yet give me a code base with clear contracts, narrow interfaces and minimal dependencies with EVERY ONE of these so-called 'violations'...all of which are are trivial to contend with if you have a good software architecture.<p>Am wondering when our industry will see this forest for the trees...
While the advice in the article is funny, on a deeper level the author seems to argue that program text is a rather basic representation that often obstructs insight into the semantics of the program.<p>The quest for other program representations is still open. The state of the art uses text as "storage" format plus an IDE that does some semantic analysis to help the developer navigate. Many of the ideas mentined in the article (navigation, coloring, auto-format) have been integrated into IDEs and editors.<p>With almost 20 years of research between the article then and now, what semantic techniques are you dreaming of in your development environment? What are you missing? What feature would greatly improve your productivity (but is possibly too costly to implement by yourself)?
Also relevant The Selfish Class[1]. How to write classes that thrive in the struggle for programmer attention.<p>[1] <a href="http://www.laputan.org/selfish/selfish.html" rel="nofollow">http://www.laputan.org/selfish/selfish.html</a>
<i>> You earn extra Brownie points whenever the beginning and end of a block appear on separate pages in a printed listing.</i><p>I'm aware that this is from 1997-1999, but I'm curious: Do people still print out source code for better reading?
This should be renamed to: "Common red flags to look for in merge requests and code reviews" and handed to every rookie, mid-level, and senior developer on your project!
I once worked with a programmer who would not indent any of his code. "It makes it go faster" he said. Wrote all of his code in Windows Notepad too.
I've found it helpful to write several functions with the same name throughout the codebase. Also, when refactoring code, don't rewrite it completely, just clone the directory and append "_new".