What is a task

Innocuous questions about basic things end up causing me so many headaches.

I was trying to map some tasks to each other at work—there are, notionally, definitions of tasks and how they relate to each other, but it's not formally laid out—and I paused for a moment to ask myself: what is a task?

I'm not sure if that's even relevant to what I was doing, which has to be wrong, right? You can plan tasks without having a formal definition. I don't know how I'd get through the day without a heuristic like that. A task is a thing to do, and when it's done, it's done. Anything more complicated than that and the dishes wouldn't get washed, the trash would pile up, and the refrigerator would be empty.

But I want to play with the formal idea a little. I'm taking OMM 500D Project Management at Wash U this year. I know how to use Microsoft Project reasonably well, but that's just a tool to use—I'd like to think about things a little from the bottom up, starting with questions like: what is a task?

Thinking about what a Task class looks like...

  • A Task is a thing to be done:
    • Describe the thing to be done
    • Know when the thing is done or not done
  • A Task starts:
    • It starts at a time
    • Someone starts it
  • A Task ends:
    • It ends at a time
    • Someone ends it
  • There are different uses for a Task:
    • Planning
      • A Task can be planned to start or end at a time
      • A Task can be planned to start when another Task(s) end
    • Doing (above)
    • Reference
      • A Task can be recalled later for information
      • A Task can be shown in a map with other Tasks

I have some doubts that this line of thinking is going to result in some sort of prize or breakthrough. I don't have any big problem to solve—this is just an exercise in building things. What does it take to build a task planner, or task analyzer, or project scenario visualizer, or whatever.? Not a to-do list manager (Microsoft To Do is mighty nice), and not a project scheduler (Microsoft Project is... what we have), but something else that lets me play. I'm also not a proper software developer, and there are some features of Python I've been meaning to learn how to use (e.g., NetworkX for graphing networks), and some methods for modeling systems that I ought to learn to be fluent with our modelers at work. So it's all unnecessary, but for fun.

I started a repo called renwu to play around. (任务/rèn​wu is the Chinese word for task.) We'll see where it goes. Metaproject: developing tasks for a project that develops tasks.
In the meantime—as ever—here are some interesting things that I found that I may (or may not—as ever) follow up on:

An alternative definition of task: something you were late in finishing.

The Captain's Newsletter, 2021-W06

It's cold outside. So bundle up by the fire, get yourself a nice warm mug of newsletter, and listen to me complain about the cold outside. Some people will try to tell you that you shouldn't complain. Don't listen to them. These people are just amateur complainers who are jealous of your superior complaining skills. Whine on you crazy griper.

The Captain's Newsletter, 2021-W06 - The forecast for today

Newsletter and chill: /captain.

Cranky rewards

Trailhead: Zaria Gorvett. Why it pays to be grumpy and bad-tempered. BBC Future (2016-08-10).

Eh. Honestly I didn't need any more motivation to be ill-tempered. But I do appreciate the opportunity to know that I can be that way and get something out of it. It really takes away some of the anxiety of knowing that I've been a difficult person to deal with.

The truth is, pondering the worst has some clear advantages. Cranks may be superior negotiators, more discerning decision-makers and cut their risk of having a heart attack. Cynics can expect more stable marriages, higher earnings and longer lives – though, of course, they’ll anticipate the opposite.

I don't act difficult by choice. It happens when I settle into Problem Solving Mode. It's not a decision to go there—something catches my attention, a switch is flipped somewhere inside, the world narrows into a focused beam, and I can be an outright jerk while I wrestle with The Problem, whether it's a real or perceived problem. That narrowing causes the problem to be as large as the world—ignoring it isn't an option. Thinking nice thoughts about it isn't something I do—internally I'm really cranking away trying to find an angle, a solution, and I just don't feel the extra space I would need to have a balanced view of the situation. I just... it is Go Time. And although I'm sorry that bystanders sometimes catch an elbow, that's often after the system has cooled down.

In essence, creativity is down to how easily your mind is diverted from one thought path and onto another. In a situation requiring fight or flight, it’s easy to see how turning into a literal “mad genius” could be life-saving. “Anger really prepares the body to mobilise resources – it tells you that the situation you’re in is bad and gives you an energetic boost to get you out of it,” says Baas.

There is a fuzzy line in there—hard-nosed focus to get something done, and just being a good old-fashioned asshole. The only way you really know the line is there is after you take a few steps over it, after you finally catch an empty second to look around the room and read the expressions. Not again. Sorry.

I'm also not sorry. That mode is my superpower. But it's a superpower with poor control. It's complicated. The tools we wield, wield us.

One thing missing from that article: it's written as if the benefits accrue to the crank. But who really works alone? How does having that so-called mad genius on your team work out for everyone involved.

Small nothings passing through vast nothings

In an alternate timeline, I decided to stay in the astronomy department in college and not switch to engineering.

"Astronomers Confirm Solar System’s Most Distant Known Object Is Indeed Farfarout". NOIRLab press release (2021-02-10).

This is more like what I imagined when I was thinking about studying astronomy: staring into a telescope for a very long time, staring into the abyss, trying to make incremental sense of an incredibly large, dark nothing.

It's easier to imagine an alternate me doing that than a real me. There's something romantic about the idea of sifting through data, day after day, year after year, searching for answers to abstract questions of the universe. Romantic about the idea. The idea is a movie montage—a telescope, a man at a computer, a man point at the stars, a press conference with shutter clicks and pointing to the reporters for the next question. Years of waiting and popularly uninteresting results not thrown out so much as never considered for inclusion. A long arc reduced to its key points. A reality, a fiction.

I doubt that professional astronomers really sit there and look into telescopes night after night after night. Anything that needs the kind of resolution that can be handled by the human eye is surely a nineteenth century problem. There are things we would recognize as images, but much of it is raw, raw data. Looking for the light wiggles of a star eclipsed by a planet that can't be directly seen. Impossibly scarce but very hot gases like wreathes around star systems. Ever-so-slightly unexplained perturbations in the orbits of our neighbor planets, indicating that something somewhere is lending its gravity to the party.

Long, slow problems. Small nothings passing through vast nothings. Ambiguous traces of interstellar importance. How many of these small wanderers exist out there? It's not even a real number. Swivel back around to the eyepiece, and keep looking.

The false name

Currently reading The Book of Disquiet by Fernando Pessoa—this from fragment 66 in Richard Zenith's translation:

Civilization consists in giving something a name that doesn’t belong to it and then dreaming over the result. And the false name joined to the true dream does create a new reality. The object does change into something else, because we make it change. We manufacture realities.

This is the opposite of giving things the right name, no?

The right name is for building tangible things, measuring them, verifying their results against our expectations. But the right name is the right name only because we believe it is the right name. It's what it is—without a name, whatever it is essentially—and it is the result of the name that we give it, and it is the story that we build (bind) around it.

This page is nothing but paper or a screen. And the words, individually, are ideas that don't mean much individually. Then I put them together on the page, and give it all a name, and wish it into a new existence.

Every new beginning is an open field, and the turbid past follows at a distance until you slow down enough and it eddies turbulently ahead, burying the grass that was once greener in sediment. Why not pause, and give it a fresh name anyway? A new name doesn't wash anything clean, but it might be that name which allows you to believe in the world under the sediment, a false name that isn't what it is, not apparently at least, and get on to the next day, day after day, perhaps even restoring the place instead of pushing onward without rest.

Intentional networking

This week in OB 565 Leading Change we've been discussing the role of networks in organizational change. For the most part, we're taking off from two articles:

The general idea is that you can map out who-knows-what and who-knows-who to understand how organizations actually work, not just how they're formally organized. Using ORA and observed company data, we get network graphs like this:

That all makes sense to me. It's all graph math based on relationships between nodes. It's similar enough to how we model how faults propagate through a network in aircraft, from the sensors that detect them to the computers that collect and analyze them to the displays that alert the pilots and the maintenance crews on the ground and so on.

The part that isn't sinking in is the idea that organizational networks can be designed intentionally to produce some desired outcome (or avoid some undesired outcome, like having noncommunicating factions within the organization). It all sounds like nice theory—very nice and neat, the kind of thing a professor can write on a board and then, with a swish of the hand, declare it "obvious".

I'm slow. It isn't yet obvious to me how you can go from (a) computational organization design to (b) a meaningful real world change. I believe it, and I can feel it, but I can't see the connection yet to the real world how-to yet.

The two examples that come to mind that are the nearest to what I am most often concerned with:

  1. How to organize teams at work in such a way that the many components and subsystems and software and test kits and so on can get done in an "optimal" way. (The scarequotes mean: what is optimal? Fastest? Cheapest? Most robust organization that won't fail due to turnover or difficult technologies not getting ready in time?)
  2. What skills should I learn and who should I meet to achieve some goal?

So I'm looking around for a bit more practical information about the how-to. I don't need any papers that explain the graph math of different organization structures. It's not even really about considering the pros and cons of different structures. It's more like: (a) how do you really know what structure you have, and (b) how do you know what structure you should have, and (c) how do you perform small experiments to discover a good path from (a) to (b)? I suspect it's right there in front of me in these articles and papers, but I'm too dense to get it. It's an interesting problem and I'd be surprised if there's a tried-and-true method to do it.

The right name

There's a scene at the end of the film version of Into the Wild, with Chris McCandless in Bus 142 shortly before learning that he has misidentified a wild plant and eaten seeds that likely caused his death. He's reading Doctor Zhivago by Boris Pasternak, and highlights this passage:

The path trodden by wayfarers and pilgrims followed the railway and then turned into the fields. Here Lara stopped, closed her eyes and took a good breath of the air which carried all the smells of the huge countryside. It was dearer to her than her kin, better than a lover, wiser than a book. For a moment she rediscovered the meaning of her life. She was here on earth to make sense of its wild enchantment and to call each thing by its right name, or, if this were not within her power, then, out of love of life, to give birth to heirs who would do it in her place.

I have to start with Into the Wild, because I haven't read Doctor Zhivago itself. (And it's an affecting, memorable scene.) I don't know the rest of the story, so I'll proceed confidently without context.

David McClinton had a go at a list of rules of systems engineering about thirty years ago. (McClinton, David F. "The Unwritten Laws of Systems Engineering." INCOSE International Symposium. Vol. 4. No. 1. 1994.) The primary three rules are: (1) Everything interacts with everything else; (2) Everything goes somewhere; and (3) There is no such thing as a free lunch. Those are good. I won't argue with them. Some of the other ones are OK, but not as good.

If I were writing the rules of systems engineering, I know what the first one would be:

Call each thing by its right name.

In the beginning—of a project, of a design—there is darkness. More or less. And out of that darkness arises thoughts and ideas and concepts, and they start to congeal into more complex functions and systems and experiments, and so on and so on until the thing is done. But the names of the original ideas change over time into the more focused names of the implementation, but not uniformly. A spectrum of names for the same thing accumulates where the One True Name should be. Things get missed or duplicated or confused.

I can feel the pitch of my voice raise when I encounter these issues. Every bag-of-words-where-one-would-do is an invitation for me to go on a crusade to eliminate the extras. You can't build correctly if there's a chance you're misidentifying the parts. You can't test accurately if there's a chance you're going to measure the wrong thing.

I'm not experiencing that problem right now, since I'm seven days into a new role (not systems engineering this time, but systems engineering adjacent), but what I am doing is getting warmed up for action. The best time to collect and establish the right name for each thing is now, before the confusion starts—before the confusion gets worse, perhaps, because there has never been a project of interesting complexity that has existed before the confusion starts.

Missing seasons, but not this one

When I was living in Southern California, I would say such clever things as "I miss the change of seasons". After a few years back in the Midwest, I can update that phrase to more accurately describe my feelings: "I miss the idea of the change of seasons".

Witnessing the change of seasons is an important part of life that was missing out there in the land of perpetual summer, where 15°C (59°F) meant it was time to wear a winter coat and complain about the cold. The changing of days is the most natural cycle that we witness because it hits us on both frequency and amplitude—light, dark, light, dark, day in, day out, more-or-less everywhere on the planet. The changing of seasons is the next most natural cycle—bloom, grow, harvest, rest. Or: greening, green, orange, white. Or: warming, hot, cooling, cold. It really felt like something was missing—some kind of ominous but hard to describe absence, like walking into an anechoic chamber and losing some of the qualities of sound that make it full.

Peering into this cold snap from the edge, I would trade this weather in for the "missing" winter weather. Not wanting what you have is a luxury when you can do your not-wanting in the comfort of a t-shirt.

The Captain's Newsletter, 2021-W05

The Captain's Newsletter, 2021-W05 - The long run

My mind has been drifting into the future lately—nothing specific, just wondering about what stays, what goes, what survives, what doesn't. Just daydreaming. Thinking about the future can have some pertinent side effects, like making plans to do something, but I find myself just trying to feel the size and the shape of the future. I don't know why. There is no why. The dimensions of the future aren't even useful—the contents are the useful part. We'll try to reel it all back from the future to the present, from abstractions to reality next week. Or not. Maybe we'll just see where the rabbit hole goes.

Subscribe for the long haul: /captain.

10000 year projects, 10000 year systems

Trailhead: Early project management event prep (2021-02-01) and Long-term responsibility (2021-12-03)

Following up on ideas for planning an event for the local Project Management Institute (PMI) chapter—I've got one, and I think it's a good one, and it's really stuck in my imagination all day. Getting my membership card from the Long Now Foundation in the mail planted a seed in my head.

Long Now's most visceral idea is their 10,000 Year Clock. It is literally a clock designed to keep time for 10,000 years.


As an engineer, my mind naturally turns to the question: how in the hell do you make a clock that lasts 10000 years? I think that's also a good question, so I'm thinking of this event as a pair of complementary events: one event about the technical aspects of the project for the local systems engineering professional society (INCOSE Midwest Gateway): "10000 year systems". And then the part of me that operates projects thinks: how the hell do you operate something for 10000 years? So there should be a corresponding event about how to operate the clock as a project for 10000 years, or how to plan for 10000 years of operation, for the PMI chapter: "10000 year projects".

The concept of a project that lasts for 10000 years tests the capacity of my imagination. At home, projects last from a week to a few months. In my career, I typically deal with projects that last about one to three years. (Although aerospace programs themselves last decades, they operate as numerous interrelated projects.)

10000 years is forever. It's not real. But this project is real. It's made out of metal and housed in rock in west Texas—and I've seen that rock in west Texas (not the exact one where they're building) and I know that rock has been there for longer than 10000 years, so I can somewhat ground that project in Reality.

10000 years is forever. But it's also not forever. Humans, in their current form, have been walking the Earth for longer than that. I enjoy reading apocalyptic fiction, but I believe humans, in their current form, will still be walking the Earth in 10000 years. So it's plausible. But it stretches the imagination—it's an idea that is sense and nonsense, possible and impossible, certain and unknowable.

So I'm going to organize the idea a little and pitch it to the Long Now and see if they would go for it in August. I think it would light some minds on fire. I think it would burn the tops of some heads right off. I think it's a fire worth starting.