[dpenguin]

Code organization (part of Architecture) matters a lot here. Especially in large code bases. Software is meant to be “soft” or pliable easily. To do that, one should be able to alter a module without having to understand the whole system. If a small task takes too long, there’s a problem with the software architecture or code organization.

[sooheon]

I think GP's "millions of lines of code" references the code that runs all the systems outside of your particular org's architecture.

[dpenguin]

Got it. Better to stick to tried and tested “boring” stuff and actually code small functionality yourself than chasing a thousand line library for trivial stuff.

At work, someone used a 3rd party library to send stats to a server in json format and “standardized” on it. 100s of developers had to now learn this new library and it’s APIs and one bug caused everyone a bit of hassle. It probably made the original dev’s job just a little easy but made it a bit hard for everyone else. These things do happen. The point is to learn from this and make better decisions over time, not give up and say we can’t get better. Trying to provide an estimate forces you to think more carefully and become better over time.

[sooheon]

A poor library choice or two is not even 1% of the systemic dependencies any system has if it's working at a reasonable level of abstraction.

> "not give up and say we can’t get better"

Not sure why you feel the need to state this straw man? That is not my opinion, nor do I think it is the GP's.

[dpenguin]

It was not a counter argument to anything per se. Just pointing out that even with episodes of failed estimates, there is reason to continue estimating.