How to write unmantainable code (2015) • Hacker News Board

Re: How to write unmantainable code (2015)

#61

Post by cerved » Sun, Dec 25, 2022, 9:12 AM UTC

SCLeo wrote: post #20

> Hungarian Notation is the tactical nuclear weapon of source code obfuscation techniques; use it! Due to the sheer volume of source code contaminated by this idiom nothing can kill a maintenance engineer faster than a well planned Hungarian Notation attack. The following tips will help you corrupt the original intent of Hungarian Notation: I can't stop laughing.

  m_bIsLaughing

There should be more tips, like use "l" as a prefix to any number, like shorts. Also, make sure to sometimes distinguish shorts, ints and sometimes not!

Also, when you've accumulated about ten years of this, start using a different making scheme and make sure there are preferably random bits of Hungarian notation around. Make sure there's no record of why and no explanation of what Hungarian notation is and how to use it.

Re: How to write unmantainable code (2015)

#62

Post by CHsurfer » Sun, Dec 25, 2022, 9:16 AM UTC

My son is just starting to code for a class in school. If only the author was grading his assignments…

Re: How to write unmantainable code (2015)

#63

Post by Dawnyhf2 » Sun, Dec 25, 2022, 9:23 AM UTC

If you put something out for free on the Internet, don’t expect credit. Why would you?

Re: How to write unmantainable code (2015)

#64

Post by fcatalan » Sun, Dec 25, 2022, 9:53 AM UTC

TrackerFF wrote: post #23

It's a fun read, but it is pretty much impossible unless you're running a one-man show, with zero oversight or checks at place. Code like that should set off alarms very fast, and any code review should catch it early on.

I'm that one man show, within a very dysfunctional org. I write a lot of internal tools, unprompted, just to save time for me or colleagues I like. I get bored sometimes, so deep inside some of them there's a naive Forth interpreter, and I then write some non performance critical logic in Forth. It's just a silly personal joke, at least until the proverbial bus hits me.

Re: How to write unmantainable code (2015)

#65

Post by sureglymop » Sun, Dec 25, 2022, 10:05 AM UTC

csours wrote: post #34

I just reworked some java code that is deployed INSIDE an oracle database. You can load java classes into oracle and use them like functions. So I would say: find the most obscure place you can deploy code, and make sure it is not testable.

I did this at my last job. It's truly astonishing how much can run inside the database. Your whole application and business logic if desired. I wrote a lot of PL/SQL which actually was not that unpleasant although god knows who can maintain that after I'm gone.

What I saw there in particular was that any given team will try to solve their problems in their domain. For example, I was in the database administrator team, and they tried to do everything in the database and use database features for everything. Then you have the DevOps/Middleware team who try to do everything in pipelines and with ansible scripts etc.

The best thing you could invest in imo. to be a good allrounder is really good knowledge of unix(like) systems and a shell which is available everywhere.

Write your cicd pipeline logic as shell scripts instead of e.g. the dsl of gitlab/github. That'll be usable in every domain!

Re: How to write unmantainable code (2015)

#66

Post by magicalhippo » Sun, Dec 25, 2022, 10:22 AM UTC

ElfinTrousers wrote: post #26

mtlmtlmtlmtl wrote: post #5

This is the way it seems to go in the public sector, at least here in Norway. 1. Get an n year government contract for some huge public IT overhaul. E.g building a new hospital journal system for a large region(this example is real, google "helseplatformen") 2. Spend years developing this huge proprietary .net monolith with a waterfall model, and minimal user interaction and testing during most of the contract. 3. Re…

Sounds like my experience with software procurement in state government in the USA. The basic problem as I see it is that the companies that get contracts aren't especially good at writing software, where they really shine is in understanding the intricacies of the procurement process.

> The basic problem as I see it is that the companies that get contracts aren't especially good at writing software

At least here in Norway, a huge part I think is that the buyer doesn't have a good grip on what they need. The people making writing the bids or managing the projects are too far removed from the day-to-day operation to write down proper requirements.

Don't get me wrong, it's hard. But for these large projects I think many would have gone a whole lot better if the buyer had spent more time understanding their own organization and their needs before doing these large projects.

Re: How to write unmantainable code (2015)

#67

Post by praptak » Sun, Dec 25, 2022, 10:55 AM UTC

The section on naming is amateur. Names like `fred` or 'asdf' are too obviously meaningless and wouldn't even pass a code review.

You want names that do describe your code but badly. If your function reads policies from the DB, filters them and calculates some missing data, be sure to name the function 'readPolicies'. Nobody will look at that function when chasing a bug related to the filtering part!

You may want to spread it across a few changes to get plausible deniability. You may also "fix" the name by changing it to something hopelessly generic like `initializeState`.

Re: How to write unmantainable code (2015)

#68

Post by kabes » Sun, Dec 25, 2022, 10:58 AM UTC

mtlmtlmtlmtl wrote: post #5

This is the way it seems to go in the public sector, at least here in Norway. 1. Get an n year government contract for some huge public IT overhaul. E.g building a new hospital journal system for a large region(this example is real, google "helseplatformen") 2. Spend years developing this huge proprietary .net monolith with a waterfall model, and minimal user interaction and testing during most of the contract. 3. Re…

I've been involved in some big public sector projects and it indeed went like this, but I'd say most of the blame was on the government.

The tender requirements were written by a general tender-writing team of the government.

We only got to meet the actual users of the software-to-build after we'd won the tender. Apparently what was in the tender was a complete mismatch with what the actual users wanted (as far as they actually knew what they wanted).

What the users wanted didn't matter, because payment was based on checking off all tender requirements. Oh, one of the tender requirements was "all business logic needs to be configurable by the users" and more gems like that.

Re: How to write unmantainable code (2015)

#69

Post by adammarples » Sun, Dec 25, 2022, 11:28 AM UTC

praptak wrote: post #67

The section on naming is amateur. Names like `fred` or 'asdf' are too obviously meaningless and wouldn't even pass a code review. You want names that do describe your code but badly . If your function reads policies from the DB, filters them and calculates some missing data, be sure to name the function 'readPolicies'. Nobody will look at that function when chasing a bug related to the filtering part! You may want to…

My favourite python function, get_data. Takes a dictionary called 'config'. Mutates it, sends it to another function called load_data. No docstrings anywhere.

Re: How to write unmantainable code (2015)

#70

Post by adammarples » Sun, Dec 25, 2022, 11:29 AM UTC

semi-extrinsic wrote: post #57

One of my favorite tricks is to combine functions that get called recursively (ideally four-five calls before you get back to the first one in the circle) with objects that are gradually unpacked such that their identically named member functions do subtly different things.

Hey we work together I see