Patience is waiting. Not passively waiting. That is laziness. But to keep going when the going is hard and slow — that is patience. The two most powerful warriors are patience and time.

—Leo Tolstoy (claimed, unverified)

I could have sworn the quote was different, and I've been misquoting Tolstoy for weeks, not that I'm sure Tolstoy ever said this. Maybe it doesn't matter. I prefer my own version, anyway:

Waiting is productive. Not passive waiting—that's laziness—but active waiting.

#Life #Maxims #Quotes

I do my thing and you do your thing. I am not in this world to live up to your expectations, and you are not in this world to live up to mine. You are you, and I am I, and if by chance we find each other, it's beautiful. If not, it can't be helped.

—The Gestalt prayer by Fritz Perls

#Life #Quotes

He wears a mask, and his face grows to fit it.

—George Orwell in Shooting an Elephant

#Life #Quotes

Sadly, software cannot be estimated that way, and we need to stop pretending otherwise. It's a myth—a pervasive one—and perpetuating that myth only perpetuates its harm.

Sure, if a task is almost identical to some previous task, a precise and reliable estimate really can be communicated. Unfortunately, that almost never happens. If the work ahead were so similar, someone would have done it already using copy and paste. If it's similar and the engineering team wanted to set themselves up for success later, they'd refactor the system. That refactoring itself can be a hazy fog of unknowns. We've all been there many times.

In my fifteen years as a software engineer, I've worked in many different kinds of organizations, from a small non-profit research and development lab (the Open Publishing Lab at RIT), to a medium-sized, quasi-non-profit business with a deep and pervasive developer culture (the Mozilla Corporation), to a for-profit startup in the music industry (Inveniem), to a publicly-traded conglomerate with an estimated 100,000 employees (Honeywell). Although I have fond memories with all of my former employers, in my experience, not one was even remotely better or worse than any other at software estimation. Clearly, something more fundamental is wrong.

I think the problem is obvious. They all wanted to know the unknowable.

The problem

I once worked with someone who liked to compare software development to parcel delivery: communicate a date when the package is expected to arrive. It's okay if there needs to be a delay, as long as that delay is communicated clearly. While the flexibility with delays was genuinely appreciated, the broader analogy soured on me over time. In truth, estimating software is nothing like estimating package delivery. The former involves doing something that has never been done before, while the latter is completed billions of times each year. Does Amazon have an advantage when forming estimates? You'd better believe it.

Software development is one of the only professions where we are asked to accurately state how long it will take us to do something that has never been done before in the history of the universe.

—Unknown, from a screenshot on X

How long will it take for Amazon to deliver a board game to Zara in Cincinnati? Well, probably about as long as it took last time. Yes, every delivery is different, but there must be millions of deliveries of similar items to nearby locations with similar weather forecasts and other pertinent factors being similar or identical. How long will it take? Probably that long.

By contrast, how much time will be required for me to change code I've never seen? I truly have no idea. How about adding, say, karaoke support to a streaming music app, one with millions of lines of code I've never read, where myriad caveats exist for different software clients, different spoken languages, and different copyright laws. How long will that take? Except in extremely broad terms, your guess is as good as mine. It will take more than one week, and it can probably be completed in less than one year. Beyond that, there's not much more that can be promised, at least in the beginning. More on that in the next section.

No, estimating software development is nothing like estimating like parcel delivery. It's more like estimating the pace of scientific progress. We simply don't know what we don't know. We can't know until we do it.

As much as possible, organizations should communicate that software will be ready when it’s ready. If some software must be released by a certain date, the feature list should not be guaranteed. I know this is easier said than done, believe me, but reality is what it is. Software simply cannot be estimated the way organizations imagine. Some higher-ups, especially those who have not been software engineers, may find this outrageous. They may demand exact estimates regardless. To them, I would say, “Fine, but let’s be honest, how’s that working for ya? How often are you given estimates that actually turn out to be correct?”

There's a reason you're reading this blog post. Something isn't working, and it's not about discipline. It's not about communication. It's not about skill. You're on the wrong path. Skeletons and vultures surround you. It's time to turn around.

Thankfully, there is a better way. Your manager may not like it at first, but over time, they may come to see that estimates of this type are actually useful, unlike the aspirational and unreliable estimates they're accustomed to.

The solution

To explain this kind of estimation, I need to define two terms. First, I'm using the term accurate to describe any estimate that is correct within a given range of dates. Defined this way, even a very broad estimate can be accurate. For example, an estimate that a feature will be completed some time between March 1^st and December 31^st would be accurate, as long as it turns out to be true. Precision is another matter. Precision refers to how narrow a range of dates is, with more narrow ranges being more precise. The previous feature estimate isn't very precise, but it would be more precise if it predicted a completion date between, say, April 1^st and July 1^st. This is how Rapid Development defines the terms, and I think it’s a good approach. In fact, most of this advice is lifted from Rapid Development. I recommend reading it. It's a tome, so focus on the sections that are most pertinent to your needs.

Crucially, estimates can and should become more precise as time goes on and details become more clear. If a team begins with an estimate of some time in Q1 or Q2, but the feature is more difficult than expected and they realize they need to revisit the database schema, perhaps the estimate could be narrowed to some time between May 1^st and June 15^th. If the team is nearing the end and the final code reviews go more smoothly than expected, maybe the estimate could narrow to some time between May 16^th and May 31^st. If a critical issue is found elsewhere in the codebase, taking the team off the feature for a while, maybe May 29^th becomes the most likely date of completion. The point is, there's practically no way to predict those circumstances in advance, but they can inform better estimates over time, as long as the estimation method supports that.

Did you instead randomly pick a date three months in advance? Too bad. You're screwed.

Reality-driven estimation

So how should we estimate? Strive for accuracy, start with low precision, and seek greater precision over time. As another example, you might consider communicating a project end date some time between Q2 and Q4, then later refine that to some time in the fall, then some time in October. Finally, at the very end of the project, you might be able to promise a specific week or even a specific day. That is an approach to estimation which acknowledges reality. That is an approach to estimation which acknowledges that surprises happen.

Do organizations want to hear this? Unfortunately, no, I don't think so. It's a tough sell. Organizations want certainty, and they want it now. Good luck telling your boss that you don’t know exactly how much time and money you're going to spend. Even the project management apps we use typically require that an estimate be recorded as a specific date. Talk about encouraging bad practices.

Pushing back is hard, and as someone who was raised to never question authority, even when that authority is obviously wrong, I happen to be particularly bad at it. That's too bad. Our bosses pay the bills, but we do the work. It's time we start saying, “The work can't be done that way, and if I were to tell you otherwise, I'd be lying to you.”

Reality is what it is, and the best we can do is provide estimates with gradually increasing precision. Organizations can pretend otherwise, and countless surely will, but again, I would ask, “how's that going?” Organizations ignore these facts to their own detriment, at the cost of time, money, and frustration. I wish them luck.

For everyone else, consider embracing reality. It's not perfect, but it's the best we can do.

#Life #Quotes #SoftwareDevelopment #Tech

Tomorrow may rain, so I'll follow the sun

—Paul McCartney

#Life #Quotes

Death isn’t a failure of care.

On some level, it seems obvious enough. No one has ever beaten death. Your loved one was supposed to be the first? I don't think so.

On another level, I find the statement difficult to accept. There's always more that could have been done. I could have timed her medication better. I could have brushed her more to calm her and to express my love. I could have slept by her side those final days, on the floor of my office where she hid at night. I don't know why the idea only occurred to me later. Maybe she would have lived longer if I had. (To be fair to myself, I was pretty confused and exhausted in those final days. Perhaps I couldn't think clearly with her health declining.)

Kika's death

Kika ultimately died of gastrointestinal disease. She may have had lymphoma, but we will never know for sure. Her primary veterinarian felt that certainty was unnecessary, because the treatment for lymphoma was the same as the treatment for other kinds of gastrointestinal disease. We did follow that treatment plan, but it wasn't enough.

I brought Kika in for an appointment the day before she died, on my mother's urging. My mom knew I would never regret going, but I would regret not going. That turned out to be excellent advice. If it hadn't been for that, I would still be second-guessing myself, wondering if Kika had died of acute pancreatitis or something else that I failed to see. The vet took some fluids and sent them to Cornell, but when Kika passed the next day, the practice cancelled the tests. On the day Kika passed, the attending veterinarian did say something about how Kika's fluid looked cancerous under their microscope, but I was so flustered I could hardly understand what she was talking about.

The GI med may have worsened Kika's condition in the end, but I still think trying it was the right course of action. No one could have predicted how she would react to it, and if I hadn't tried it, I would be blaming my avoidance of the medication for her decline.

Even still, I should have been able to extend Kika's life somehow. Every choice matters. In that sense, wasn't her death a failure of care?

I don't know. There are many causes of death in humans and animals. Kika didn't die of the following things, to be clear, but mistakes happen, people die of medical malpractice, and accidents take lives too soon. Are those deaths predetermined? Are they unavoidable?

Maybe they are.

Kika died because she was a living thing, and living things die. Death is the price we pay for birth. Perhaps everything else is secondary—a few days here, a few days there, perhaps more. Immortality? No.

The Mortal Rule

I'm not a Buddhist, but I find Buddhism interesting and Buddhist and Buddhist-inspired meditation indescribably helpful. Buddhism can sometimes seem impenetrable, with myriad traditions, vast terminology, and scripture which is much more voluminous and much more sprawling than Westerners are accustomed to. I recently stumbled across the “Five Remembrances,” though, and they are not at all difficult to understand. They offer a meaningful response to my difficulties, or perhaps a preventative for the feelings I've been struggling with. Practitioners are encouraged to memorize and reflect upon these facts, as interpreted by Lion's Roar and author Koun Franz:

I am of the nature to grow old. There is no way to escape growing old.

I am of the nature to have ill health. There is no way to escape having ill health.

I am of the nature to die. There is no way to escape death.

All that is dear to me and everyone I love are of the nature to change. There is no way to escape being separated from them.

My actions are my only true belongings. I cannot escape the consequences of my actions. My actions are the ground upon which I stand.

The names of others can be substituted in these reminders. Kika was of the nature to grow old. Kika was of the nature to have ill health. Kika was of the nature to die. There's nothing we could have done to change that. (The last remembrance seems like a non-sequitur, but I assume its inclusion partly serves as a reminder of the centrality of karma in Buddhist thought.)

Philosophical stoicism offers similar advice:

With regard to whatever objects either delight the mind, or contribute to use, or are tenderly beloved, remind yourself of what nature they are, beginning with the merest trifles: if you have a favorite cup, that it is but a cup of which you are fond, – for thus, if it is broken, you can bear it; if you embrace your child, or your wife, that you embrace a mortal, – and thus, if either of them dies, you can bear it.

—The Enchiridion of Epictetus, as translated by T.W. Higginson

Dialectical behavior therapy encourages the broader practice of “coping ahead.” Others take solace in remembering the phrase “memento mori.” It's not the Golden Rule, I suppose, but there's enough ancient and modern support for the idea: remember that you and others are destined to die. It has helped me, and it may help you, too.

Watching without failing

In the end, Rachel may be correct. Certainly, insisting that your loved ones overcome death is insisting that you be disappointed. You will not succeed. Even still, that won't make you a failure.

#Life #Quotes

—P.J. O'Rourke

I love this quote, because I've been that guy. I've been the guy who thinks he can save the world but who literally doesn't help his mom with the dishes when he visits. Thankfully, I've dramatically softened in my activism (appropriately discussed ever so briefly in a recipe but nowhere else on this blog), if it can even be called activism any more, and I did help my mom with the dishes during my most recent visit, although I'm sure I could have done more.

I interpret the statement like this: riding a “high horse” can be fun, and there really are important societal problems that ordinary people can help improve. That said, there are always more ordinary problems that need attention, and sometimes fixing those things goes further than protesting in the streets.

#Life #Quotes #SocialMedia #Tech

It is really true what philosophy tells us, that life must be understood backwards. But with this, one forgets the second proposition, that it must be lived forwards. A proposition which, the more it is subjected to careful thought, the more it ends up concluding precisely that life at any given moment cannot really ever be fully understood; exactly because there is no single moment where time stops completely in order for me to take position [to do this]: going backwards.

—Søren Kierkegaard, as translated by Palle Jorgensen

This reminds me of what Steve Jobs said in his 2005 Stanford Commencement Address: “You can't connect the dots looking forward, you can only connect them looking backwards.” Based on the stories I've heard of Jobs, I wouldn't be surprised if he knew he was borrowing from Kierkegaard.

#Favorites #Life #Quotes

“I can explain it for you, but I can't understand it for you.”

The problem is, that's pretty curt. I don't think most people would be able to really hear that, and I think we have a responsibility to make sure our words are heard. If we know our words won't be heard, what's the point of speaking at all? Is it to feel better about ourselves? It shouldn't be, in my opinion. We have enough of that already.

For that reason, I might try something kinder first when talking with an ornery person. In the past, I've used the following, and people seem to take it well.

“I'm sorry that's not the answer you want, but that's my answer.”

Substitute the word “answer” for “request,” “advice,” or any other word as needed.

#Life #Maxims #Quotes

—Mel Brooks

#Life #Quotes