[noxToken]

So what's the alternative to lying for what you hope is the greater good?

This is the advice that I give my colleagues who, after exhausting all other methods, try to squash technical debt before a 1 hour task becomes a 5 hour task. Leaving the job doesn't solve the problem (though it may save your sanity). In fact it might make it worse, because the leaving person is likely taking tacit knowledge with them.

I'm not saying that lying is preferred, but what else can one do?

[crdoconnor]

You need to flip the script on the problem. It's no longer a technical problem, it's a management problem.

Management problems are solved with spreadsheets that show concrete numbers going up or down.

At the beginning of each sprint ask the manager what % of time developers should spend fixing quality issues on each story after the story is complete. 0%? 30%? 50%? Track it. Graph it.

At the end of the sprint ask developers "how do you feel about the quality of the code base this sprint? [ 0 dangerously unstable --- 100 - clean and perfect ]. Track it and graph it.

Track what % of stories in the sprint are "code quality" stories (e.g. upgrade node). Create a graph showing four consecutive sprints with 0% time allocated to code quality stories.

After about 4 sprints of this, provided you were reasonably open and transparent about what you were doing, you'll probably have a slightly freaked out product manager who is newly cognizant of the need to properly allocate time to "quality".

If it turns out he's an idiot who ignored your little game, well, you've amassed documentation necessary to make his bosses start considering his termination and replacement.

Don't fuck around with this stuff though - you can invite all sorts of problems if you're not careful with this approach. Assume everybody is honest and has good intent until proven otherwise.

[jrochkind1]

I have not completely figured out what to do, but I'll say that if you leave because the organization is not interested in producing quality code and you don't want to work for such an organization, and they were unwilling to give you time (ie money) to produce quality and maintainable code -- the problems they have maintaining the code after you leave, having made efforts to educate/convince them of this fact and failing, _are not your fault_ and _not your problem_.

The tacit knowledge you take with you, when they were not willing to give you enough time to share/document this knowledge, or produce code that was more transparent, despite your efforts to tell them the consequences -- are _not_ your problem. Don't get Stockholm syndrome.

I realized at one job that I kept busting my ass to cover up for management failures (that I wouldn't get credit for saving them from)... they would NEVER LEARN. I was enabling terrible management and a toxic environment. They didn't even _realize_ I was saving them from themselves (and if I'm wrong and they were right and I wasn't, all the more fine it was for me to leave).

[justin_oaks]

I just left a job where I knew that management would never learn. That was my primary reason for leaving. All other problems could have been fixed IF they would listen to the employees and/or learn from their own mistakes.

Alas, it was not meant to be. I feel like I was an enabler because there were a lot of things that I held together despite not receiving any support from management.

[s73v3r_]

If the organization doesn't care about code quality, then they don't deserve talented engineers with domain knowledge.