[debacle]

In my experience, this was likely entirely driven by one person, my guess would be two levels above the author in the org chart. It's sometimes frighteningly easy to convince business leaders that the dev teams are wasting a ton of time, doing the wrong thing, etc. It's even easier when that direction is coming from a consultant (might not be in this case, but I've seen it happen a few times).

Someone who was supposed to be advocating for their team (maybe the author's boss) wasn't, or was being out-advocated by others, and that led to breakdowns. As a manager, I keep a lot of KPIs and do a lot of postmortems (lean), because you need to be able to counter the gut feeling of "development should be faster."

[hinkley]

I've worked at plenty of places where the dev team was wasting their time, doing the wrong thing. You know who we blamed?

Someone two, three levels above us in the org chart.

[btbuildem]

Did that have any effect? Usually people lower in the org chart have less power than those closer to the root, so I'd expect that complaint to be filed away an no-op'ed on.

[pjerem]

I think it’s different for developers. They know that for other people (even for their hierarchy), they are just doing mystical, abstract "work". In my experience, a lot of developers learn to use this to convince themselves and everyone else above them that they HAVE TO do this full refactoring.

imo, this all comes down to the fact that management is still not able to assess the quality (or even the real nature) of developers work. Of course there are managers who are developers but they themselves speak a very different language with the people above them so it’s really easy for them to convince upper management that they (and their team) are doing the good thing.

I’m not blaming anyone here, we are just workers that are a little less abused than the others. But as a developer who is not really fond of tinkering things (at work), I’ve seen things. This industry never stopped to promote developers based on their LoC count regardless of the business efficiency.

In fact I’ve seen people become millionaires because they wrote extremely generic frameworks (akin to netcore, angular or bootstrap but "invented here") which then became the company’s SPOF once they left. Good for them, but I’m still amazed that upper management never realizes when they are paying someone during 4 or 5 full time years because he didn’t like Bootstrap (won’t blame him) and convinced his hierarchy that we needed to develop our own competitor.

Oh and don’t read any jealousy in my comment, the only bitterness I have is against myself, because at the end of the day, if management doesn’t care about the real output, they deserve to be served a $500k brand new css framework.

[bruce511]

Oh this is such a hard path to tread, and again the same time hard to know without hindsight what the right path is.

I come across lots of situations, with legitimately bright developers, who have replaced a standard subsystem either a home-grown one, usually for performance reasons.

In that moment in time, in that context, the general solution was less performant or had an ugly bug, or whatever, so they replaced it with something designed for the one specific context.

But then the context changed, and now heres this bastard-child that's been narrowly designed, and optimised for performance (so hard to maintain or change. ). And the developer is somwhere else.

But equally I've spent a career writing the "new standard solution", which of course started out as an alternative to "the standard solution". And in our context that -has- made a huge difference. So it eould by hypocritical if me to say "stay inside the box".

If you do need to get outside the box, I would give some advice though.

A) documentation. Nobody likes doing this, but this is the most important part. If it's not documented properly, it doesn't exist. And just the act of documentation will show you where the design is deficient.

B) write your code as clean as you can. Make it easy to follow. Make it easy to read. Try not yo be clever and where you are clever don't skimp on the comments. You'll thank yourself for this later.

C) as much as possible try and build for the general case, not the one in front of you. The more useful this vote is the more it'll be used. The more it's used, the easier it is to identify flaws.

In summary - stay on the main road. But if you do need to forge your own path, make sure it's done properly, not some single lane gravel dirt thing.

[pjerem]

At the end of the day, I do agree with you. My point wasn’t against the developers who acted like this and if they were right or wrong to do so. My point was about the fact that the knowledge barrier between developers ("R&D") and the upper management is frequently so tight that nobody is ever questioning those choices because let aside the "story points" the damn thing is costing, nobody understands what this is about and if it is necessary or not.

However, that’s just my personal experience, it’s possible that I’ve only seen the wrong kind of companies.

[pdimitar]

Sadly the wrong kind of companies are the majority. Which is to say, my experience mirrors yours.

[hinkley]

For several bosses, this scenario you describe has fallen under the concept of 'kill your heroes'.

Sometimes the person really is brilliant and you should do anything to keep them. But if it's because they're the only one who understands their code, then they are a liability.

[pdimitar]

Is it really so difficult to train other people in the code?

Or is the hero deliberately sabotaging such efforts to maintain scarcity, and thus their higher value?

[hinkley]

Catharsis, most of the time.

If you a middle manager that's really, really good at upmanagement, they can make things a little better.