• by komon on 1/18/2021, 7:00:30 AM

    You gotta sell everyone involved in the benefits.

    Convince the devs that you're not just giving them make-work to do, get the execs to buy in on giving you the space to do what must be done.

    Keep the pitch focused, you're not selling them on a rewrite after all, just on better practices.

    A code review process means fewer defects and better ramp up on changes made across the code base.

    A clean codebase is going to make future changes easier, faster, and less buggy. It's also going to help with engineer retention.

    Execs don't really care about fiddly perfectionism or process or even technical debt. So speak their language.

    Engineering can be done on short notice, but running up the pressure is only going to result in a broken product. If you can't get the execs to stop pressuring developers directly, it's a lost cause.

    For the devs, they need automation and clear benefit. If you just tell them to start doing code review it writing tests, the starting friction is going to be too high.

    Instead, give them working PR templates that reduce how much typing they'd have to do. Give them build scripts that test the code cleanly in one step. Plan some mob programming sessions and write some tests together.

    Most importantly, you have to get everyome on the team in a (virtual or otherwise) room and have them choose the standards themselves. You can't mandate things like test coverage percentage targets or code formatting standards without the devs feeling like it was something that they all agreed on.

    Then, make it your personal business to follow up with automation to back it up. Get some plug and play static analysis tools in there to enforce whatever test coverage minimums were agreed on. Build formatting and linting into a pre-commit hook so they never have to think about it. Take as much friction as you can it of it so that even the most pressured dev can see the value in writing some tests for the new feature.

    You have to get them from agreeing to trying it these new processes to getting value out of those processes as quickly as possible.

  • by brudgers on 1/18/2021, 1:59:22 PM

    Make a business case to the business execs. There is not one in your description...slowing down productivity because the code base is "ugly" doesn't cut it. A future where it is hard to change the code only happens if the busines survives and grows to the point where that's a problem...and if the company really grows well, then even a pretty code base will probably get chucked when the new problems that only come with scale dominate. Good luck.