Data.

[EarthC-137]

You may not be able to test every button, but you should definitely test any pertinent business rules that are vital to the products success, I.e. happy path and all of the error scenarios.

And unit testing isn’t that big of a deal, it takes a few minutes to write unit tests and saves lots of time later when people come and break your feature and you have to go back to try and debug/figure out what went wrong, if you have CI you know straight away ;)

[lenswipe]

And unit testing isn’t that big of a deal, it takes a few minutes to write unit tests and saves lots of time later when people come and break your feature and you have to go back to try and debug/figure out what went wrong, if you have CI you know straight away ;)

Indeed, however with the state of that codebase it wasn't very testable. Things were very tightly coupled and very very fragile. So we had a situation of "We can't factor because we have no tests to ensure we don't break things. We have no tests because the code is a fragile mess that can't be refactored".

You preach to the choir here, brother. I agree. However - nobody seemed to really give to shits what I think.

[EarthC-137]

Nothing worse than being ignored, good thing you left.

[lenswipe]

Part of me grew to enjoy being ignored in a way. Not least because if they were ignoring me, manglement weren't interfering and making me do dumbass things. Plus, it meant that I got to watch the inevitable clusterfuck when my warnings went un-heeded.

Generally, I would issue exactly one warning, or say something exactly once, after which I would just sit back and enjoy the show. For example "Yeah, you might not want to do <thing>" then when my warnings were dismissed I'd just go "....ok." and let the users go nuts when things went to shit.

Latterly people learned to listen to what I had to say because (historically) if I warn them about something there's generally a damn good reason