I came across this fantastic quote by Steve Wozniak in “Making it Big in Software,” by Sam Lightstone.  Woz is talking about designing the Apple II:

“And I did every piece of software from the ground up, through applications that you can’t pin down for any one of them.  The hardware was so interrelated that I can’t really divide it into software and hardware alone.  Those days were that way.  Today, if you work on embedded processors, you put a little microprocessor into a small product.  That’s the job in the world that I would love to this day! That’s what I did back then; it mixed both hardware and software.”

Sounds like Woz wants my job.  :-)

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!

My favorite quote (which is, itself, a quote):

“What’s so evil about general solutions? After all, your code could be both a floor wax and a dessert topping.”

He makes some great points about building software to solve a real, concrete problem, instead of building software as a semi-abstract-solution-that-could-solve-any-problem-possibly-the-one-people-are-paying-us-for.

My second favorite quote (second favorite only because it doesn’t quote Saturday Night Live) sums up the danger of the abstract:

“You put the problem at the center instead of the customer. When the customer isn’t at the center, your code loses its soul. It goes from being astounding to being adequate, from marvelous to mediocre.”

What is your goal?  Mediocre, or Marvelous?

The vendor sent two people to present – a sales guy and an engineer.

The sales guy started the pitch with an overview of the software. Sounds great, says us, but we need a bunch of technical details to know if it’s worth pursuing. This is a critical piece of software, it will interact with a lot of internal systems, and so we need to know what we’re getting ourselves into.

So we ask a bunch of questions which the engineer answers to our satisfaction. Probably 30 or 45 minutes go by, mostly a back-and-forth between us and the engineer. He knows his stuff, and he seems to enjoy telling us about their technology.

The sales guy doesn’t have much to contribute, which is fine. Or rather, it would have been fine, if Mr. Salesguy would have appeared to be paying attention, or at least not acting distracted and bored.

Instead Mr. Salesguy checks his email. Checks his voicemail. Fiddles with his pen. Fools around on his computer for a while. Does a lot of things that tell me he doesn’t care about this sale. All with a look of “Get me out of here” on his face. Which doesn’t exactly inspire confidence or help the sale at all.

What’s the lesson here? When you make a sales pitch / presentation / demo / whatever, make sure that every single member of your team is devoting 100% of their attention to the customer. Even if you’re not currently speaking, even if you’ll never speak – act interested! Better yet, BE interested! And if you can’t get interested, then you probably don’t need to be there in the first place.

1. You think you’re an awesome programmer.

2. But no one else has ever told you so.

3. You’ve never looked at old code you wrote and thought, “Ewwww! That is horrible code! What was I thinking???”

4. You’ve never looked at someone else’s code and thought, “Dang, whoever wrote this is a freaking genius.”

Note that this also works if you substitute <other profession> for “programmer,” and <output of other profession> for “code.”

If you don’t see growth, it probably ain’t happening.  If you don’t see growth potential, it probably ain’t happening either.

1. Rands’ recent post on “Saving Seconds” really resonated with me. I forwarded it to my wife and said, “See, this is how I think!” so that she could better understand why I optimize the shortcuts on our PC, or the way I load the dishwasher, or the other thousand seemingly-OCD-inspired things I do. (Thankfully she understands me very well already!)

2. I think it’s incredibly important to be good to “the environment.” Whether you believe in the global warming story or not, it needs to be done. I recycle everything possible (and I got really excited when I found out that Ecology Action, our local recycling place started recycling #3 – #7 plastics!), am a vegetarian, use reusable grocery bags (and don’t use individual plastic bags for bagging fruit or veggies), use BioBag compostable trash bags, and the list goes on.

3. Joel’s “Fire and Motion” post also resonates with me. Forward progress, even if it’s just a tiny bit of progress, is good. And necessary, in fact, to getting anything done.

If your goal is to save the Earth it’s easy to get overwhelmed because you can’t do it all yourself. What possible difference can a single person make? There’s too much to do!

If your goal is to improve some software or improve a software development process itself, it’s also easy to get overwhelmed because you can’t do it all yourself. What possible difference can a single person make? There’s too much to do!

Guess what? Maybe you’re right. Maybe you can’t save the Earth by yourself, or single-handedly improve the festering swamp that is your team’s software development process, but there is something that you can do – you can take baby steps.

Recycle something. Get a reusable bag or two for your groceries. Turn off the lights when you leave the office conference room. Ask a coworker to look over your code for bugs before you checkin a change. Create an automated test suite for your software, start with a single “does it compile?” test.

It will require an intentional change in your thinking and behavior to do these things the first time, and the second time, and the seventh time. But soon enough doing a little bit extra for the environment or your software will become a habit, and those small bits of effort will add up into something meaningful over time.

And you will be motivated to keep adding more good habits over time because you will see the internal (“Yay! I feel better about myself!”) and external (“Yay! I found a bug!”) benefits from those habits you’ve already adopted.

And as you develop those small habits, you will be noticed by others around you who may even join you in small improvements – “viral marketing” at work.

Joel’s “Getting Things Done When You’re Only a Grunt” post has more software development improvement ideas.

http://science.howstuffworks.com/save-earth-top-ten.htm has a few Earth-friendly things you can do.

I’m a fan of both of those guys (I even have an autographed copy of Joel’s book!), so I signed up to be a beta user to see how it develops. I was trying to come up with a good way to give Stack Overflow a test drive, and I think I’ve hit on something: use it to build a web 2.0-ish site. I’ve been wanting to build a site for myself for at least the last year – I can picture it in my head (and on paper), what it should do and what the user interaction should look like, but I haven’t spent any time actually figuring out how to build the darn thing.

You see, I’m comfortable in C/C++/Perl/Python/x86 assembly (really), but I’ve never done any database or web-y development. Enter Stack Overflow – hopefully it will be a good place to learn about web programming.

I’ll update this blog with my progress once Stack Overflow goes live, wish me luck.

And Jeff: Give me a call when you decide to learn C, I taught it at Purdue for a few years back in grad school and really enjoyed teaching it – maybe you could trade me some .NET lessons for some C lessons. You check my post on pointers to get started. :-)

Thanks to Chris Jones for writing about a very interesting talk by Aza Raskin:

Video: Away with Applications: The Death of the Desktop

You should check out Chris’s summary, and the video as well.

This is one of the few videos I’m glad I watched instead of just ripped to mp3 and listened to – a lot of visual stuff, well worth the time.

“Sure you gotta go fast, but if you’re not getting feedback to figure out if you’re going in the right direction it doesn’t matter how fast you go.” (2:47 in the video.)

That advice can apply to both technology and the business sides of a company, but here Norvig focuses on the feedback necessary to make sure the technology you’re developing succeeds.

He suggests you can get this vital feedback by:

“Acquiring lots of data [and] running machine learning over it… The key here is that no matter how agile you are as coders, and I understand that you’re all great, data is going to be more agile than code. Because you’ve got to right the code yourself, but the data you can leverage… there’s an immense multiplying factor that way.”

I guess this Lisp/AI guru from Google knows a thing or two about using lots of data, eh?

He goes on to describe how Google has used machine learning over large data sets for their image search, text segmentation and Google Sets. It’s a great talk, I highly recommend it.

I like the idea of letting the data and algorithms do as much of the heavy lifting as possible – the knowledge I want to share with my users may already be in the data, I’ve just got to dig it out!

“Still, I hate to duck your questions even though I also hate to offend other people’s sensibilities—given that software methodology has always been akin to religion. With the caveat that there’s no reason anybody should care about the opinions of a computer scientist/mathematician like me regarding software development, let me just say that almost everything I’ve ever heard associated with the term “extreme programming” sounds like exactly the wrong way to go…with one exception. The exception is the idea of working in teams and reading each other’s code. That idea is crucial, and it might even mask out all the terrible aspects of extreme programming that alarm me.

I also must confess to a strong bias against the fashion for reusable code. To me, “re-editable code” is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.”

There are only a few people who can get away with saying that and actually have people listen to them – and Knuth is definitely one of them. I would love to hear him expand on the “terrible aspects of extreme programming.” If he had an email address I would ask him about it, but unfortunately he doesn’t.