3 ms·
Early in my career, I worked on a team of 6 in a small division (acquired startup). We really cared about DevEx and built a set of tooling that allowed us to bu
by teeray 2y ago
Early in my career, I worked on a team of 6 in a small division (acquired startup). We really cared about DevEx and built a set of tooling that allowed us to build and ship insanely fast (while still maintaining a solid CI and PM approval process for every feature). We astonished the rest of the Megacorp that was enmired in Byzantine process-what took them weeks took us hours. Sure, we shipped a bug from time to time—it was trivial to rollback, fix, and push. For them, shipping a bug was disastrous—it took so long to roll out fixes and rolling back was impossible. So naturally, the answer is “more verification.” They start chasing after the impossible dream of “0 bugs shipped.” In this case, a bad DevEx begets worse DevEx, and a software lifecycle that is trapped in a tar pit.
- drewcoo 2y agoYes! Unless you plan to go fast, you'll just keep getting slower and slower. And slow feedback is bad feedback. I see lots of people adding slow tests to already-slow test suites and thinking they're helping. They are not helping. They're only making the problem worse. Those are often the same shops that measure "test coverage" in number of test cases.