Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Write Unmaintainable Code (1999)

doc.ic.ac.uk

Post reply on HN
Print view View original

11–20 of 72 posts

Re: How to Write Unmaintainable Code (1999)

#11

Post by Someone »

They are missing the creatieve use of your version control system.

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.

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)

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".

Also, make sure that "customer X" has both V1 and V2 deployed, so that future developers cannot learn that "customer X" implies "version 2".

Re: How to Write Unmaintainable Code (1999)

#13

Post by adrianN »

Someone wrote: post #11

They are missing the creatieve use of your version control system. 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. 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 custome…

You can also use a version control system like ClearCase that doesn't have the concept of an atomic commit of multiple files. Work on several features at once and check in the changes in a random order. Make sure not to leave helpful check-in comments.

Re: How to Write Unmaintainable Code (1999)

#14

Post by roel_v »

vog wrote: post #5

> You earn extra Brownie points whenever the beginning and end of a block appear on separate pages in a printed listing. I'm aware that this is from 1997-1999, but I'm curious: Do people still print out source code for better reading?

I was watching a TV documentary a few weeks ago about a botched government IT project, and a company that also had bad experiences with the company that did the project had some British auditor review the software that was delivered for their project. The show interviewed the auditor and he actually pulled out a box (maybe 50cm/20 inch high), completely full, with printouts of the whole source code of this application. He was showing his notes in them, it seemed like he actually went through and annotated 4000-6000 pages (if I estimate it from comparing to the height of a pack of printing paper which has 500 pages) of printed Java source code.

Re: How to Write Unmaintainable Code (1999)

#15

Post by marcosscriven »

Symbiote wrote: post #10
vog wrote: post #5

> You earn extra Brownie points whenever the beginning and end of a block appear on separate pages in a printed listing. I'm aware that this is from 1997-1999, but I'm curious: Do people still print out source code for better reading?

The essay was presented half-seriously as part of a module on software maintainability [1], which I took in 2007. Perl was given as an example of a write-only language: modification of a typical Perl program requires at least a partial re-write. (The extra joke was that many of the computing department's internal systems were written in Perl.) More seriously, there were discussions of library versioning schemes, back…

I fondly recall her design patterns course, way back in '96!

Re: How to Write Unmaintainable Code (1999)

#16

Post by laurent123456 »

Someone wrote: post #11

They are missing the creatieve use of your version control system. 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. 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 custome…

Also a nice thing to do is to split the project into multiple repositories, each also split into multiple branches.

Then when a dev checkout a branch in one repo, they need to find and checkout the matching branches in the other repos in order to build the project.

To make it more fun you can name the branches slightly differently from one repo to another, like "mybranch3" in one, and "my_branch3" in another.

Sometime a feature only affects one repository. That's fine - just create a branch there, and leave the other repo to the default branch - "master" (or sometime "release", unless it's "current_test", or maybe "dev-temp", or...).

Re: How to Write Unmaintainable Code (1999)

#18

Post by TorKlingberg »

Someone wrote: post #11

They are missing the creatieve use of your version control system. 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. 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 custome…

Also make sure your build system only works with a specific combination of Windows XP, cygwin and ActivePerl.

Re: How to Write Unmaintainable Code (1999)

#19

Post by DCoder »

roel_v wrote: post #14
vog wrote: post #5

> You earn extra Brownie points whenever the beginning and end of a block appear on separate pages in a printed listing. I'm aware that this is from 1997-1999, but I'm curious: Do people still print out source code for better reading?

I was watching a TV documentary a few weeks ago about a botched government IT project, and a company that also had bad experiences with the company that did the project had some British auditor review the software that was delivered for their project. The show interviewed the auditor and he actually pulled out a box (maybe 50cm/20 inch high), completely full, with printouts of the whole source code of this applicatio…

To be fair, an IDE is not geared at auditing and it would be much more painful to do freeform annotations in it. Circling problematic areas, drawing connections between variables/functions, making handwritten notes in the margin... all that is easy on paper and requires workarounds/other programs on a PC.
Post reply on HN