The Official 2022 Death Pool
-
@Zecc The most important single decision he made was to make bytes 8 bit. The most important legacy he left wasn't that decision and the move to support lower case but to produce possibly the most misunderstood project management guide in history.
-
@Arantor wdym, it only takes a few man-days to read, if that.
-
@Gribnit two Gribnits, one book.
-
@Arantor Out of curiosity, how do you think the book was intended to be understood, and how is it misunderstood? I read the book in college and the professor really emphasized a few points in the book he felt were most important.
The things I got out of the book were:
1.) A project's core complexity and level of effort (especially with prerequisite tasks) will be the main determination as to its minimum time it could possibly be completed, and of its initial quality. There will be a point at which no matter what you throw at it, it can't be completed sooner or with a certain threshold of quality. (the essence of "no silver bullet"). The more complex the system, the inevitable greater number of bugs and greater chance of "whack-a-mole" bugs.
2.) The number of engineers dedicated to the task will have less impact on the timeline than other more important factors, such as the skill and subject matter knowledge of those engineers and above all their ability to work as a team (malcontents vs team players). There should be a distinct hierarchy of a small set of lead engineers and architects (possibly even just one of each) to prevent a "committee problem" and another set of qualified and specialized subject-matter experts and "toolmakers" followed by the rest. Plus, no matter how well the engineers work, there is a diminishing value with each additional engineer assigned. Finally, adding more engineers after the work has already started is a foolish decision that will actually negatively impact the project's timeline due to the rampup and training resources needed to even make them productive.
3.) Stakeholders should expect the first version of the software to suck. It is the intent to prototype first with a rough draft (a beta if you will), see where the gaps are, and then make a far stronger second version of the software that learns from the mistakes of the prototype. It's important to recognize both the benefits and problems of the organic and "easily changed" nature of software, such that you not make it too malleable as to create a moving target of scope creep and wild changes in the middle of testing that causes confusion as to what is wrong, but also adopt principles of continuous improvement in a methodology of distinct version updates in a cadence that allows people to provide feedback on the previous version without having to worry about the software changing on them in between time.
-
@The_Quiet_One said in The Official 2022 Death Pool:
It's important to recognize both the benefits and problems of the organic and "easily changed" nature of software, such that you not make it too malleable as to create a moving target of scope creep and wild changes in the middle of testing that causes confusion as to what is wrong, but also adopt principles of continuous improvement in a methodology of distinct version updates in a cadence that allows people to provide feedback on the previous version without having to worry about the software changing on them in between time.
...and breathe.
-
Tragic news! I've actually met him.
-
@The_Quiet_One I always understood TMMM as one part guide on how to and one part guide how not to. What puzzles me is how many times I've seen the 'how not to' weaponised anyway by people who don't understand why it's not going to work. Every major example - from adding more people to a project makes it go faster (not necessarily, especially not after a certain size), to no silver bullet, to 'don't add people after work has started', and every time these come with special one-off reasons (rationalisations) to make sense.
The main issue is that TMMM was written in a world where basically every project was run in a waterfall fashion - analysed, designed, estimated, costed, developed, tested, delivered, maintained; the classical software engineering lifecycle.
-
is still fundamentally true if your core development process is waterfall or waterfall-adjacent where a reasonable amount of the constraints are known or assessed in advance, because you've made a pretty good (in theory) analysis of the core complexities and eliminated the worst of the unknowns.
-
The pure quantity, definitely less impact, and that was absolutely the one takeaway that people did get from this: if 1 engineer takes x months, x engineers will not take 1 month, and that the more engineers you add, the proportionately longer it's going ot take to onboard, upskill and manage, to the point that after a while adding new engineers at all to a project is simply a net drag. This set of principles, definitely aged the best and least misunderstood - and yet, inevitably still applied anyway because people aren't in practice good at thinking this through. This is further muddied by 'Agile' where everything is always still moving anyway, meaning that it's borderline impossible to have a point when 'a project isn't ongoing', so you have to take the hit to onboard someone with all the second order effects that come with it.
-
They should expect that. My experience is that they never ever do, not even if you tell them up front that that's what you're doing. v1 is expected to be production quality with fewer features but no less quality than finished production. In their mind, they have paid for a thing, not a half-assed version of the thing.
The main issue, though, is that in the intervening years, Agile has been let loose upon the world, redefining expectations at every level and every step of the process. The theory seems to be that 'we have to be fast' and be able to turn on a dime to reflect customer requirements as they evolve (because why bother doing requirements gathering up front when they're going to change).
My experience, ultimately, is that people try to use what's in TMMM as a blunt object to hit people over the head on how to fundamentally mismanage software development. Either it's interpreted literally and smashed into whatever Waterfragile development process is going on to 'fix it', or it's interpreted to justify how 'we're different, the rules don't apply to us' to assuage whatever management nonsense is going. I've seen enough examples of both in the last 20 years - not even in pure dev environments - to conclude that it's almost like Sun Tzu's The Art of War: a tome many claim to have read but if they have, they didn't understand what it taught because they read the words, not the meaning.
-
-
@Arantor said in The Official 2022 Death Pool:
read the words, not the meaning.
Thus confusing your enemies.
-
Come on Lance. You can do this. At least, I am not totally convinced that you can't.
-
@Gribnit It works on you.
-
-
-
-
who would later become a theater professor and author
So much potential
has died at the age of 66
Tragically cut short
-
Nobody posted this? Guess no fans here. (I'm not either.)
-
@Atazhaia ah yeah, he bit the first modern puck directly from a semitrailer tire
-
-
-
And it's time for the yearly recap, like Spotify Wrapped but for now dead people:
-
-
-
-
@boomzilla I'll allow it.
-
-
-
@Mason_Wheeler finally, some real progress will be able to be made in soccer theory.
-
-
-
-
-
-
@topspin he shoulda held on a few more decades - protip, if you get Poped, write yourself some health advice each morning. Parlay that infallibility into inmortality.
Although, he really let the merchandising get out of hand on
Deus caritas est
. You wouldn't believe the vulgar crap I've seen that slapped on. 'Ceptin' the vulgarity.