3 ms·

And if they keep delivering features in short time frames they will never get a chance to debate quality or elegance in their work. And eventually you will sta

And if they keep delivering features in short time frames they will never get a chance to debate quality or elegance in their work. And eventually you will start hearing them complain about an unmaintainable mess and turnover will probably increase. /s I think you do have to care, on some level, about maintaining code quality and standards. I've worked in feature-factories and it's not a panacea. It doesn't crash and it goes reasonably fast are both features after all that seem to be related to the quality of a code base and the expertise of the team behind it.

jakear 7y ago
One approach is a schedule for when everyone works on debt vs features vs testing. For instance: first week of the iteration is for paying off debt. Second and third are feature work. Fourth is testing (note: not unit testing, real testing. As in everybody chips in to actually play around with the features their colleagues added and provide feedback; also verify that all the bugs that were fixed this iteration didn’t creep back in, or get fixed with a “works on my machine” patch)
partyboat1586 7y ago
Of course there is a balance to be struck. I'm not saying don't plan things out at all. I'm saying limit the time you spend doing it relative to the impact of the decision. That's not always easy to gauge which is where an experienced tech lead comes in to have the final say on what gets done and how long the debate goes on for. A strong tech lead is essential.