> Software engineers are not always good at prioritizing the business value side of their work so they aren't trusted there.
This.
Software engineers are focused on the implementation side of things and how today's work will impact their work in the future. Yet, sometimes a quick and dirty solution that takes close to nothing to implement is more than enough to put a functionality in production. Sure, the whole thing will need to be scrapped in the near future when rewriting the feature to meet all design requirements, naturally the quick and dirty solution underperforms, and of course implementing it properly will take 3 or 5x the time. Isn't it obvious that the team is wasting it's time by implementing a quick and dirty solution?
Yet, the quick and dirty feature does shorten the time to market to a fraction of what it would otherwise take to implement properly, and perhaps that is good enough for the project for the time being.
It's for this reason that I've often tried to get the business side to give opinions on how shoddy/quickly they'd like the feature to be done. Curiously a lot of the time they appear very reluctant to do so. It's probably CYA kicking in maybe... many managers don't like to say "do a shoddy job" if it ends up biting them in the ass later... they'd often rather just hint and exert unspoken pressure to rush it out and then deny everything later when the CEO starts asking questions a bug that fucked everything up.
There are exceptions, of course, and I'm pretty happy to have worked with them, but in general about 90% of managers I've worked with have resisted my attempts to get them to be explicit about the level of quality that they want.
Quality is so ridiculously subjective that I'm not sure a non-technical manager should approach the question, and a technical manager should refuse a direct answer and steer the conversation towards structure and deliverables.
% of time spent on refactoring is completely objective. Whether that results in quality is another matter, but it's a dial that a product manager has control over that (usually) has direct impact on the quality of the end product.
My take is that product managers care mostly about what functionalities were delivered and if the requirements are met. If the development teams deliver a quick and dirty solution and it meets some requirements then they check the requirement as delivered, and that's it.
When this happens then the devteam's negotiating position changes completely, because they are no longer arguing about how to allocate resources to deliver a functionality and instead they are asking to waste time rewriting something that was was already delivered and is supposed to be up and running.
This.
Software engineers are focused on the implementation side of things and how today's work will impact their work in the future. Yet, sometimes a quick and dirty solution that takes close to nothing to implement is more than enough to put a functionality in production. Sure, the whole thing will need to be scrapped in the near future when rewriting the feature to meet all design requirements, naturally the quick and dirty solution underperforms, and of course implementing it properly will take 3 or 5x the time. Isn't it obvious that the team is wasting it's time by implementing a quick and dirty solution?
Yet, the quick and dirty feature does shorten the time to market to a fraction of what it would otherwise take to implement properly, and perhaps that is good enough for the project for the time being.
reply