Wandering off. Spinning down. Fading out. My projects here have a habit of that. What does that say about me, about you, and about our work? And krill? Really?

Some of my projects here have become fairly complete. At least one of the SpaceWar implementations was rather complete, and Asteroids got fairly well polished, and even Space Invaders was pretty solid. But I’ve abandoned quite a few things here, including Sudoku, and recently the Dungeon program after only a couple of hundred articles.

Da Vinci supposedly wrote:

Art is never finished, only abandoned.

I make no claims to art here, but I’d have to raise my hand when the speaker asked “Has anyone here ever abandoned a project?” Back when I was working for a living, building and managing software efforts, I was famous among my crew for losing interest in efforts before they were finished. It always seemed that once all the big problems were solved, and it was down to the long slog from nearly good to shippable, I would wander off and become interested in something different.

I’ve learned a big lesson from that, too late to do me much good:

In the first days of a software effort, produce a running tested skeletal version of the product, and keep it working, and growing, shippable from that day forward.

Had I done that, the course of my career would have changed, and we probably wouldn’t be here now, sipping our beverage and thinking about stopping projects. But my life has been good, and I hope that yours has, so I would not go back and edit history even if it were allowed1.

In this article I want to explore the ramifications of our efforts being abandoned, in particular but not limited to whether my history here of abandoning projects is good, bad, neither, or both. The point, of course, is my standard set of reasons for writing these articles.

  1. Entertain myself;
  2. Entertain you, and possibly give you something to think about.

At this stage of my life, I am privileged to be able to spend my time pretty much however I wish. I’m too old to employ, and have managed somehow to save enough money so that I can afford cable Internet. So here I am. I truly write these articles to entertain myself, to explore ideas that I find interesting.

And enough people have expressed interest in what I think to cause me to publish them, on the off chance that they’ll be interesting–and I hope somewhat valuable–to some readers. I’m not saying you should do as I do, even though I do think that sometimes I do things that are worth learning and doing. I’m just saying “I did this. Look what happened. Think about it. Laugh with me. Go forth and do as you see fit.”

Programming

Most of what I like to think and write about is programming, in particular but not limited to the creation of object-oriented code that does interesting things. I enjoy working with code. Like other folks, not every line of code that comes out of my fingers is really good. And then, often but not always, I am able to think about that code, and with fairly simple manipulations, make it better.

Better

Better by my standards. Your standards may vary, but whatever they are, I’d bet that your first cut isn’t always up to your standard, and I’d bet that some “fairly simple” manipulations could make it better, by your standards. And I hope, oh my do I hope, that you care enough about your work to want it to be good, by your own standards.

So we get to think about standards of quality, and changing code to be more like we would like it to be.

Good Enough

So long as my current project offers me interesting things to write about, I continue to work with it. I got over 200 articles out of the Dungeon program, but now it’s more irritating to me than interesting, because I’m not enjoying the conversion to a Hex map. It seems to be working, but it’s tedious. Maybe there’s a lesson there and maybe I’ll go back and try to learn it.

At some point, my current project no longer offers interesting things to work on. The results of the work, more the articles than the program itself, are good enough. I go off and search for something else to begin, something to craft for a while.

But there’s an important lesson here. I referred to it above and I want to hammer on it a bit more now.

When is a product “Good Enough”?

A product development effort always comes to an end. It can end in a number of ways.

Done

In principle, it could actually be “done”, having completed all the planned elements. In principle it could even be on time and on budget. That I’ve never seen that happen does not imply that it’s impossible.

Good Enough

The effort could be “good enough”. It could have reached a level of capability and quality that makes it fit for its purpose, such that the next proposed changes to it do not seem worth the effort. I think this is a fine result. We’ve accomplished something and further investment will not pay off. Time to do something new.

Cancelled

Sometimes–too often–efforts get cancelled without delivering anything of value. The effort just fails. I have a number of product failures of this kind in my past, and every one of them would eat at me, if I were the kind of person who lets past failures eat at him2.

Good Enough is Just Right

Of these, I think that “Good Enough” is a marvelous outcome, since “Cancelled” is terrible and “Done” is at best unlikely. If you can do it, great. Send me a link to your articles: I should read them. But seriously, if we can invest some time and money and wind up with a result that is “good enough”, that should mean that our efforts were rewarded in terms of money, pleasure, or whatever other benefits the effort provides.

In software, you could argue that the point of an incremental approach to product development is to allow us to get to “good enough” in a fashion that tends to pay its way, and that tends never to tip over into “Cancelled”. We build that working bit and we add to it, we keep it nice and well-factored, we keep the code alive, and we make it shippable as soon as possible, and ever after, until one day we say “good enough” and move on.

You could argue that. I do in fact argue that. Often ad infinitum.

My Projects Here

I choose projects here that seem interesting, and that seem likely to cause me to learn something (or relearn it, since I often seem to need to learn the same lesson quite often). Then I code a bit, think a bit, all while writing. I make mistakes, no need to fake those let me assure you, and discover them. I try to figure out how to avoid those in the future. Sometimes I manage that. Often I do not.

I call this approach “warts and all”, and I started it years ago, probably when I was writing my Adventures in C# book. (Do not buy it, it’s well out of date.) I want to show what my real experience of programming is like, rather than some carefully refined fake experience where it seems like I always type in just the right thing for the next step. Real programming isn’t like that. Real programming includes plenty of mistakes, missteps, and trouble.

I like to think that folx should see that even very experienced programmers make plenty of mistakes. I like to think that sometimes I learn from my mistakes, and I hope that readers look at them and figure out how to learn from theirs (and mine, if they can), and so make their programming lives a bit better.

Or, maybe it’s just good for laughs. That’s OK too.

Things Have to End

Most things come to an end3. Software products either ship or not, but sooner or later we stop investing in them. Hobby projects get done and we move on to another one. Sometimes events just happen and we’re forced to move on before we would choose to.

You can find plenty of advice out there about how you should set goals and then work to achieve them. I’m not here to say no to that, but I would like to offer some notions about the kind of goals we do well to select. I am probably particularly bad at goals and I think that makes my offering here particularly … significant … irrelevant … odd …

Consider the goal “I will go to Iowa State and graduate as an engineer”. If it turns out that you hate being at Iowa State and that engineering isn’t for you, you’d be mad to continue to attain that goal and yet disappointed if you were to bail out and do something else.

Compare that to the goal: “I will attend school to learn interesting things, to learn how to learn, and to discover work that I can do well and enjoy doing it”. Here you could work through a half dozen universities and programs, then stumble accidentally into a job that offered learning that you found fascinating, leading you to a wide range of jobs and to a life filled with interesting people and ideas.

So far, the joy I have found in learning, the joy I’ve found in programming, the joy I’ve found in working and being with good people who share my values, has never ended. Sometimes the joy has been low, sometimes high. Sometimes I’ve made choices that reduced my own joy, sometimes choices have fallen my way that led me to more joy.

Goal: Joy

Sometimes, when things didn’t seem good, I stopped doing what I was doing and did something else. I didn’t have to “fail” at my goal: I found a better path to it.

I often describe my life strategy as trying to swim where the krill seem plentiful and tasty. I’ve sought learning, the joy of creation, the joy of working with people who share my joy.

Our projects have to end. Drawing joy from our work is often possible, and almost never has to end. I think that if we swim wisely, the krill can almost always be plentiful and tasty.

I wish you such a life. Maybe a few little hints for it can be found here.



  1. There is a simple proof that a machine to travel to the past and change it is impossible. If there were such a machine, it might or might not have been invented. If it were invented, people would travel to the past and change the future. Some of those changes would cause the machine not to be invented. Those are the only stable points in the change loop. Therefore the machine is never invented because whenever it is, some fool changes the past to make it uninvented again. 

  2. OK, so sometimes, I do think about them sadly. But my life is good, so I wouldn’t edit the past if I could. See above. 

  3. I suppose that one day, we ourselves have to end, but forgive me for not wanting to think about that much just now.