top of page
  • Writer's pictureJosh

The Not So Quiet Genius of Herb Wasserman

A few months back a reader sent us notes that his mentor had written and collected over his many years working on projects.  His mentor, Herb Wasserman, was a crochety, angry bastard who saw that everything was a shit show, and as such, took it upon himself to be the champion process improvement super freak.  He was also a bit of a contrarian.  Scratch that, he was a lot of a contrarian.

When some of Herb’s co-workers would express their thoughts, Herb would take up the opposing opinion solely because he knew that if this other dude thought it, it had to be stupid.

His notes, if you can call them that, were littered with all nature of colorful phrases, and interesting ways of describing his co-workers and bosses.  His immediate boss, who he called the Cock-Sucking Fucker-Muppet, didn’t care for his attempts at process improvement, and Herb’s notes reflected what he thought about Fucker-Muppet’s feedback.

Nearly every entry consisted of him saying “we fucking need to be better” or some variation of that.

The genius of Herb Wasserman wasn’t his generous use of the word fuck (that’s our schtick), nor was it in his near Shakespearian turn of phrase used to describe those around him and the situations he found himself in (the office administrator was referred to as “the brightest bulb in a factory without power”).  No, Herb’s genius was in his brilliant yet batshit terrible ideas, and the incredibly petty reasons he came up with them.

Did Herb Accidently Invent Agile?

“While those titans of suck frolic through lush meadows of flowering shit, we’re stuck hanging on their every fucking whim.  To that end say I: fuck you.  We’ll build you what ever the fuck we want.  If you don’t like it, make another fucking request.  We’ll make your fucking fucked changes, but not in the middle of building your last fucked changes.”

A decade or so before Agile was introduced, Herb recognized that clients are “snot-sucking bastards with the IQ of lumpy fucking gravy.”  To work around this, Herb outlined a methodology that treated the clients like (to put it in a more acceptable way) “fucking children with developmental disabilities.”

Tired of the midstream changes or delivering work only to find that it wasn’t what they actually wanted, Herb developed a strategy.

  1. Break down all work into bite sized pieces.

  2. Present completed work one item at a time.

  3. Ask “does this please you, Great Overseer: Titan of Suck, Writer of Paychecks?   Does it please you?  Is our sacrifice worthy of your praise?”

  4. Get sign off on the work that was completed.

  5. Start work on the next item in the list.

  6. Repeat.

It’s a pretty good approach, right?  It’s a strategy that is utilized by many teams to varying degrees of success, so what was the problem?

Well management had the “object permanence of a braindead jellyfish.”

“This isn’t everything we asked for, where is everything else; why are we still talking about the last thing deployed; why am I such a dumbass?”

Herb likened it to making a sandwich.  The business wasn’t understanding that they needed to agree to every ingredient along the way, instead, insisting that he deliver a sandwich, and they’ll say what they like and don’t like, and then you can go back and make a sandwich that meets the new (updated) sandwich request.

So, it’s not that delivering small pieces was a problem.  The problem was the business leaders had never been to a subway.

Exploring the Right Idea, Just the Wrong Mathematical Principle

Herb noticed that those on the business side didn’t care about feelings or intuition.  No, they wanted to see fucking numbers.

Trying to explain how the effort it would take to make a requested change doesn’t translate to time because of various complicating factors was like trying to explain open heart surgery to a kindergartner who doesn’t speak English.  They might appear to be interested, but they don’t understand what they fuck you’re talking about.

Herb’s experimental solution?  Pythagorean triples.

Yeah, you read right, Pythagorean triples.

For those who don’t know, a Pythagorean triple are three whole numbers that satisfy the Pythagorean theorem (A2+B2=C2).  It includes the sets (3,4,5; 5,12,13; 7,24,25; 8,15,17; and so on. 

The idea was, you could demonstrate how something that has a low level of effort can still take a long time to do because of complicating factors, like code being “load bearing.”  So, if the LoE is determined to be a 9, but the code has a high rate of connectivity to other code, you could rank that at a 40, which would provide an overall complexity of 41.  Low LoE (9) realistic idea of how difficult it is, is high (41).

The strategy of giving a numeric value to LoE and complicating factors (being the two small numbers in the triple), he could provide a measure of how complex requests could be that felt quantitative, but in reality (as Herb admitted) was still based on feelings and intuition.

The problem?  None of the developers wanted to learn fucking Pythagorean triples, and if you used straight maths instead of the triples it doesn’t provide a clear enough explanation of how these things interact.  Like, what the fuck does mean, or worse ; and how the hell does that equal about 8.9?

What Herb stumbled into here is a problem with estimating work that I’ve heard from many of the developers that I’ve worked with complain about.  Something might be an easy enough job, but there are a lot of complicating factors that are unforeseen when simply determining story points.  The solution, typically, is to use Fibonacci numbers, and just combine the level of effort with anything that might be a problem when estimating.

The issue here is, from the outside, the scoring seems confusing and arbitrary.  Two nearly identical requests can have drastically different story points.  The straightforward one might be a 5, while one that is also straightforward, but has complicating factors that the first one didn’t scores a 13.  As a project sponsor, I can’t see that the additional estimated effort is related to the complicating factors, I just know that I’m being taken to the fucking cleaners.

The nice thing about using Pythagorean triples, and the reason we would like to see it better implemented, is that it establishes a relationship between two things, and how those things can affect each other, in a way that seems intuitive enough that even the dryest fuckers on the top floor would understand.

In fact, when discussing this with a reader, he informed us that they use a similar concept when explaining to clients the issues with concrete drying, and why it is having an effect on the schedule.  They show a graph, where the x axis is climate (temperature, humidity, etc) and the y axis is depth.  They then show that depending on where the x and y intercepts fall, the length of the line connecting them grows or shrinks.  A shallow slab being poured in terrible conditions might take longer to cure than a deep slab in ideal conditions.  The graph is a nice way of presenting them this information.

Why Herb’s Notes are an Important Reminder That Process Improvement is Necessary, But Sucks for Everyone Involved

In a note that he wrote early on in his career as a project manager, Herb wrote about being pulled on to a newly formed team that would be orchestrating new product development and keeping the teams falling in step with each other.

Because it was a newly formed team, there were no processes in place, no templates to speak of, and no clear direction on how to handle things, Herb set out to change that and introduce structure to an otherwise unstructured team.

The issues arose when he began to butt heads with his boss.  Herb believed in the power of getting a lot of information up front, to avoid making ill-informed decisions later on, or worse, making broad assumptions based on reading the audience between the lines.  His boss, on the other hand, believed that starting now, and figuring out the details later is better, and any attempt to bring processes to the new team was an exercise in futility.  The problem, as his boss put it, was that we were trying to get too much information early on.

In this note, Herb starts to rant about how much he hates Superman.  Calling out the error in the famous lines from the superhero comic.  Firstly, he states, it’s unreasonable to believe that a New Yorker is going to be looking to the sky in Midtown Manhattan, and two, that they would feel the need to say they saw something weird, especially when that weird thing is a psychopath in a spandex onesie.  He likens his experience with his boss to these same “look in the sky” people to eloquently describe what the central problem is with process improvement.

It's very easy to call out things that are wrong or out of the ordinary, but too often the people calling them out are wrong about what they are seeing.

There is something that isn’t right, but it’s something boring and ordinary (it’s a bird shaped like a six-foot-tall man, nothing out of the ordinary there, probably just a quetzalcoatlus back from extinction).  The key is understanding that the dude thinking a bird is worth calling out is doing so because they feel strong enough about it to bring it up.  Their motivation is the same as yours.

Which is where Herb wrestles with his desire to drive process improvement.  Is he the one saying it’s Superman, or is he the one saying it’s a tiny human shaped plane?

It’s a rare bit of humility from the one who affectionately called his favorite coworker a Jackass of all trades.  Herb understood that you can’t be sure if you’re the bird, the plane, or the Superman guy, but you can be sure that you’re at least doing something productive, rather than doing the typical New Yorker thing and not looking up. 

Herb’s argument for process improvement takes on a Socratic feel, as he explains that so many people around him are content to simply stare at the concrete walls, rather than peering around and seeing the passersby casting shadows in the cave. 

This begs the question, then, is it better to call out things that can be better, ala Superman, or is the ignorance of better processes the path to contentment ala, Plato’s allegory.

For us at Astutely Obtuse, we choose the former, because calling out a dude in colorful spandex who is ruining your project is a cornerstone of being a good project manager, even if that colorful spandex dude ends just being a bird (or a guy in a bird costume, we don’t judge.)



Recent Posts

See All


bottom of page