5 ms·

You care because most often it is your problem still. For example, when you know with facts that a given technology is less error prone than another. But the ot

You care because most often it is your problem still. For example, when you know with facts that a given technology is less error prone than another. But the other party still picks the worse one. When a year down the line shit hit the fan, it usually ends up back on you. Because you are the only one with enough knowledge and expertise to even understand the mess they put themselves in.

Supermancho 4y ago
I'm certainly in the defensively argumentative crowd. Eventually, as someone who likes doing this work, a single/series ends up being a massive albatross on the team until the project dies or someone steps up. That's often me, because I don't want to be miserable. Sometimes the choices are so monumentally bad, there is no way to fix it. It's just a miserable death march.
- pdimitar 4y ago
  Yeah, I am very much the same (if I read you correctly): I get it that maintenance is more important than "devs playing with new shiny toys" -- a saying over which I slammed a manager in a high-level meeting and I didn't flinch doing it; I'd do it again! -- BUT sometimes it's painfully obvious, usually months later, that using tech X or Y just makes it that much harder to maintain the software. There are points at which difficult decisions have to be made. It's a shame most managers / CTOs / VPs of engineering are so cowardly and idolize not being spotted by upper management for having a few hiccups in their projects, over any other concerns. I have no patience for their political in-fighting in companies so I usually arrive at a contract, beat a bunch of things into shape, reduce test failures, simplify deployment, introduce a few conventions (and document them) that make it easy to change code, make 1-2 high profile and very requested features and then usually end up leaving 6-9 months in -- simply because I start getting included in the political games. At that point I am like "hell no" and just move on.
hutzlibu 4y ago
"For example, when you know with facts that a given technology is less error prone than another." I am sorry, but this sounds a bit like you are in the fanatics camp. It always depends on what you want to build and what is the given skillset of the people and the avaiable time. Bad teams will mess up even with the best technology and good teams can deliver with outdated imperfect languages. And good teams can disintegrate over religious tech wars ..
- pdimitar 4y ago
  This is always down to context -- so please don't generalize somebody as a fanatic. Many times during my work it has become apparent that (some examples follow): 1. We constantly introduce bugs due to the dynamism of the language we use. We had in-house devs that could have rewritten a few very small services (think 20-ish endpoints, we're not talking rewriting a mastodon with 500+ here) in a static strong typed language. Alas, almost everyone mercilessly shot that effort down even though it was right in everyone's faces how that will reduce the upkeep of bugs and maintenance with at least 50%, if not 80%. 2. Somebody figured it's a genius idea not to follow the conventions of a certain web framework. At least 15 people came and left over the course of a year and they all struggled hard to adapt. It's not because they're stupid; it's because you have a well-working schemata in your head that you have to undo many times over just so you can work in a single team / company. Eventually all these people figured it's not worth it and I can relate to them (even though I and several others had no difficulty adapting). 3. At one team somebody decided that the in-VM cache implementation is buggy -- even though it absolutely is not because otherwise even stuff like WhatsApp wouldn't function well, btw! -- and they said "hey, let's not only use Redis for cache" (which is fine) "...but also let's use it for mutexes and semaphores that span several computers" (lol). Only after me and another senior threatened to leave did management finally budge and they left us to rewrite the thing which resulted in smaller Dockerfiles, simplified deployment, inadvertent fixing of 20-30 intermittently failing integration tests, and reduction of coding lines by about 1200 (in a project with 11500-ish coding lines so 10% decrease). Then we still left afterwards btw, both of us together, because management figured we're some kind of a threat and sabotaged us at every turn afterwards. Petty small humans ignoring feedback from users and other dev departments telling them we did the right thing. Those I'd call fanatics. Point is, people want one thing to "just work" and never touch it again, and then proceed to use fluff language to disguise this like it's anything else BUT that. Some of us see through that BS. Yes, error-prone tech exists. Yes, projects get improved by the removal of those. And I truly believe all this mindset of "you can do your project in ANY tech and it won't make a difference" seriously has to stop. This has been demonstrably false throughout most of computing's history.

Supermancho 4y ago

I'm certainly in the defensively argumentative crowd. Eventually, as someone who likes doing this work, a single/series ends up being a massive albatross on the team until the project dies or someone steps up. That's often me, because I don't want to be miserable. Sometimes the choices are so monumentally bad, there is no way to fix it. It's just a miserable death march.

pdimitar 4y ago
Yeah, I am very much the same (if I read you correctly): I get it that maintenance is more important than "devs playing with new shiny toys" -- a saying over which I slammed a manager in a high-level meeting and I didn't flinch doing it; I'd do it again! -- BUT sometimes it's painfully obvious, usually months later, that using tech X or Y just makes it that much harder to maintain the software. There are points at which difficult decisions have to be made. It's a shame most managers / CTOs / VPs of engineering are so cowardly and idolize not being spotted by upper management for having a few hiccups in their projects, over any other concerns. I have no patience for their political in-fighting in companies so I usually arrive at a contract, beat a bunch of things into shape, reduce test failures, simplify deployment, introduce a few conventions (and document them) that make it easy to change code, make 1-2 high profile and very requested features and then usually end up leaving 6-9 months in -- simply because I start getting included in the political games. At that point I am like "hell no" and just move on.

hutzlibu 4y ago

"For example, when you know with facts that a given technology is less error prone than another." I am sorry, but this sounds a bit like you are in the fanatics camp. It always depends on what you want to build and what is the given skillset of the people and the avaiable time. Bad teams will mess up even with the best technology and good teams can deliver with outdated imperfect languages. And good teams can disintegrate over religious tech wars ..

pdimitar 4y ago
This is always down to context -- so please don't generalize somebody as a fanatic. Many times during my work it has become apparent that (some examples follow): 1. We constantly introduce bugs due to the dynamism of the language we use. We had in-house devs that could have rewritten a few very small services (think 20-ish endpoints, we're not talking rewriting a mastodon with 500+ here) in a static strong typed language. Alas, almost everyone mercilessly shot that effort down even though it was right in everyone's faces how that will reduce the upkeep of bugs and maintenance with at least 50%, if not 80%. 2. Somebody figured it's a genius idea not to follow the conventions of a certain web framework. At least 15 people came and left over the course of a year and they all struggled hard to adapt. It's not because they're stupid; it's because you have a well-working schemata in your head that you have to undo many times over just so you can work in a single team / company. Eventually all these people figured it's not worth it and I can relate to them (even though I and several others had no difficulty adapting). 3. At one team somebody decided that the in-VM cache implementation is buggy -- even though it absolutely is not because otherwise even stuff like WhatsApp wouldn't function well, btw! -- and they said "hey, let's not only use Redis for cache" (which is fine) "...but also let's use it for mutexes and semaphores that span several computers" (lol). Only after me and another senior threatened to leave did management finally budge and they left us to rewrite the thing which resulted in smaller Dockerfiles, simplified deployment, inadvertent fixing of 20-30 intermittently failing integration tests, and reduction of coding lines by about 1200 (in a project with 11500-ish coding lines so 10% decrease). Then we still left afterwards btw, both of us together, because management figured we're some kind of a threat and sabotaged us at every turn afterwards. Petty small humans ignoring feedback from users and other dev departments telling them we did the right thing. Those I'd call fanatics. Point is, people want one thing to "just work" and never touch it again, and then proceed to use fluff language to disguise this like it's anything else BUT that. Some of us see through that BS. Yes, error-prone tech exists. Yes, projects get improved by the removal of those. And I truly believe all this mindset of "you can do your project in ANY tech and it won't make a difference" seriously has to stop. This has been demonstrably false throughout most of computing's history.