How To Write Unmaintainable Code and Enjoy Lifetime Employment

[Andy Nguyen]

In the interests of creating employment opportunities in the Java programming field, I am passing on these tips from the masters on how to write code that is so difficult to maintain, that the people who come after you will take years to make even the simplest changes. Further, if you follow all these rules religiously, you will even guarantee yourself a lifetime of employment, since no one but you has a hope in hell of maintaining the code. Then again, if you followed all these rules religiously, even you wouldn't be able to maintain the code!

You don't want to overdo this. Your code should not look hopelessly unmaintainable, just be that way. Otherwise it stands the risk of being rewritten or refactored.

http://www.thc.org/root/phun/unmaintain.html

 

[KaiRu]

Nice link!

It's so called "job security through code obscurity".
There is a great peresentation available on this topic - Unfactoring from patterns.

 

[alain]

Funny thing, one way to obscure your code is to follow Microsoft standard practices of Hungarian notation.

 

[Ohad]

In the interests of creating employment opportunities in the Java programming field, I am passing on these tips from the masters on how to write code that is so difficult to maintain, that the people who come after you will take years to make even the simplest changes. Further, if you follow all these rules religiously, you will even guarantee yourself a lifetime of employment, since no one but you has a hope in hell of maintaining the code. Then again, if you followed all these rules religiously, even you wouldn't be able to maintain the code!

You don't want to overdo this. Your code should not look hopelessly unmaintainable, just be that way. Otherwise it stands the risk of being rewritten or refactored.

http://www.thc.org/root/phun/unmaintain.html

I would have to say that this will backfire if anyone tries to use it. The simple reason for that is that unless you are working solo on a project and all you do is supply a black-box to the other groups you work with, people will comment you about you poor working practices and will not want to work with you.

Not to mention that many companies enforce rigid programming rules that say explicitly not to do some of the advices given there.
So it might work for a week but after that your boss will either kick you out or make you change it.

That being said, it can take a day, a week but if someone have your code and it isn't decrypted , they will be able to use it.

 

[SYau]

Funny.

 

[Andy Nguyen]

I would have to say that this will backfire if anyone tries to use it.

The rule was clearly spelled out in the first post. Our goal is to ensure we have a lifetime employment, right

Then again, if you followed all these rules religiously, even you wouldn't be able to maintain the code!
You don't want to overdo this. Your code should not look hopelessly unmaintainable, just be that way. Otherwise it stands the risk of being rewritten or refactored.

 

[Andy D.]

That's a very funny article

 

[efajardo]

The rule was clearly spelled out in the first post. Our goal is to ensure we have a lifetime employment, right

Hey Andy:
I'm curious where do you find so many interesting (and sometimes funny) articles? What pages do you check out?

 

[Andy Nguyen]

I monitor and follow a lot of news outlets, interesting people via Quantnet's twitter account
It's getting harder to shift through the mountain of info, real time streams each day.

 

[tobias elbert]

That's my favourite:

Local Variables

Never use local variables. Whenever you feel the temptation to use one, make it into an instance or static variable instead to unselfishly share it with all the other methods of the class. This will save you work later when other methods need similar declarations. C++ programmers can go a step further by making all variables global.

 

[Daniel Duffy]

It's amusing to see how bad, undocumented code is accepted as the norm. In other disciplines the code would be kicked out.

The basic problem imo is that developers have not learned how to design software before they start implementing. The rest of the story is well known. The process tends to be chaotic.

The 5 CMM levels of software process are

1. Initial (chaotic, ad hoc, individual heroics) - the starting point for use of a new process.
2. Repeatable
3. Defined - the process is defined/confirmed as a standard business process, and decomposed to levels 0, 1 and 2 (the latter being Work Instructions).
4. Managed - the process is managed in accordance with agreed metrics.
5. Optimizing - process management includes deliberate process optimization/improvement.

It's a continuing drama...

 

[cgorac]

The 5 CMM levels of software process are

1. Initial (chaotic, ad hoc, individual heroics) - the starting point for use of a new process.
2. Repeatable
3. Defined - the process is defined/confirmed as a standard business process, and decomposed to levels 0, 1 and 2 (the latter being Work Instructions).
4. Managed - the process is managed in accordance with agreed metrics.
5. Optimizing - process management includes deliberate process optimization/improvement.

Interesting that throughout all of my work experience, whenever I was part of an organization trying to push developers beyond level 1, it ended up as a disaster... On the other side, level 1 always served me very well, so I guess I'm just going to stay there.

 

[Daniel Duffy]

Interesting that throughout all of my work experience, whenever I was part of an organization trying to push developers beyond level 1, it ended up as a disaster... On the other side, level 1 always served me very well, so I guess I'm just going to stay there.

Fair enough. Of course heroics without the chaos :D

I am glad you don't make pacemaker s/w.

Old system saying
"if you have a guy who is good in an emergency, keep him on board and you will always have one" :D

 

[cgorac]

Fair enough. Of course heroics without the chaos :D

I am glad you don't make pacemaker s/w.

Old system saying
"if you have a guy who is good in an emergency, keep him on board and you will always have one" :D

There exist many types of programming work. Certainly a well-defined process is to be followed when writing code for pacemaker, or anything alike. But not that many programmers are in position to work on this type of software. Still, for many of them, some sort of process is needed, simply because number of programming positions nowadays are drones. However, there also exist types of programming work where imposing some rigid process is not needed, and is even counter-productive. So all that I intended to say with my previous message is that there exist counter-examples to your claims - namely, if a development is not following some prescribed process, it doesn't necessarily mean bad and undocumented code will be produced (and vice versa).

 

[Daniel Duffy]

I agree, it depends on what the final software product is and how long it wil live. Some products hava a lifetime of 20-30 years while some have a shelf life of a few weeks.

CMM is tyically about process quality; product quality is another concern altogether. ISO 9126 discusses s/w product quality, i.e. all those nice "-ility" characterictics.