
Pushing for engineers to code faster may not equate to faster deliverables - kwansolo
https://www.betbuildgo.com/blog/2019/8/10/myth-of-engineering-velocity
======
tombert
Not exactly the same thing, but about six years ago, I was working for a
startup that did consulting work, and we had a project where I was doing the
frontend JavaScript in AngularJS, one person was doing the backend in Node.js,
and another person was doing the HTML/CSS. This was a pretty logical split,
and there wasn't too much toe-stepping.

One day, my manager decided (and this isn't a joke) that he was going to make
the project finish "three times faster" by adding three times as many people
to it.

This turned out to be a royally idiotic decision; this was a monolithic
application (before microservices became a buzzword), as a result it became
incredibly easy to break everyone else's stuff. Since there was now three
people doing every given thing, and we were now in a time-crunch, and since
the management wasn't terribly good, it became incredibly easy to accidentally
break the whole app without even trying; there was no longer a clear division
on where my part of the code began and ended.

It turned out to be a shitshow; eventually management realized their mistake,
and annoyingly since I was the only one who knew all three parts of the app, I
was the one who had to complete the mess.

~~~
kwansolo
exactly! you can gain so much more efficiency (and improve morale) by just
examining your processes more, before trying to throw more engineers at the
problem. and honestly, it is wasteful and lazy to just pull that trigger
before thinking things through, not to mention all the negative (and honestly
obvious) consequences that you describe.

~~~
tombert
Yeah, the only thing that goes three times faster when you do something like
that is the project budget.

It was a good lesson for me; surprisingly enough it's sort of what made
concurrent algorithms click; specifically why "adding more threads" doesn't
just magically speed up an algorithm.

I do think microservices would have helped in this specific problem; at least
the toe-stepping would have been minimized.

