On Mon, Sep 09, 2019 at 01:01:07PM +0100, James Bottomley wrote:
> On Mon, 2019-09-09 at 12:53 +0100, Mark Brown wrote:

> > That's often a corporate problem as well, if the company has a
> > big investment in whatever approach or codebase they have they
> > may not want to spend the time on substantial rework.  Often it
> > seems fairly clear that the people doing the upstreaming have
> > inherited something from other engineers rather than having done
> > the design and original implementation themselves.  In my more
> > embedded experience I'd say that the corporate investment is a
> > more common issue than developers.

> Actually, I find the inherited code part easier because usually the
> person pushing it isn't wedded to someone else's design and is happier
> to do a rework because it makes it more their code.  My biggest problem
> has been with the original author trying to push their design as the
> only possible way and then trying to bring corporate pressure to bear
> when it became clear this wouldn't be accepted.

Yeah, both are issues - the corporate one is usually basically a
"we've decided we need to get this done in X timeframe" or a "we
have a massive investment in testing that we couldn't possibly
repeat without which any other solution much worse" so it goes
beyond the individual developer.  The developers might be happy
to do the reworks (they sometimes thank me offline for saying
what they've been saying internally already) but are being told
to push the existing code.

> > I'm not sure I have any particularly bright ideas other than
> > being clear with people about what the issues are and asking for
> > clearer explanations of what's being done and why it's different
> > to everything else.

> Trying to explain that it's a maintenance and consistency issue more
> than anything else does seem to help.

Those problems do tend to be a bit easier to get over to the
management people.