Software as Good as American Pie

Three and a half hours down the highway here a celebration is taking place in memory of Buddy Holly, Ritchie Valens, and The Big Bopper, who played their last concert in Clear Lake, Iowa 50 years ago tonight.

We got some good news last week that the University of Iowa will have students do some marketing research for SnupNow this semester. I had paid a student intern at our local college to assist me with some research at the start of the company, but not enough to get to the point of financial projections that I would ever show to someone else. I have never believed any financial projection I’ve ever read from any project. I don’t like reading them, nor do I like preparing them, but the students will not do that for me, just help to bring this horse (that would be me in this analogy) to water.

I need to waffle less regarding how fast this project will go, when the software will be delivered, prior to pursuing funding, should I decide to do so (I guess I waffle on that question too). That answer depends quite a bit on the resources available for the project, right? Some such resources depend on the amount of funding. The funding amount depends on having answers to questions about how fast the project will go.

When will we be delivering software? I have been thinking that it will go to pilot sites, but not go to general availability until after we have received some funding. It just seems like a really bad idea to be supporting real users with no one who gets paid. On the other hand, it is easier to pursue funding when you can point to a number of people using your software already. In that case, if we can get people using it and also paying for the service, then the specifics of the funding might be different.

In any case, the approach I am not taking is the one made famous by silicon valley, where you get venture captial (I have no plans to pursue such), shoot for the moon, then either reach the stars or crash and burn, as Buddy Holly’s plane did on that fateful night.

With the speed at which we are going right now, it is clear that I am not taking that “shoot the moon” approach. I think it was Philippe Kahn of Borland fame who said “Delivery is a feature” but I could not find confirmation with a quick internet search. I agree that delivery is an essential feature of our SnupNow software that we are currently lacking, although we do “deliver” our builds to a user experience testing area. Adding in the delivery feature to software that does not have sufficient features to be useful would not be a virtue, however. Delivery is not the first feature of any software. If it comes too early, you can crash and burn.

Another way to crash and burn is to take off without enough lift in the form of people to support the speed at which you will grow. I have considered this past week that if I were to add up all of the hours I have spent in trying to get others on board working with me, so that we can write and support something bigger than me, these hours would significantly exceed the amount of hours from all others working on it. That might seem ridiculous, but it really does take work to make work. It also has taken and is taking me a lot of hours to learn the toolset I chose, with more hours spent teaching it to others. Other than the hours I have spent producing software, Tom has spent the most hours, with Ken coming in second, and all others well behind, spending time learning and getting onto the runway, but not yet really taken off by adding many features to the software to date. While I am hopeful that improvement on this front is coming (John has been writing some code this week and Bobby plans to this week too), the payback to having others work with me on this project is yet to come.

That brings me to another well-known quote from Kahn, which wikipedia tells me is from his keynote address at COMDEX 1992 and says “Philippe’s Law states that the productivity of a software developer in a team of N people is diminished by dividing it by the cube root of N.”

So, if I were to have been heads down writing the software last year, I would have completed let’s say 1 whole piece of software. Since there are 5 people on the development team right now, a quick estimate would be that we would get roughly 3 developers worth of progress. However, what we have are after-hours hours, not full-time members of the team, with the total hours not even adding up to a single full-time person, plus me with my productivity diminished by coordinating with each and all. My estimate is that I could have been five times more productive in writing the software on my own than in bringing others into the project so early. Instead of 1 for me solo, I think our team with me included ended up with about a 0.3 for 2008. Can you tell I’ve pondered the wisdom of my “get others involved” approach?

Unlike a pie, however, software doesn’t get made and baked by a baker and then eaten and gone. It is also not like the song American Pie about 50 years ago tonight, after midnight on February 3, when the music died. It cannot be written once and then used forever that way, even played repeatedly with Don McLean singing it (and me singing along). Software is developed and maintained over time. I could both bake a pie and write a song today, in theory at least, although both would lack the quality I would wish for in a pie or a song.

I want this software to be as good as American Pie, and taste as good as American pie.  If I did write this software on my own, I think I would have trouble getting that delivery feature in there in such a way that the customer base could grow. I would get myself into a bind, I’m quite sure, I think, most likely, perhaps.

One way that I handle so many differing opinions (even when only considering my own) on topics of when to deliver, how to get to delivery, what features to have when we deliver, how tight the software needs to be, and whether I should just sit myself down and do more coding in a week and less talking with the other Snupnow LLC owners is to focus on what we are doing, and try not to worry about the speed.

Of course, I do worry about the lack of speed. While I sometimes remind myself that “slow and steady wins the race,” and “haste makes waste,” or even “a stitch in time saves nine,” I do want to go faster than we are going right now, so that I can have some confidence in making good future projections that are still within my expected lifetime. This weekend I mulled over issues of what-they-call-human-resources, aka people. Could we use more? Less? Different skillsets? We do not yet have a high-productivity team, even if each individual can be productive at times. Right now we still somehow need to pick up enough speed to get off the runway, start to fly, and reach that delivery destination. I know we will, but today is also a reminder that, alas, that does not always happen.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s