Why working with others in code takes longer

13 Jan, 2017

Expanding on why working with other people might take longer:

You might have two choices early on, and be forced to make a decision based on a technical limitation. Later in the project you have a brainwave and can solve that limitation. By now everyone has learned the current (less good structure) and continue writing new code in the worse style
Your tests have probably become coupled to their implementation by now (i.e. probably because they are not separate protocol-based tests based on the unit of a single microservice that couldn't care two hoots about how the service worked at all) so it is no longer possible to fix all the problems in a single sprint cycle (and certainly not as part of a single ticket) so the person in charge either has to admit to the customer agile hasn't worked quite as well as they said it would, or you just plough on and make the problem worse.

Possible solutions:

Tests as a separate codebase interacting only over the protocols of your microservice, written only in response to tickets
Any time you think it would take more than a day to re-write everything from scratch you should down tools immediately and do it.
If anything is hard, do it more often!