Problems come up every day, for everyone. Development teams are no exception. Those concerns are raised by a variety of stakeholders - customers, executives, and colleagues.
Where I've seen trouble arise is when the immediate reaction by a decision maker is to treat the symptom of a problem.
Where I've seen trouble arise is when the immediate reaction by a decision maker is to treat the symptom of a problem.
- This design concept has shortcomings? Scrap the design and start over.
- Production instability causing customer complains? Freeze production.
- Code coverage for a particular microservice is low? Just write more unit tests.
The solutions to these concerns are probably not treating the underlying problem(s) that are harder to see. Efficient and effective leadership can take these concerns and go one step further. They ask "why?".
- Why is this design untenable? Are we hitting limitations of other services that need to be re-worked? Does a re-prioritization of work need to take place?
- Why is production unstable? Is it out of our control? Do we need to adjust a deploy pipeline?
- Why is the code coverage for an individual tool so low? Is the code not unit-testable? Do other types of testing like integration or regression testing cover this code? How can we work with the developers to provide tools to ensure new code introduced into the service is unit testable?
Even harder to do is accept that there is no great solution to some problems. Every decision has tradeoffs. If every problem had a perfect solution, we would never have any problems.
Sometimes you must stand your ground. Solutions that only treat the symptom often bring short-term relief, but long-term baggage. It's critical to try and understand what the actual cause of a problem is, and that often starts with asking: "why?"