While I'd like to say I don't do hacks, I sadly cannot (while being honest) Given the poor quality of some of my employer's codebase, doing a proper fix instead of a hack could sometimes inflate the scope of work beyond reason, and leave the possibility of introducing more bugs. Sometimes it is best to leave a little hack here and there in order to avoid going down some really messy rabbit holes, especially when there are deadlines to consider!
That sounds about right to me. I can't recall a significant project I've worked on that didn't have one hack in it. Major projects are typically going to have one or two. After that, it's time for a rewrite.
That's what //HACK: is for! VStudio will even give you the list of these comments in your project.
I would prefer to fix the problem properly than leave a workaround. If time is not permitting then I would make sure I properly commented the workaround so that the next person to come across it understood why it was there.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
If that piece of code is only readable by the author, it means it becomes a liability. That's what I would consider a hack and it should not stay. It's not only my professional reputation that is on the line but more importantly it should be about ethics and courtesy that we all should abide to so we make the next guy's life better and the legacy of your work safely replaceable or refactored.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
If I create a hack in order to get it to work, I add a comment above and below to indicate that it is a hack and the date. I would love to fix it in the future, but the reason for the hack is that I did not have the time to explore a better way to do what needed to be done. Net result: I will probably NEVER have the time to fix it, unless it breaks.
When it breaks, I use the date to look up the original problem, my research into a better way, my reasoning and so forth in my notebook. (I keep a daily journal of everything I do at work. It is a great CYA hack. )
Agree. This was always my approach, write up a ticket explaining what we were trying to accomplish, and the reasons why we chose to do a hack. Include at least some details about the path we'd go if we were to implement the 'proper' solution. Put it in the backlog in whatever change tracking system is being used.
Where, of course, it's ignored for eternity. Sigh.