Technology vs. Psychology

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:

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!
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!

Semler on Urgency

Ricardo Semler says:

“The real difference between important and urgent is the difference between thoughtfulness and panic.”

From his September 1989 article in HBR, “Managing Without Managers.”

Smart Bear Software: Lightweight Code Review presentation

A couple weeks ago I saw a great talk by Jason Cohen, founder and CEO of Smart Bear Software about lightweight code review (pdf of slides).

A quick summary of Jason’s talk:

Up-front code review saves time and money by finding bugs earlier (backed up this claim with real world data).
Smart Bear has a product called Code Collaborator which “enables peer review of source code changes before or after files are checked into version control.”
His emphasis was on the process of code review rather than Code Collaborator, though he got plenty of questions about the software.
They did a big study with programmers at Cisco (“the largest-ever case study of peer code review”), talked about the results.
The most effective reviews are for less than 200 lines of code and take less than 1 hour.
- Maybe you can do 400 lines and 1.5 hours, but that’s pushing it.
Positive social aspects of code reviews:
- “ego effect:” knowing that someone else will be looking at your code may help you be a better developer immediately
- you may learn a thing or two by seeing how others code
Create an atmosphere where finding bugs is good – whether you coded them or not. Bugs found here and now are much easier and cheaper to fix (and less embarrassing!) than bugs that turn up after you ship.

Jason was truly excited about this stuff, which helped made it a great presentation.

Jason (& company) wrote a book about lightweight code review called “Best Kept Secrets of Peer Code Review” – they’re offering it free (as in beer) from their website – that book title link will take you there. I just received mine in the mail and I’m looking forward to reading it.

(Yes, I read stuff like this in my spare time. I am, in fact, a geek. And proud of it. Of course if you’re reading this far odds are you too are a geek, so you’re not surprised.) I’ll write more as I read the book.

Herding Cats at Google

From an Information Week article about Google:

“Lots of small, short-lived projects mean traditional project management software based on task lists isn’t right for Google. For one thing, techies aren’t very good at cataloging how they spend their hours. What they are good at, it turns out, is writing up a few short sentences or snippets about what they do each day. Those get compiled in a database along with periodic updates from project leaders about a team’s deliverables.”

(That link is from page 4 of 5, fyi.)

What’s more important to a non-consulting / hourly billing company – (A) tracking the number of hours employees work or (B) tracking the actual work done?

Hmm, let’s see:

(A) Tracking the number of hours worked doesn’t necessarily tell you how much work was done. It may give you a hint, but what if you’re having a day like Joel sometimes has?
(B) Tracking the actual accomplishments tells you exactly how much work was done. You know where the project stands relative to its milestones.

From a “how is the project doing” point of view, option B seems to make a lot more sense. Getting Things Done is what makes money. More hours will probably lead to more work being done, but why use a second order measurement when the first order measurement is available?

Plenty of people who are smarter and more eloquent than me^* have discussed why you can’t just measure “techies” by the number of hours they work. I’m glad Google is doing something better. Meow.

^* I’m not even smart enough to know if “me” or “I” is the right word there.

Fast, Cheap, Good

“Tradeoffs: Fast, Cheap, Good – Pick Two.”

That saying is usually depicted with a triangle – each edge or point of the triangle has one of the words on it. Kind of a binary (or ternary?) thing:

You can have Fast and Cheap, but it’ll be lousy.
You can have Fast and Good, but it’ll be expensive.
You can have Cheap and Good, but it’ll take a long time.

The simple Pick Two decision implies that your project will be lousy, expensive or will never be completed in the first place – in other words, a failure. I think the choice is not that simple – nor should it be.

Vivid Media has a nifty interactive slider graphic that is more realistic than the Pick Two scheme (and it’s so much cooler than a plain ol’ triangle, too).
Each Fast, Cheap and Good slider moves a bit up or down as the other sliders are moved – it’s not strictly an ON/OFF relationship. There is more granularity than simply “fast or slow,” “cheap or expensive,” and “good or lousy.” These degrees of choice should be considered as a continuum of interrelated options – I think this is a much better way of thinking about the “What are the tradeoffs?” question.

Edit: Niksilver.com has some interesting comments on “good.”