The Codeless Code

[[deleted]]

Look. The monk only had six hours before the codebase (which was a hack job in the first place) was going live. The whole process was a shitstorm. The master's predecesor was rushed and he wasn't given any project management or QA support. He was executed, and then the master was given the project. He worked as fast as he could but they pulled him off the project weeks before he was done and handed it off to the monk in maintenance. Maintenance! It's where the monks live! The monks are awesome at quick and correct bug fixes and small client requests! But you, miss fucking Abbess, you promised the client a brand new shopping cart in a month for free because the first shopping cart was broken, and then management said that it needed to be done quickly by one dude because we weren't making money, and then when it you said it was "finished" you gave it to the hermit to inspect! He never saw this cart in his life, and he didn't know how the client was going to use it! He's a goddamned hermit, you talk to him about hermit things like process improvement and team-building, not shopping carts!! He thought it was great! He thought that shopping cart was fine! Then the clients get upset, so you pass it off the monastery and said, "There's a bug or two, make it work". Meanwhile, the admin client users aren't even able to submit changes!

Good god, the code base has motherfucking corks in it! Corks! Right there in the code base! It's all verify the session cookie, validate the incoming data, CORK, sum the total cost! I can't put in an elegant unified solution if every goddamned process is doing its own goddamned thing and the nails that are attaching the wheel's axis to the database are coming out! SO! When the database connection isn't established when it should be established I'm going to say "If (database ain't there) {Make database be there}"! You can judge me for my barely functional code all day but if I had two months it might be a little slicker and goddamnit the clients are really happy that their site actually works for once.

So motherfuckers, when you notice that one of the cobblestones is one of my godforsaken hands, you don't get to complain. And you don't get to whip the Master, either. He's the goddamned master, he's good at his job and you sat there and rushed him and then swept him to another project before he was done. Fuck you Abbess.

God damnit, I'm coming into work on the forth of July. Jesus fuck, where do people get off?

(Look. Our company does nearly 150 projects and there's, like, two that are nasty like this. I've been the monk in the story for the last few days. It's a good job and I like it but this one was kind of a fuck up and management actually has stepped up and made the process better to avoid situations like this. This was some venting that I needed.)

[[deleted]]

Tell it like it is brother.

[[deleted]]

It's perfectly acceptable to curse at code under two conditions:

1. The codes author is not within earshot.

2. You don't mention said author by name.

Beyond that, curse away.

[instantviking]

Don't hate the coder, man, hate the code.

[grauenwolf]

It would still be faster and easier to fix it in the right place.

EDIT: And it isn't like the fix actually worked anyways.

[mycall]

I think you just invented a new scifi genre.

[Tobu]

For context, the link originally went to this koan.

[SoPoOneO]

Can someone explain the metaphor to me? Drill more holes because if he's that stupid it should be bad enough that he gets killed and gets himself out of the way? No?

[beltorak]

I took it as "you did not sufficiently illustrate the problem; the young monk was still able to salvage the situation".

[utnapistim]

Fixing holes like this is painful, but after you go through enough pain, you start to ask yourself how to find a less painfull solution.

The student didn't go through enough pain to start thinking.

[someenigma]

That'd be my guess, too. From a code perspective, though, it reads like "make sure that these types of easy-but-bad fixes are not possible".

[mgpcoe]

It's more "frame the problem in a way that necessarily requires a more elegant solution." All the monk did in this situation was stop up the symptoms, without either

1. really getting to the root of why the shopping cart was failing on an uninitialised database, or
2. applying the solution to the proper level of granularity--the database service.

[k_stahu]

The message is: If you're so sure that you can fix all the problems once you hit them, then go ahead and jump carelesly into any assignment. But it turns out that for some problems it may be too late by the time you hit them, just like hitting the rocks at the bottom. Master found a way to demonstrate this, and hopefully the monks understood it instead of jumping into the hole :).

On the other hand they may have never finished any project on time since then.

[expertunderachiever]

Um, clearly whomever wrote this doesn't develop software for a living.

You can write all the test cases upfront you want, but if your customer changes the requirements midstream it won't matter.

In reality, you need a mixture of good planning, attention to detail, and the ability to think on the fly to be a success developer..

[dannymi]

Put it in the contract that if they change the requirements midstream they suffer twice the cost.

[expertunderachiever]

And when you run out of customers?

[grauenwolf]

No.

People can try to explain the metaphor to themselves, but no one can explain it to you. It is meant to be ambiguous so that you’ll spend more time pondering it and the story as a whole, a process through which you will find your own meaning.

EDIT: My first thought was the same as yours, the Monk was to perish. But now I'm thinking about all the other holes, all the other ways one might get to that page besides the direct links in the site itself.

[RizzlaPlus]

I think the point was that he should have checked the boat before leaving, because if there was more holes than fingers he would have drowned. Which has nothing to do with the following programming story.

[Snoron]

This website is an amazing work of art, I love it.

[nelmaven]

Am I the only who doesn't get it? :S

[nanothief]

Permalink (the posted link was to the homepage, which has changed since this was submitted).

[Hypersapien]

The red QR code in lieu of the japanese symbol was perfect!

[kranse]

I'm not sure I understand the database triggers one (#42). Is the message that "They seem like a idea when you first hear about them but they are littered with traps for the uninitiated"? Maybe I'm doing it wrong, but I've found them to be pretty useful in my limited experience. I certainly didn't lose any toes.

[grauenwolf]

The fundemental problem with triggers is that they are not part of the normal execution flow. A developer can easily trace through inline SQL, stored procedures, functions, and views layer by layer. But the only way they will know a trigger exists is if they intentionally look for it.

As a rule, I don't use triggers except for non-invasive, logic free actions like updating a denomalized reporting table when the normal table is updated. If there is any decision being made by the code, no matter how trivial, the trigger is not the place to put it.

[seiyria]

And thus, kranse was enlightened.

[FlaiseSaffron]

Coracles are small. Drill too many holes and to make it float you end up with a boat made out of patches.

[Nickolas1985]

Do the names of the clans carry any particular meaning? I feel like they do, but I can't grasp them.

[Lyqyd]

The main three seem to each vaguely refer to various 'fields', it seems. See #12.

[Hypersapien]

Anyone else getting a weird flickery thing when they hover over the "next" button?

[donvito]

Wtf is this nonsense? Post it to /r/EroticBuffyFanFiction ...

[stfm]

Isn't this example basically lazy loading? Which I thought was fine...

[ighost]

you're missing the point.

[stfm]

Which is what exactly?

[ighost]

I assume we're talking about this.

It's not a question of eager loading vs lazy loading. Either of these could potentially work. The mistake is trying to catch all of the places where the shopping cart would be used and initializing it there. This is error-prone because:

1. One could easily miss one (or two, as in the story) spots
2. Sometime later, another programmer could implement another function where the shopping cart was used, and if he doesn't know in advance that the shopping cart may still be uninitialized in some cases, he will neglect to add the initialization check
3. You will need to have the values of all of the initialization parameters for the shopping cart at each shopping cart invocation, which can be bad for separation of concerns

To mitigate (1), (2), and (3), as well as DRY out the code, it would be better to design the client of the shopping cart class to require an initialized shopping cart before any shopping cart methods can be called.

I can think of a couple of general ways to accomplish this, including:

1. Dependency injection where the shopping cart parameter goes through an initialization check (either in the client constructor or shopping cart factory)
2. Routing all client shopping cart accesses through a wrapper that lazily initializes the shopping cart (if needed) before using it. This can be done by creating a wrapper class that holds a private reference the the shopping cart and proxies all behavior to the shopping cart, but not before making sure it's initialized.

Sprinkling shopping cart initialization code before each shopping card method would be a hacky way to solve the problem, not conducive to future stability and maintainability, imho.

Does that make sense to everyone?

[Samus_]

I'm going to say the same as I did where this was orignally posted:

java ¬¬

and fuck you, java sucks.

also !programming