Aaron's Thoughts

(from TDD entry on Wikipedia)

In the programming world there's this school of thought called Test Driven Development. The idea is basically that if you were going to write a piece of a program you'd start first by writing a test that would verify that it works. Then, you'd write the code and try to get it to pass the test. Let's say it's an adding calculator, so the first thing you'd write is not the code that adds two numbers together, but a test that would verify the results of what you are about to write. Your test is that you'll pass it "1" and "2" and expect the result to come back as "3". Next, you go and write the code that does this. The advantage of this approach is that the test cases drive the implementation. Plus, you continue to use all the tests you write. So anytime you make a change anywhere in the app, all the tests fire as verifiers that you didn't break anything you weren't aware that you broke.

It's a good practice in programming, but I think this is also a great metaphor for startups (and even goals and ambitions elsewhere in life). I've just started working out of a great new co-working space called 3rd Space and have the pleasure of being around some great people, some doing startups, some doing apps, design, marketing, etc. I met a new friend here, Kevin from Fashioning Change, who has solid startup failure and success experience. He engaged me in a great line of questioning the other day. I was showing him a quick proof-of-concept of an app idea that I had made just to test out where the rough parts of developing it might be. I'm integrating 3 services in 3 different programming languages, so I just wanted a quick test if all that was going to work.

Kevin looked at me, excited to show him the programming, and focused me back on the product design. "OK, so back to the idea -- what are your unknowns? What do you need to know in order to say that this is going to work?". Hmmm, I thought about it for a second. I listed a few things that the users would do with this app, over a period of weeks and months. If they did it, that's a success. "OK", he said, so I think you have enough here to test that, don't you?" I resisted a little and let the excuses fly: "The UI is almost non-existent, the color scheme is black on white, the layout makes no sense, the authentication flow is terrible....", I continued. "Well, then just get 5 people you know. If you can't get 5 friends to use it, whom you can show it to and explain it, then a better UI for people you don't know isn't going to help. You just need to test the idea". 

Wow, this caught me totally off guard. In my mind what I was showing him was just scratch-paper quality code. This is the napkin doodle before the sketch, before the color markers, before you open the box of brushes and paints. But he's right, and he helped me define the test cases that my idea needs to pass. If it doesn't, then it needs to be tweaked until it does pass. I made him a deal, I wasn't ready to just release this version, but I'd focus for 2 weeks after the new year to have something testable and semi-presentable. Then, with the feedback, decide the next move.

There are lots of names for this process, and lots of existing wisdom out there to test early and often, but for the programmers and programmer-minded, 'test driven idea development' is the way to think about it. If you have an idea for something, write the test case first, then do what you can to try to pass it. Will your user come back X number of times per week and do Y number of actions a month? Will they pay Z dollars for products A, B, and C? You don't need a lot of code to test that out. In fact, you could even hand-write emails and web pages that mimic what a bigger system would do once you build it out. Or, just a really crude proof-of-concept web app that you're scared out of your mind to release with your name on it. 

My wife and I recently did a personal genetic test using 23andMe.com. There was a wealth of information about disease probabilities, family history, and some "trait" information that has been determined by studies that compare certain types of people to other people. Way at the bottom of the traits list was this interesting one: "Avoidance of Errors". From 23andMe.com:

"Learning involves a range of behaviors and skills. These include developing a tendency to prefer rewarded (positively reinforced) choices while avoiding those that are either punished or negatively reinforced. Past studies have shown that the neurotransmitter dopamine is involved in such trial-and-error learning; that means variations in genes related to dopamine signaling may also affect a person's ability to learn."

The German study that found this was able to show that some people's brains reward them when they take paths that avoid errors, while others do not. And, as I know from basic college psychology, when your brain gives you dopamine for certain things, it is actually changing your brain pathways and in turn changing your behavior.

Programmers encounter errors every day, sometimes hundreds of them. In any given day I write some code, complie, look at the error list, fix, compile, fix, and on and on. It doesn't bother me in the slightest that 99 times I see error and one time I see no errors. Contrast that to my wife, who has the error avoidance gene. She works with people, and she manages a clinical research study. Errors with people, and errors with measurement are bad. She should avoid them. Of course errors in code are bad as well, and I strive to release code that is error free and loathe every time a bug ends up in production, it gives me a sick-to-my-stomach feeling actually.

After thinking it through I'm reminded of an experience in college. I went to an undergrad welcome event for computer science majors and met a lot of young would-be computer people. One stood out, we'll call him Eric, who was so certain of how his college career would pan out and how he'd move along to an internship with one of 3 companies he had already pre-selected. I couldn't decide if I admired this guy, or if I thought he was just full of it. He did have some programming under his belt from high school, and my high school didn't offer any real programming classes so all I had was what hacking I had done myself.

I ended up seeing Eric again in the first programming class everyone had to take, the "weeder" class that thins out the impacted major. Fast forward to the first major programming assignment, due 9.a.m Saturday morning. EVERYONE, the entire class, is tired and frantically figuring out how to pass all the test cases in the basement of a large concrete building at 3.am. I was sitting next to Eric, trying to figure out test case #15 and having no luck. I had what I thought would work, but was getting maybe a dozen compile errors or warnings as I made my way towards the final working progress. I leaned over to him, 

Me: "Hey, how's it going?"

Eric: "Good good, almost done I think."

Me: "Really? Wow, that's awesome. " (I couldn't believe it. I'd be there until the sun came up turning it in just before the 9.am deadline like most).

Me: "Can I ask you a question about #15? I think I'm doing it as it says, but I keep getting this compile error: 'Blah blah'. Are you getting that too?"

Him: "Oh, I'm writing it all out first, then I'm going to turn on the errors."

Me: "Oh, ok, nevermind then."

I think I just guessed he was that good, that he could write the whole thing out free form and with all the pieces in place it'd work. He didn't want to see the errors, they were really bothering him and hindering him from proceeding along.  A couple hours later (4 or 5 am) I was down to probably half the errors and warnings from before, curious how he was doing. 

Me: "Making some progress?"

Eric: "Yup, almost done. I'm about to compile with the errors and warnings turned on."

He went to the command line, compiled -- 187 errors & warnings. Eric's mouth dropped. You could tell, it was game over and he knew it. Having avoided seeing the errors all week, he now had too many to resolve. He hadn't assembled the program layer by layer against the compiler errors the way I had. He looked over and said "I'm going to work on this from my room and fix these before 9". He packed up and left. Needless to say, he dropped the class. I then saw him a year later, he had changed his major and was happy doing something else.

I thought of this when I saw the genetic trait analysis. If your brain is fighting you every time you see an error, you're not going to like programming (maybe you'd be a good QA person though?). When I was a kid I used to take toys apart, and see how they worked, sometimes they'd go back together, sometimes not. It didn't bother me too much. Making circuits on a breadboard, if I crossed some wires and fried an LED or motor, no biggie. I picked up programming as early as elementary school using Logo, without the internet to look up solutions, so you can imagine how many errors I'd see there. If your brain is wired to treat you to avoid seeing those errors, you're not going to like programming. If an error is just another feedback, like a hint, or like a bowling alley rubber bumper, then you're the programmer type.

What do you think? Can someone be error-avoiding and be a programmer?