Do you write software for a living?  Or design hardware?  Or maybe some of each?  While the particular projects any two software or hardware designers do may be worlds apart, we can characterize what we do in the same way: our work is 20% technology and 80% psychology.

Most of the work we do is 100% solvable – it “merely” requires people and time to accomplish.  It may be difficult, it may be risky, but it’s doable.  Most projects don’t require quantum leaps in technology to accomplish – current hardware and software platforms will do just fine, thank you.  Most projects don’t fail because the IDE wasn’t up to the task, or the compiler, or the linker.  Most projects fail because of the carbon-based part of the tool chain, not the silicon-based one.

All projects have some inefficiencies and problems.  They always start small but aren’t life- (or project-) threatening:

• The build process is manual and annoying, and therefore error-prone; but most engineers run it before checking in new code, and the errors are always found quickly enough.
• Code drops from external groups happen less frequently than we’d like, but it’s been okay so far.
• The external contracting team has found a few bugs in the spec, but it’s nothing that can’t be fixed later, and we don’t have time to check the spec right now.

None of these problems will doom your project on their own.  And because you can live with the status quo, you won’t fix them now.  “I’ll get to that later when I have more time.”  But as the problems multiply, build in intensity and (gasp!) start to constructively interfere with each other, your forward progress will slow down.  It will take longer and longer to do what used to be quick tasks.  Many aspects of the job will become more frustrating, and morale will go down.

Inefficiencies and problems don’t persist because we lack the appropriate technology to fix them – they persist because we lack the appropriate psychology to fix them!

That’s an important thought, so I’m going to repeat it:

Inefficiencies and problems don’t persist because we lack the appropriate technology to fix them – they persist because we lack the appropriate psychology to fix them!

How do we address the psychological aspect?  We need to trick ourselves into doing the Right Things in the Right Ways to make continual progress.

Here are two guidelines for doing the Right Things in the Right Ways:

1. We MUST make activities that are good for the project as easy as possible and as enjoyable as possible. 
   • Can your pre-commit tests be run automatically?  Yes?  Great – do it!  Make sure they run reasonably quickly, with easy to read status updates.  When the tests are done and passing, can we help the user enter a helpful commit message by supplying a list of the diffs automatically?  Yes?  Great – do it!
2. We MUST make activities that are bad for the project as difficult and miserable as possible. 
   • Checking in without passing all tests?  Okay, but you have to run this ugly command line, fill out the TPS reports on this slow web page, and get a note from your mom.  Consider making “bad activities” impossible.  Checking in without passing all tests?  IMPOSSIBLE!  Can’t be done.

Two of my favorite geniuses agree with me, so I must be right:

• Albert Einstein said, “Everything should be made as simple as possible, but not simpler.” We need to worry about making our processes as simple as possible.  Don’t worry about making them too simple, I doubt we’ll get that far.   Can you make it simpler?  Yes?  Then do it!
• Kathy Sierra said, “Make the right things easy and the wrong things hard.”  She says it much better than me – go read her post!

Of course sometimes we don’t have time to improve a process right now, because we (hopefully) have paying customers banging on the door, deadlines to meet, product to ship.  You’ve got to pick your battles and manage your time wisely.

But we geeks need to spend more time thinking about our psychology – the “how” and “why” of what we do – instead of just focusing on the technology – the “what” we do.

The earlier you find and fix inefficiencies and bugs in a product, the more time and money you save.  In the same way, the earlier you find and fix inefficiencies and bugs in the way you create a product, the more time and money you save.  But you get an extra bonus from improving the way you create a product because it produces not just a one-time boost, it produces a many-time boost!  It’s like compounding interest.  Actually, it’s not just like compounding interest, it IS compounding interest!