How to Write Unmaintainable Code (2003)

1. Don't write it yourself. Your expertise is too precious for the company and you work in a high cost location which automatically makes you too expensive to actually code. Outsource it to some other team in a low cost location. Hire entire team for the purpose of the project, ensure they know most of them will be let go before the project end and ensure they have no vested interest in the success of the project. Provide as little actual guidance on how the problem is to be solved, only very general requirements. Let the team self-organize. Don't supervise (your time too precious, remember?) and only ever involve in discussion about high-level architectural concepts. Expect the application to be delivered to PROD on time regardless of the state and the missing features to be substituted with workarounds.

2. Not happy with quality of the code? Start a rewrite without a good idea on why exactly you are doing the rewrite, what you want to achieve or how you are going to do it. Decide to slowly migrate functionality from the old service to the new one using strangler pattern. Don't get buy in from your stakeholders. Annoy them with requests for more staff while delaying development of critical features and creating more and more incidents. Eventually put the migration on hold having multiple services with unclear boundaries, copies of functionality, nonexistent documentation and new development team because the old got fed up with your bullshit.

3. Accept government contract to move 10 messages from webservice to a mainframe. Ensure you need 5 different features when processing moving the data. Each of the features requires, of course, their own programming language, database technology and their own message format. Use 20M (yes, that's twenty million) LoC. Yes, I have worked on a contract to add new functionality to something like that (10 messages with two dozen fields to move from ASP.NET service to IBM mainframe. 20M lines of code. Polish social insurance administration)

- Use exceptions for control flow. With different exceptions leading to entirely different flows. On C you can use setjmp/longjmp + globals for a similar effect. This will help the maintenance programmer develop thinking in multiple dimensions.

- To save space, do not declare separate constants for every magic number/string. Instead use one large constant pooling all the constants, and then deduce the other constants from parts of the one large constant. You'll be teaching the maintenance programmer an advanced optimization technique.

- Abuse localization rules whenever a case-insensitive operation is operated (e.g. Turkish i, German eszett, etc.). You'll be broadening the mind of the maintenance programmer, teaching cultural differences.

For extra points, when dealing with fixed string constants in the code, abuse Unicode's right-to-left rules to make the shown data rather different than the actual data the compiler sees, and zero width characters the make the shown length different than the actual length. This is particular useful with the "one large constant technique" from above.

- Do use locals when the locals shadow the global variable. This will teach the maintenance programmer to pay attention.

- Supply more precise overrides in files/projects included in partial compilation as to make code that will behave differently depending on compilation order, included files/projects, etc. This will help teach the importance of a build system.

Bonus points if the included code is actually similar, but relies on subtle differences in the behaviour of a previous version of the framework or included packages.

2018 https://news.ycombinator.com/item?id=17781475

2016 https://news.ycombinator.com/item?id=12188236

2016 https://news.ycombinator.com/item?id=12165878

2015 (different article, same title) https://news.ycombinator.com/item?id=10237636

2015 https://news.ycombinator.com/item?id=9602743

2013 https://news.ycombinator.com/item?id=6849532

2012 (a bit) https://news.ycombinator.com/item?id=4717912

2010 (a bit) https://news.ycombinator.com/item?id=1573034

2009 https://news.ycombinator.com/item?id=637491

As for the year, 2003 is an upper bound given https://web.archive.org/web/20030626161523/http://www.mindpr.... Open to lower suggestions.

This is the worst thing that you could ever end up dealing with. Back at an old job many many years ago, the company bought a smaller one with the same business. Me and my at the time tech lead were given the task to migrate the database from the system they were using into ours. "How hard could it be" we thought. Well... All 51 tables scattered around two databases were in Romanian. Needless to say neither of us knew a single word in Romanian. I was surprised how much we managed to learn in a month though.

In all seriousness though, I have found that even with carefully and thoughtfully named variables, classes, methods, etc., code with no comments and no human-readable explanation is very difficult to maintain. I’ve been doing it for years and it never gets easier, especially with large code bases. Yes, the ROI for adding useful comments may seem low now, but it does pay off for the unlucky newb, intern, or junior engineer who’ll be stuck fixing that tricky bug or integrating that odd feature request in the future.

But there are more unintentional ways of making your code base less maintable:

- Lack of consistency: Avoid using multiple different words to describe the same thing.

- Mix everything together: This happens when instead of having a dedicated piece of code for each purpose, the code contains functions that tries to do everything at the same time.

- Cyclomatic complexity: This happens when a function can have many different unique outcomes, making it hard to understand and test. Long functions usually fall into this category.

- Implicitness: Being implicit can make it very hard to figure out what is going on. Abbreviations and acronyms fall into this category as well. Bonus points if you excessively use operator overloading, reflection or anything that can be used to have a layer of magic happening.

- Messy concurrency: If you are going to be using concurrency primitives, you better have zero tolerance with messy code... otherwise, you'll be living in a multithreaded hell made out of spaghetti involving mutexes, condition variables, semaphores where things break and you have no idea why.

- Memoirs about journeys to nowhere: This happens when instead of writing a comment explaining what something does leaving out irrelevant details, you write a longer comment that reads like a monologue with many irrelevant details where the central point is you rather than the code being documented, and reads in a complicated, non-linear way... like: "I thought this did A, but then because of B, C happens this does D. Right? TODO: find out more about E". Some people think this makes them look clever.

- Interleaved levels of detail: Instead of having layered levels of detail that do not mix, write code that deals with high level things and very low level things at the same time.

I saw @axegon_ talking about "Names From Other Languages" and calling it "worst thing that you could ever end up dealing with". But I tell you, a "Single Letter Name" master will turn your mind really quickly.

You open up the code, that's a file of over 2,000 lines, no comment. Everybody inside there were called `a`, `b`, `n`, `i`, `q`. Some functions were a little better, `handle`, `add`, `equal`, `DataClass`, `MainProcessHandler`, `Service`.

Yeah, I rewrite the whole thing because at least I can trust the stupidity of my own.

  if check_date(owner):

  if has_an_active_subscription(owner):

Step up your game by defining those methods from a DB entry.

(I wish I was making this sinister plan up for satirical purposes)

1. Big commits make it easier to evade code reviews, submit pull requests close to the deadline

2. Commit messages should be generic and misleading

3. Logical units of change should be split up between many non consecutive commits, big commits should contain multiple different features and bugfixes

4. Have bots commit to version control frequently

5. Keep multiple copies of the same files for backup

6. Rename and move around files frequently

7. Reuse filenames liberally

If regular expressions seem too tame to you, write all your business logic in SQL that’s contained in a long stored procedure. Prefix the name of the stored procedures with “HBD_” (HereBeDragons) so that your future self doesn’t get hurt. For added pain, use triggers that will invoke stored procedures, but not everywhere. In this case, inconsistency is the name of the game.

[1]: https://xkcd.com/208/

[2]: https://stackoverflow.com/questions/1732348/regex-match-open...

The rules for maintainable code are not maintainable!

Step 1: write your project in Node.js.

I have never seen that quote attributed to Napoleon before.

Today it is known as Hanlon’s razor, but it can be traced quite far back in time, just not to Napoleon. As always, Wikipedia got you covered:

https://en.m.wikipedia.org/wiki/Hanlon's_razor

And because the new service crashes when you input a non-integer string, please catch and ignore the exception client side (we'll fix it later).

For good measure do it in TDD. That just creates the cherry on top for maintainability in high pressure scenarios where features have to be generated quickly ... and possibly not by the same dev doing previous work and is used to this high powered mode of existence.

Whatever happend to finding balance between coupling and cohesion?

As a young programmer I worked in a very serious enterprise codebase that used the systems variant of Hungarian notation: prefixing variables with str, int, bl, fl, etc. They also sometimes prefixed for scope, like g[lobal], m[odule], etc. To this day I don’t know if anyone on that team of people 20 years older than me understood why I had such a tough time not cracking up in meetings discussing ‘gstrNotFoundErrorMsg’.

https://news.ycombinator.com/item?id=17781475