3 ms·
> I don't think developers should even necessarily explain that this is what they are doing, because then they have to ask permission to do it. In my experienc
by freetime2 7y ago
> I don't think developers should even necessarily explain that this is what they are doing, because then they have to ask permission to do it.
In my experience, it pays to be open with product managers and QA about what you are working on, how you are implementing it, what the risks and benefits are, etc. For example, it helps QA to focus their testing efforts on the areas that are most likely to be broken by a refactor. And having some understanding of how an app is built and where the problem points in the code lie helps product managers to develop a sense of how much effort a certain change might take, and reduces the chance that they will be surprised by some behavior in the app as the result of a change.
And if someone on the team wants to question me about the cost/benefits of a certain refactor and discuss alternatives, I think that is totally fair game. Same way that if I want to ask a question about the cost/benefits of a new feature and discuss alternatives, I feel empowered to do so. It's not about asking permission so much as it is about developing a shared understanding of the costs and benefits of the decisions that we make, and working together to optimize them.
- andrewstuart 7y agoYou make good points and I tend to agree with you. On the other hand I remember on some projects there being real (HUGE) pushback from the client about doing anything that wasn't implementing features exactly as they define and "are paying for". As soon as you declare that you are doing something "optional", it gets political, people start talking about it, it escalates to project manager, their bosses boss etc and the shitfight starts. Ugh.
- freetime2 7y agoYup I guess what I was describing was more of an ideal software development environment, but fully recognize that there are many cases where being too transparent can cause issues. Hopefully those projects paid well, at least, to make up for all the frustration. :)
- TeMPOraL 7y agoThe best general strategy may be simply "tit for tat". Try going the high road first; if you see positive reaction, keep at it; if you see dysfunctional reaction (like parent here had), revert to doing it without asking for permission.
- gregknicholson 7y ago> implementing features exactly as they define and "are paying for". The reason they're paying so much for it is that you didn't do the refactoring last time. Every time they refuse a refactor, all their future costs genuinely go up. If they ask why the refactor is needed, why you didn't do it properly first time round: “You're constantly refining your business processes to satisfy ever-changing business needs; that's what I need to do to the code.”