This is based on an email I send my .NET team at work
Happy Friday,
We’ve all worked in codebases (and probably created some) that are less than perfect. Sometimes we build things in a hurry, swearing that we’ll “circle back to this next sprint”. That of course, almost never happens.
Or maybe through ignorance of the underlying framework we set up an architecture that forces us to fight the framework or maintain thousands of lines of code duplicating features that were already included.
Sometimes we wonder if people do it on purpose…
How to Write Unmaintainable Code
https://www.se.rit.edu/~tabeec/RIT_441/Resources_files/How%20To%20Write%20Unmaintainable%20Code.pdf
This is a pretty funny satire piece that can teach you what to do to ensure you always have a job. Writing code that is incomprehensible to anyone else is a perfect way to make yourself invaluable.
There’s some real gems in there. How many of them have you seen and/or unwittingly written?
Use accented characters on variable names. E.g.
typedef struct { int i; } ínt;where the second ínt’síis actually i-acute. With only a simple text editor, it’s nearly impossible to distinguish the slant of the accent mark.
Use _ and __ as identifiers.
Use foreign language dictionaries as a source for variable names. For example, use the German punkt for point. Maintenance coders, without your firm grasp of German, will enjoy the multicultural experience of deciphering the meaning.
Make sure that every method does a little bit more (or less) than its name suggests. As a simple example, a method named isValid(x) should as a side effect convert x to binary and store the result in a database.
Choose your variable names to have absolutely no relation to the labels used when such variables are displayed on the screen. E.g. on the screen label the field “Postal Code” but in the code call the associated variable “zip”
The Human Cost of Tech Debt
http://www.daedtech.com/human-cost-tech-debt/
While few programmers, actively sabotage their company’s codebase, we do frequently have to maintain and enhance codebases that have significant technical debt. Technical debt is not simply “bad code” but code that was known to be less than ideal, but written because the business value of shipping now was deemed more important than the future costs.
I thought this second article was especially interesting because we usually talk about technical debt in just those economic terms. We warn clients that poor code may get it done quicker, but that the debt taken on by the shortcuts will have to be paid back with interest in the future. The repayment terms include slower feature development and increased defect rate.
But there’s also a human cost to technical debt that is often ignored or not considered when the business focuses on the risks involved. Dietrich details a few of them:
- Unpleasant work
- Team infighting
- Atrophied skills
If you’ve ever spent a lot of time in a legacy, debt-ridden codebase, you can probably relate to each of these. These are great points to keep in mind when helping a client understand the full risk of taking a particular shortcut.