I've only read half of it, but I liked it a lot. What about you? Did you like it? Why?
> it was [possible] the author probably would have just written a single paragraph in the first place and saved a whole lot of time for everyone.
This does not fit with my experience, even disregarding things like YouTube videos which drag on in order to justify longer ads.
Writing concisely is hard, and often much more time consuming than a lengthy brain dump. It's also tempting to elaborate on every point, however tangential. I have to constantly fight this in my own writing; my desire is to be complete, but really I'm drifting off-topic, diluting my point with irrelevance, making it harder to follow.
Based on the comments above, it seems like the tl;dr missed important nuance, but that isn't always so.
Obviously, a summary can't be an explanation + an argument + history. It has to be the most salient points presented alone. Think about an abstract for a paper: it should tell you enough that you can understand if you should read the paper now, and enough context so that you can remember to read it later if your situation changes.
If you feel like the tl;dr doesn't pay full respects to the article, that's fine but I feel like not many readers will mind.
edit: also thanks for writing that article, it's great.
I can't understand this. You can measure time, but you can't measure effort directly, unless you're maybe doing some physical work like pulling weights. Also, you can't usually increase a mental effort, except by spending more time (e.g. by working overtime).
I can only see points or other non-time measures as proxies to time intervals (with uncertainty), but we can't know the function points -> time beforehand, we can only measure and map it from experience.
If you could explain "effort" from some other angle, I'd be grateful.
My answer is that you can plan for work to be done on a deadline but you can't negotiate when it will be done with the people doing the work. It's going to take as long as it takes. It's poor management that sets unrealistic expectations and demands results.
You can plan for work by using data. You get data by tracking effort estimated versus completed and triaging bugs. You prioritize goals instead of setting deadlines. You measure and refine.
It sounds counter-intuitive to business people who think in terms of, I just sold customer X the product and they need it delivered by Y so that we can get the team paid by Z. This is where poor management decisions can sink your team. If Y is decided by the sales or management team with the customer and they didn't consult their engineering team... then they're working on another planet. The goal of processes like this are not to eliminate Y but to set reasonable expectations and objectives.
As I like to remind my business owners: you can have something that works -- it may not be the whole kit -- or you can have nothing at all. Winning is about prioritizing objectives.
One book I've read recently that taught me a lot about management is Extreme Ownership[0]. I think there's a lot of cross-over from this book into Agile methodologies that I think non-technical stakeholders can really understand.
[0] https://www.goodreads.com/book/show/23848190-extreme-ownersh...
If I'm interpreting that fragment right, your essay is treating "programmers development time" as a fixed rate of progress (the "9 women can't have a baby in 1 month" meme) so one answer to meet a deadline is to remove features until the deadline can be met.