Incrementalists & Completionists

I recently got into minor war of words with a co-worker regarding the proper solution to a problem with one of my products. As an aside, let me say that email is never ever ever never ever the right way to resolve controversy. Too much subtly is lost when you’re YELLING IN ALL CAPS. Don’t waste your time solving problems in email… stand up… walk down the hall… and look the person in the eye. You’ll live longer.

ANYHOW.

What was intriguing about my email repartee with the co-worker was that we weren’t disagreeing about whether or not we should do something about the problem. We’re arguing about how much we should do. The disagreement reminded me there are two distinct personalities when it comes to devising solutions to problems: Incrementalists and Completionists.

Incrementalists are realists. They have a pretty good idea of what is achievable given a problem to solve, a product to ship. They’re intimately aware of how many resources are available, where the political landscape is at any given moment, and they know who knows what. They tend to know all the secrets and they like to be recognized for that fact.

Completionists are dreamers. They have a very good idea of how to solve a given problem and that answer is SOLVE IT RIGHT. Their mantra is, “If you’re going to spend the time to solve a problem, solve it in a manner that you aren’t going to be solving it AGAIN in three months.” I used to think that architects were the only real Completionists in an organization, but I was wrong. Architects are the only RECOGNIZED Completionists in the company, but the personality is hiding all over the place.

Rewind to my email situation. The actual problem is irrelevant, but here’s the background. The co-worker discovered a problem in our product and reported it. I responded and suggested an minor improvement which didn’t solve the core problem, but was achievable given our schedule. The co-worker responded with “Why do this if we don’t solve the problem”. I responded, “We don’t have time to solve it and something is better than nothing.” Co-worker, “This is less than nothing!” Insert stunned silence.

Remember, the co-worker identified (correctly) the original problem. Why in the world don’t they see the value of my solution? The reason is, this is a Incrementalist doing battle with a Completionist. This isn’t the battle of wrong versus right, it’s the battle of right versus right. Bizarre.

How does anything get done with Incrementalists and Completionists arguing about degrees of rightness? Well, first, limber Incrementalists can switch teams. They’re opportunists and when they see that acting like a Completionist is a good move and, more importantly, it’s an achievable move, they’ll step up to the Completionist plate. Once they’re there, it’s likely they’ll engage a Completionist to do the heavy lifting, but the Incrementalist will drive because THEY CAN SEE THE PLAN FROM SOUP TO NUTS. This is a big deal for Incrementalists because they normally can’t see past their next meeting… getting them on-board with the “big picture” gives them a sense of foundation they don’t usually have.

Conversely, effective Completionists know when to let the Incrementalists poke around and do their thing. Completionists recognize where this Incrementalists with their rapid-fire buzz-speak fit into the corporate culture and they embrace their mania because they know it’ll help with their Completionist agenda. This, too, is a big deal because Completionists spend much of their lives shaking their heads, staring at the floor, muttering, “Boy, could they fuck this up more?”

A healthy population of both Incrementalists and Completionists is essential to a corporate agenda. It’s not only because they both represent groups that “get stuff done”, it’s also because they are going to argue, but it’s the argument you want your teams to have. It’s not “Should We or Shouldn’t We”, it’s “Let’s do this thing, let’s make sure it gets done, and let’s make sure it get’s done right.”

Related

38 Responses

Incrementalists and completionists, otherwise known as the happy-go-lucky and the anal-retentive. In construction circles I imagine they’re referred to as renovators and demolitionists, respectively. In terms of car ownership, there are repairers and replacers.

I get it! Instead of the expensive, unrealisitic Completionist solution (setting up an new, expensive Marshall-style plan to rebuild Afghanistan and the Middle East), we take the Incremental approach, scattering the Taliban and knocking off the top 52 guys. The problem goes away for ten years, and then we get to deal with it again. But at least the problem was taken care of this decade…

I think you’re oversimplifying and presenting an Incrementalist-biased point of view.

There’s Incrementalists, Completionists and Realists.

Realists probably started out as one of the other more extreme camps and are likely still biased to some degree or another towards one or the other, but realize when the other approach is more appropriate.

I think both extreme Incrementalists and Completionists in total isolation will simply never get anything done.

I’ve seen what happens with extreme Incrementalism: it’s all about getting the current task done and nothing else, and eventually the little incremental things add up and there’s an overwhelming quantity of little tasks, many of which are lengthy and very similar.

With extreme Completionism nothing gets done because every little task, even if it’ll only happen once, has to be engineered into something that automatically handles every detail of that task perfectly in all cases. This leaves the extreme Completionist working for days on every little 5 minute task.

With time and suffering, either one will mature and realize that sometimes this approach is wrong. The Incrementalist in particular will suffer the pain of doing the same stupid task repeatedly and (hopefully) learn to automate something or fix the underlying problem after doing the same thing the tenth (or hundredth) time. The Completionist will get flack for never getting anything done and will see their growing pile of new and different tasks that won’t be solved by the current project and will find themself forced to sometimes cave in and just do the 5 minute task.

And without a strong influence of some true middle-of-the-road Realists, the best thing is to have Completionists and Incrementalists, complete with the periodic yelling.

In your example, I suspect that perhaps the best solution is to make the small fix now and add the proper fix to the TODO list for the next major release. Or at least in similar situations I’ve encountered that was the best approach. (Obviously none of us random readers can know, since there’s insufficient details)

I wrote a game back in high school (1990). At the time, I hadn’t gone through the college courses advocating proper design and software engineering practices. I wrote the whole game in a summer. After I took those courses, I tried writing another game. After several years, I gave up. That got me questioning everything.

Lately I’ve been thinking about this issue again, although I didn’t have a good way to expressing it in words. Part of me wants to complain about all the wasted effort of doing little things that later are thrown away or undone. And part of me is looking around at the projects around me and seeing that the incrementalists are getting a lot more done than the completionists. Dynamically typed vs. statically typed languages; extreme programming vs. design up front; rapid iteration vs. careful coding; copy/paste vs. building interfaces; …

Something all of this reminded me of — when I’m playing SimCity, I get very bored when I plan the whole city in advance and build it all. Doing a little at a time with less planning tends to keep me playing longer. I wonder if it’s related.

There’s an old saying that encapsulates this point: “don’t let the best be the enemy of good enough.”

I disagree that only incrementalists can see the big picture: on the contrary, completionists see the big picture, and get hung up trying to fill in all the little details, or just get overwhelmed by the size of it all.

Anyhow, useful point–there’s a time and a place for both approaches, and it helps to recognize that they both exist.

Now, in the same area of overall design goals for your software, I’d like to talk about engineering itself.

For me, as an engineer, one of the uncomfortable truths is that the technology doesn’t really matter. I hate that fact. It annoys me in the depths of my soul. But, I submit to you that if there’s anything that we should have learned from Microsoft and Windows over the past two decades, it’s that the technology barrier to the marketplace is lower than we’d have believed possible. Surprisingly enough, it turns out that people don’t care as long as the technology mostly works and they can get their jobs done most of the time.

I almost entitled this part of the talk “Don’t Focus on Technology”. Unfortunately, for most of us in this room, that’s the *fun* part of the job. But the bottom line in the marketplace is that once the technology is “good enough” then any engineering work that you do after that time is fun, interesting, and good for the soul, but it won’t matter a bit in the marketplace. And, I want to make it clear that I’m talking about the marketplace of ideas here, too, not only the jingle-jangle of the money. “Good enough” is the most important engineering number, and you ignore it at your peril.”

Technology really doesn’t matter. I learned this rather disappointing fact when they were trying to finance and eventually sell my prior company. Whenever the due diligence teams from banks and venture capital firms would show up, I got all excited… “Hey! I get to talk about all our cool crap! I get to give demos!”

Invariable, my talk/demo would show up… usually late in the day.. and the now exhausted due diligence team would only show minor interest in EVERYTHING MY TEAM HAD BEEN WORKING ON FOR THE PAST TWO YEARS. WHAT.

Having recently been playing SimCity, this observation resonates with me. I think that if you are wondering whether you are a Incrementalist/Completionist… just sit down w/ SimCity for a few hours and you’ll know.

In related news, I’m certain there are NADD-identification techniques which could be used with SimCity, as well.

As a recovering completionist, I recommend “Extreme Programming Explained” by Kent Beck. The relevant idea is not to fear having a little work to do in three months to such a debilitating extent that you have to overload yourself with work RIGHT NOW to prevent it.

Errrgh… I’ve had to deal with this recently so, as my volume of text shows, it’s a bit of a hot-button. The article is definitely biased in the Incrementalist approach, which is understandable, it’s a comfortable place to be for many developers. It portrays Completionists as inflexible, which for the audience (coders, in general) has clearly negative connotations. It’s a bit like saying, ‘I’m a Python programmer, so Python programmers must be better programmers than others!’

Perhaps I’m contributing to that, by saying, ‘I believe I have tendencies towards both, so I think that all engineers should have tendencies towards both’. But at some point, I suppose, you have to stick a stake in the ground, and say, ‘Darn it, things just aren’t meant to be monochromatic!’

As a ‘madwand’ programmer, one who came to it very, very young, and grew into it, I know I (and I think most people like me) started off Incremental, and eventually learned that it builds an unyielding mess, learned refactoring (although it was just called ‘cleaning up the code’ in that mythical time referred to as ‘in my day’), and moved on.

Then, if you ship enough ‘band-aid’ fixes that break as soon as the code flexes a little more, you start getting the serious urge to NOT ship until you know the ABSOLUTE bottom reason for something, even if you don’t *fix* it, you KNOW why it’s broken before it ships.

I can’t count the number of times people have said, ‘We’ll ship with this fix, it works around the problem…’, and I’ve had to ask, repeatedly, ‘Do you know what the core of the problem is?’ The sadly inevitable answer is often, ‘No, but this patch seems to fix it, so we want to ship the patch.’

In truth, if you never do it right, you’ll never be sure where it’s going to break next. The other side is that if ‘doing it right’ means you never ship, it doesn’t matter where it’s going to break next, what matters is where your next meal comes from. 🙂 Yes, there is a balance, but it’s not in the number of each type in the company (if you limit it to the proposed two), the balance has to be in every single engineer.

Again, limiting it to the proposed two types, in the first phase of a project, every engineer needs to be a completionist. If you’re not at least TRYING to do it right when you’re starting a project, or when you’re starting the next rev of a project, when you have a clean schedule to define, then you need more seasoning before you try to ship commercial products.

In the end phase of a project, when the product fundamentally works, every engineer needs to make the judgement ‘Can I fix it RIGHT in the time I have, is it a WONTFIX, or do I know enough about the problem that I can avoid it with a patch?’ If you can’t fix it right, but you don’t know what the underlying problem is, hacking around it is a BAD (Broken As Designed) thing, it should be marked as something that won’t be fixed, and stuffed in the product notes. (‘Sometimes you have to shoot the engineer, and ship the product.’) If it’s so critical that the product isn’t worthwhile without it, then it’s critical enough to at LEAST understand the core reason it’s breaking before applying a band-aid.

Like most programmers (I believe) 90% of my work is modifying the structure and design of existing code, whether my own or someone elses. Most of this is incremental improvements. If you don’t keep a ‘complete’ picture in your head while making incremental changes, the result is a mess. If you don’t see how you can get to your image of the complete picture without massive or complete rewriting (see: Joel on Software vs. The Rewriters, Season 1, Episode 5), the result is a mess.

The balance is within each engineer, to make the decision when to insist on the Right solution, when to insist on the Right Now solution, and sometimes when to punt.

I see someone has finally linked Worse is Better. (Read it.) I tend to be very completionist, which is why I still haven’t done anything interesting. I strive to learn how to be a better incrementalist.

I think you can view it as a question of how far ahead to set your planning horizon. (Very difficult question which requires you to know many things about the situation and your goals. See? I told you I was a completionist.)

> I responded and suggested an minor improvement which didn’t solve the core problem

You answered your own question. If you were so close to a deadline that could not be moved in order to solve the problem he found, then it is a release notes candidate, to be fixed in the next version. Doing extra work which doesn’t solve the problem is just that – extra work. What is more, it is extra risk because it might create more extra work in the form of bugs.

Sometimes the entropy in software makes selectively rewriting certain sections more cost effective than patching them. This is where sometimes Incrementalists fall down, as they often will not invest the rewrite time to bring the costs down. Completionists fall down when they expand the scope beyond where re-writing is cost effective. The balance is sometimes difficult to figure out ahead of time.

I’m not a SimCity player, but I am a Go player. In Go, especially among weaker players, you have this same sort of split: do you keep fighting in the same area (common with beginners), or you do you take off and go find a bigger point to play? If you stay too close to either side, you’re going to get beaten a lot.

There’s a lot of territory on the board, and if you keep playing in some region to make it perfectly safe, your opponent is going to cede some territory there, and strengthen his own influence elsewhere. (If you spend 6 weeks making the Foobaz feature perfect, your competitors are going to make a good Foobaz feature and also a good Barbar feature.)

I give Go a lot of credit for helping me to figure out when good enough is good enough. And that’s hard for a Completionist like me. 🙂

I encounter this about twice a week. A customer has a problem with the product, and a developer (incrementalist) has a solution for them, but a management-type person (completionist) will step in and talk about bigger pictures and working smarter. In the worst case, the completionist throws himself in front of the train and holds everything up – all the while being firmly of the belief that he is “helping”.

If the incrementalist has done her homework, she may conclude that it would be nice to redesign everything in one go to solve a whole swathe of problems at once, but that this is a risky thing to do right now (or ever), and instead the sensible approach is to incrementally modify the product in stages until it reaches nirvana and we can all retire.

So the way forward in these situations is to talk to the completionist in their own language – draw a grand picture of how the system will work when it is all done and perfect, then draw up a list of milestones that will get you there and scribble some provisional dates on them, and the first milestone happens to be the very thing that this customer needs next week…

>The disagreement reminded me there are two distinct personalities when it comes to devising solutions to problems: Incrementalists and Completionists.

Really? I consider myself someone who could advocate either approach depending on the situation (deadlines, etc). I think you can accurately say that some people lean more towards one approach than the other, I’m not sure that I’d agree with the statement that Incrementalists and Completists are “distinct personalities”.

There is a similar distinction in the way people look at knowledge and the world, which as been described as “packers and mappers.” Packers view the world in terms of packets of information, where success is finding the right packet in your bundle. Mappers see information as woven into a map; accepting new knowledge often means redrawing all or part of your current map. For more, see the discussion on “The Programmers Stone” and other writings at http://www.reciprocality.org — some interesting reading. Its not that one type is necessarily better than the other, both have their good and bad points. But there is a definite correlation with “doers and thinkers,” who traditionally think each other the weaker.

Another consideration is the variations on the Pareto Principle or 80/20 rule. Originally, “80% of the results only consume 20% of the resources; the remaining 20% of results is what requires 80% of the resources.” This directly applies to your inevitable defect list. A similar phenomena is that 20% of the features are used by 80% of the people, and people only use 20% of the features. So, you can patch 80% of the problems because they are actually rarely used by a few customers. However, you’ld better recognize when you get the bugs in the critical 20% that you really fix it; for example, if there’s a problem in saving a document after you edit it. Unfortunately, sometimes people get things mixed up about what’s the more important to deal with; the fact that 80 of the usage is one type of work doesn’t mean you should optimize it, if its only consuming 20% of the time, effort and resources.

I definitely see something between Incrementalist and Completionist. Like most categories, they’re not necessarily the antithesis of one another. Down at the base level, every incrementalist becomes a completionist for their little aspect of the system.

In all projects I’ve been on you’ve needed both. You have to see where you’re going and have those people guide the design and implementation, as well as those purely focused on the problem/feature/fix of the moment.

However, I do agree that there are many completionists who strive for the perfect solution for all foreseeable permutations in the future. Given Software is quite maleable I cannot see an Architect being able to see much beyond 2-3 years of releases. In fact, I wish more Architects would realize that the Architecture should evolve as the system evolves.

Ironically the best systems I’ve seen have come through a more incremental approach after 3 or 4 releases. Mostly because they’ve employed excellent refactoring as patterns were found in the code to re-design aspects to make more of a framework out of the original code as features were added.

Completionist is Myers-Briggs N type (intuitive). They put value in the abstract mental model. For them, the most “right” solution is the one that is the most logically complete.

Incrementalist is S type (sensory). They put value in what is happening in the real world around them. For them, the most “right” solution is the one that has the most benefit in the social/political/human context of the business.

I used to be Pure N, then mainly N, now more N-S. Idealists start off as N, but real life wears them down and the underlying S starts to emerge 🙂

I reckon it’s best to be Completionist in the small, atomic parts of a system upon which everything else is built, and Incrementalist in the large, where one is building the whole system out of the smaller parts.

Iterative vs. Big-bang does not have a one-to-one mapping to Hacker vs. Perfectionist, which is part of what the post seems to imply.

I don’t know who Rands is, but he sounds like many cowboy types I’ve worked with that would collapse under the weight of their own shortcuts if left unchecked. Instead of learning to reign himself in, he depends on those despised “completionists” to be the parent when necessary (although most of the time it’s unnecessary, otherwise maybe he should change his ways).

It sounds like his co-worker identified Rand’s hack as something that would add more entropy to the system than it removes and recommended against it. Some compromises are good, and some do more damage than they fix. Cowboy types are typically blind to the latter, instead relying on the “thrill” factor of how it felt to come up with the shortcut as the determining factor on whether they should go ahead with it.

Cowboy types also don’t tend to learn from their mistakes very well. Their whole philosophy in life seems to be “mistakes won’t catch up with me cuz I’m too fast”. These are the guys who claim they’re done with a feature a couple weeks early and then spend those weeks fixing “bugs” that they admit they knew about. They also tend to be poor estimators. The more common scenario is claiming “I’m done, right on time!” by pulling some last-minute stunt and then spending a few more weeks finishing up in testing.

Bah humbug on the Rands of the world. Give me a realist (or even a completionist) any day.

I think I am an Incrementalist when dealing with problems that require team effort, but slip into Completionist mode when it’s just me solving a problem. It’s something about rolling up your sleeves that draws the Completionist out. And it’s often a pleasant surprise to see that the Completionist approach turned out to be realistic as well.

Or from a slightly shifted perspective, I’d say Incrementalist at the macro level, but Completionist at the micro level — perhaps it’s nothing to do with team vs individual.

We have a continuous spectrum with incrementalists on one side and completitionists on the other.

Incrementalists are claimed to be the realists ones. The have a pretty good idea of what is achievable. They consider the social, political, human and economic factors of the software development context.

Problems with them are they are short sighted. They do incremental little things that may add up and overwhelm them, creating unyielding messes.

Completitionists are claimed to be the dreamers, the idealists. They can see the big picture as an abstract mental model which needs to be perfectly complete and solved right.

Problem with them is that they struggle at doing things. Every little task has to be engineered to handle every single detail perfectly. Result, they never get things done.

As many people here, I think there are not 100% incrementalists or 100% completitionists. We can move to one or the other side of the spectrum depending on the situation. Incrementalists and completitionist are just constructs created to give an idea about the skills needed to confront different type of situations. I

What mother of five could be more than an incrementalist? I have been cleaning my house for more than 27 years, in increments, with the profound knowledge that eventually the children would grow up and leave and everything would finally stay clean. With four children grown, and one teenager still at large, there may only be 2500 wash loads left. You see, I was right.

I’m a completionist who is too intimidated by the size of my visions to get them done. A completionist who never completes. Never starts, in fact. Where do I go from here? Does anyone know of ideas if how to acquire the habit of tackling things in bite-sized chunks?

There is no “being incrementalist is better than being completionist”. Your project will be lost if you don’t have both and even more if you don’t have both talking to each other.

Its no question: the incrementalists will do the quick fixes that a client might need NOW. Thus incrementalists usually work on small chuncks of the code but on chunks that are spread all over the project. Thus they usually achieve a better overview over the whole codebase.

In an ideal world there must be frequent sessions where all coders (and quality assurance guys) go through the quick fixes and find out which ones need a broader and more detailed rework. This cannot be done with all quick fixes unless you have 10 times more completionists than incrementalists.

So good projects have an incremetalist at the coding front and some hopefully very bright completionists in the offices behind.

Well, for me as a more completionist thinker its hard to place me in the backoffice. But life seems to be like that. Life rewards action and speed. It simply sells better, if you can shout “done!”. Your newly introduced bugs give you the chance to shout “done!” even more frequently. Managers love this. Its easy enough for them to understand.

Pick up Jane Roses advice and clean your house yourself. If you are a completionist you will live in a mess most of the time until you can allocate a whole weekend to do everything in a perfect way.

You quickly learn to only vacuum clean one room today and wipe the mirrors the next day, everthing in only 3 minutes. Nothing will be perfect at any time then but the overall result will be quite good.

I think that discussing only this 2 dimensions of one’s personality leads to a very limited discussion.

A great programmer with incrementalist tendency in his perspectives can get a lot done in a short time, but also a great programmer with a completionist perspective can make solid work and can do it in a way that re can really finish things.

My opinion is that most code has a brief life, so spending too much time in a code that will be thrown away in 6 months isn’t going to get you anywhere. You need a very good sense of what’s important, what’s the heart of your application, and make it as good as any completionist would dream of. In the other hand keep an incrementalist aproach to the everything else, and if it’s really good and people really use it can always be improved.

PS: Useless: just noticed this huge gap between comments, from early 2005 to mid 2007

Great article, even four years later. I can relate so well to the descriptions partially because I’ve found myself in both positions so often. I wonder however if it there is a small or even a large correlation to how long you’ve worked on a problem. On any given project most of the old timers will want to take the Incrementalist approach and most newbies will want to take the Completionist approach. I have rarely ever met a programmer that didn’t want to rewrite from scratch the project he just joined. It’s also common for the people working on the same project for years to want to maintain the status quo and only make small incremental changes. I been in both situations myself and witnessed this dozens of times.

I don’t fault new members for wanting to inject new ideas in. Older members often get stuck in a rut and forget to think out of the box sometimes. Many of their assumptions in the past don’t apply anymore and it’s essential to reevaluate sometimes. It’s also the case the the old timers know how the company works. They know the pitfalls in the technology, in the business requirements, and and other dependencies. The newbies often turn out to be naive dreamers that just waste everyone’s time.

I agree that the balance is essential though. Old ideas must be tested and reevaluated periodically. We also have to avoid the pitfalls of always rewriting everything all the time. The times when companies have failed is when one group becomes two strong: either no change ever occurs or the baby is thrown out with the bath water.