/***********************************
/* a temporary hack, fix it later *
***********************************/

That was 7 years ago. I mean it was last edited 7 years ago when a temporary hack was created. It is now a permanent solution as nobody know what we are supposed to fix

.... Nothing is more permanent than a temporary fix. Not even clean refactored and tested code.

Agree, there is no temporary hacks, there is only hacks

Temporary solutions often become permanent solutions. In one of the libraries i have to work with there are several workarounds in place, for years.

'Temporary' and 'Hack' don't fit in the same sentence

@arshcaptano why?!

For example, Like if you have a server crashing again and again due to long logs and can't decide where the problem is, you could have a thing to delete logs regularly.

This is a temporary hack. You need to find the problem later... And find why does long logs crash your sever.

Maybe you'll not get a thing of this due to my shit English....

Hope you get it.

Edit: typo

This is my motto. Whenever I hear someone say:
'oh I will just put this hack in for now and come back and clean later.'

'There is nothing more permanent than a temporary fix.'

As long as it works!

@gitlog in most cases, the "temporary hack" will work. And if it works, you don't touch it. If you do, then you'll have to come up with another "temporary hack".

Most cases.

You English is good by the way.

Its bad that this happens, its worse when your architect thinks its appropriate.

Last place I worked for, we were setting up new rules / processes. We were discussing rules to turn on in our new linter. I wanted to turn on one that would display warnings for various kinds of // FIX LATER, // TEMP, // HACK, // TODO: etc.

He disagreed and refused saying it takes too long to open a ticket or write it down. Doing it this way we can code quicker and just "search for them later" ... yeah cause that will never fail.

I wouldn't recommend that shit stain to build a paper bag.

@practiseSafeHex true!!
But entropy always tends to increase..
Also, sometimes temporary fix are inevitable, but you need to atleast write a good documentation of that before forgetting the shit or resigning

@gitlog Oh I have no problem with the idea of throwing in something temporary. If its black Friday and the server is down, yeah i'm not going to add something to the backlog and wait for a review meeting / planning poker.

But every time I throw something like that in, I find time to open a ticket later saying like: "it was a temp fix to overcome xyz, think a better solution would be abc, don't have the time to build / test right now". So that its in everyones face and can't be forgotten about. So many files and classes are working in the background and rarely touched, lost hacks are bound to happen.

Yes, even developers of the Apollo 11 software had to throw some hacks in there :)

Yeh temp hacks tend to grow in to the application and just setlle in there forever...

At my job lately, we have been getting more and more in to Ci, and one of the things we did is scanning the code for TO-DO, FIXME,... And variants of those... At the moment they don't throw errors, unless there's more than x (exact amount various from project to project) but we get an overview of how many there are and where they are.

What I'm trying to do now is that once every x weeks, one of us goes through the list, and creates tickets for these so they'll be in our backlog

Just to bring this up again. Having trouble logging into an app I am suppose to be working on with another dev. Debugging and found this:

// TODO: Temporary Optional because the API is not working properly

... i'm not happy for so many reasons