Timeline for How to handle accountability for mistakes in a team as a manager?
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 4, 2023 at 17:20 | comment | added | Yakk | @neonblitzer I mean, given a large enough code base to developer ratio, it can take a LOT longer than a year to automated test even the majority of it. But yes, writing an easily testable code base will get you a lower long-term regression and bug rate than not doing so at the same development effort. Initially you'll get some features slower (which is why "throw away" code still has lots of value) and not notice the bug problem, so even here you need to have good policies (enforcing it) or short-term metrics will favour people who don't, and buy-in from the bean counters. | |
| Apr 4, 2023 at 17:15 | comment | added | neonblitzer | Fair enough – what you're saying is that technical debt doubles the cost of a code base. Deciding to write high quality code and automated tests isn't expensive in any timeframe longer than half a year, but the fact that OP's company hasn't done that makes fixing the issue later on expensive. | |
| Apr 2, 2023 at 23:10 | comment | added | Yakk | @neonblitzer Oh sure! Once you have gotten the code written, later changes are easier. But adding full on automated testing is a lot of work! And guess what happens if you skip adding automated tests for a new feature later on? That ... is again cheaper. But at each point, the easy and cheap route is "don't test it", which means you need to have a longer term than a few weeks horizon to do the extra work. Have you ever taken a large, legacy code base and got it up to a fully automated testing state? It is an insanely huge endeavor. | |
| Apr 2, 2023 at 22:05 | comment | added | neonblitzer | "Serious and effective automated testing way more than doubles the cost of a code base." "Creating changes that don't break effective automated tests significantly more work than making a cowboy change that just works." I think, based on my experience, that these claims are unfounded. To put it mildly. Especially the latter quote. Quality is speed. When you have good automated tests in place, making a change is faster since worrying about breaking things is handled by the computer, not the programmer. That's the point of automation. I'm kinda morbidly curious what has led you to these views. | |
| Apr 1, 2023 at 19:33 | history | answered | Yakk | CC BY-SA 4.0 |