I’ve spent the last week looking at old code. This has been very enlightening. On one hand, this code is decrepit and old. Most of it was originally written three designs and six years ago. There are tons of stupid and ridiculous coding decisions that I would never make today.

But that’s exactly why I am so optimistic. Yes, my code sucks from six years ago. But I know that it sucks. That means I’ve learned something about better code since then, and that’s exciting!

Joe Posnanski, one of the greatest sports writers on the planet, made this comment at the bottom of one of his articles:

One of the most underrated talents in baseball, and probably in life, is showing up.

Absolutely. But it isn’t just showing up and hanging around the back of the room. It’s about showing up and trying to take away something new every day, every week. For six years I keep showing up, reading Apple’s docs, reviewing StackOverflow posts, working XCode. So while my code sucked six years ago, it is significantly less embarrassing today.

I hope in six years I look back and think today’s code sucks, too.

Steve Blank wrote an incredibly good post asking three questions that I rarely hear asked. Most people, when starting a business, only think about the positives, about the upsides, and don’t think about what they are really doing and the impact it has on those who start that business. The reality, though, is that the years spent working on any individual business are years spent not doing something else. Yes, there is an opportunity cost, even though we don’t know what the cost is at the time we are making the decision.

The questions Steve asks, in addition to the normal business ones:

1. Do you want to spend the next 3 or 4 years of your life doing this?
2. Is this a scalable business?  And if not, are you ok with something small?
3. If I didn’t make any money after 4 years, did I still have a great time?

These are such critical questions, ones I have been asking myself over the last couple of years. 1 and 3 I have answered definitively. 2 I still struggle with.

Last week was insane. I don’t think I’ve worked so many hours in a long time. My conservative estimate is 85 hours alone with my business partner in for another 70 or more. We are working on a contract job — got to pay the bills some how as powerOne has become a labor of love — and it all came to a head last week with a deadline for today. We made our deadline. Why so many hours at the end? Because there were too few hours at the beginning.

We have never done much contract work before this past year, at least not stuff that isn’t calculator related or where I am closely guiding the development requirements. This year we have done two such projects. The one early in the year was extremely well specified. We knew exactly what we were responsible for, how they wanted it done, and had header files of everything we needed to interface with. While the coding was different in some ways from anything we had done before, the project was well defined and very straight-forward.

This project, though, was open-ended. We had a basic requirements list but not much was well defined. Even the requirements list was fluid. So here are a few things I learned from this project:

1. Force a refined requirements list. I shouldn’t have bid on a project that was quite so fluid but I did. It’s a start-up, they are moving fast, and the project was right up our alley. Plus, they had a two month window so I wanted to get started. So we did.

Honestly this wouldn’t have been such an issue if we would have had more domain knowledge. But this is one of the few times in my career I developed a product where I didn’t have a sense for the customer.

2. Mobile is not the web. This is one I knew but reinforced once again here. In essence the partner company said here’s the website; go play with it. I did a little but given that it wasn’t my domain expertise and the site was complicated, I didn’t play enough. When developing, every layer we peeled off the site showed even more complexity. I didn’t understand the full extent of code required and not sure I could have from “playing with the site.”

3. Specify, specify, specify. Which leads me to #3: I should have focused everyone on creating a specification right up front. What did we need? How many layers were there to the site? How would we simplify the entire site to fit the mobile paradigm? We thought we could do this as we went but that was a problem. We spent too many hours re-writing code and their designer spent way too many hours writing APIs for features we didn’t use.

I had a professor who once said that writing an app is 70% planning and 30% coding. What he didn’t say is that most of that 70% needs to happen up front. As I mentioned, normally not a problem as usually I write apps I understand inside and out. But when writing for someone else, especially in a domain I don’t know? More planning up front.

4. Someone must be in charge. There really wasn’t any one in charge of decision making and planning on a day-to-day basis, or more accurately it was shared. The CEO of the company we were developing for is really a sales guy, so feedback came late in the process or not at all. Mostly we were left to make our own decisions and sell them to the company, but it took us a while to get the hang of that. Luckily, the company CEO is a very reasonable person.

5. UI first or data first. Every app I have ever written started with the UI. We designed what we wanted it to look like, the features we wanted, and then built the models to match. I spent the first few weeks of this project completely frustrated because this project was the exact opposite and I didn’t realize that. In this case the data (because of the web app) was well-defined and we should have started with the models and then built the UI from that. We started moving forward once we figured this out.

6. Simplify. I preach this over and over again for our own consumption. The same is true for contract jobs. There is never a UI or data model that can’t be simplified further. Again, so thankful the company’s CEO was so reasonable. I do hope they take these lessons and bring them back to the web.

Outside of the intense process at the end, it turned out to be a decent development project. I hope we can get back to working on powerOne and Equals, though, and that we can figure out how to turn those into sustaining businesses. I really don’t like writing code for other people’s ideas.

I was at a breakfast meeting yesterday and we got to talking about minimum viable product (MVP). I’ve written about this before, basically saying how speed of development and MVP are not synonymous. But the question arose: how do we know when we have a minimum viable product?

Before I answer that question, though, I want to make sure we all understand this incredibly important concept. A minimum viable product is the least development you can do to give your potential customers the idea of what you are trying to accomplish, what benefits this service/product might bring to them, and give you a feel for the revenues and costs associated with delivering the service/product. The point of MVP is to get those of us who are inclined to sit around the office and develop apps out of the office talking to customers.

Dropbox famously built their MVP as a video. I’ve seen paper reproductions and I’ve seen code. Sometimes wireframes work or a nicely mocked up PowerPoint presentation. Every one of these can get the idea across and get a conversation started. In fact I could easily argue that the less code you write the better off you are. [1]

It’s important to understand that most people can’t imagine what you are imagining. They need to see it or touch it to truly get it. And that’s why words on a page or a concept in speech is simply not enough. Physical is better. The decision about how to get that across to a customer, though, is up to you.

When we started working on an MVP for Equals we decided we needed to write code. The concept — writing a note that can tell the difference between text and numbers, performing any mathematics automatically — was hard to imagine. We felt it was important to show that ability so we started with an MVP that did just that and over the course of months refined its capabilities.

We also realized that there were a number of other things we wanted to test as well with customers. Would sharing be of interest? Would being able to send things to third-parties like Evernote, Twitter and Facebook be important? What about collaboration? History? Integrated data?

Some of these things were natural offshoots so we didn’t need to develop them. Once people understood sharing the idea of collaboration was a natural extension, very easy to discuss. Some we could put screenshots in place that simulated the look-and-feel but didn’t actually function. I didn’t have to build Evernote, Twitter and Facebook integration. Showing a table with those options was enough. When we developed the first Equals MVP we included no text formatting. We talked to potential customers about the idea but found that it didn’t stimulate a conversation. So we added functioning code. [2]

Once again, back to the original question: how do we know when we have a minimum viable product? We know when we have a hint of all the features we want to get a reaction to from the customer. Those features need not be complete and in many cases they don’t even need to be functioning. But they do need to spark a conversation.

After all, the whole point of the MVP is to get a sense from customers as to whether we are on the right track or not.

—

[1] This goes especially for non-developers. Stop asking people if they’ll write an app for you based on an idea. Mock the thing up in PowerPoint or Keynote using a tool like Keynotopia and go get customer feedback. That’s a heck of a lot cheaper than writing code.

[2] We also needed to prove we could do it in a cross-platform way.

Since I was a little kid I wanted to play Major League Baseball. I dreamt about it, I went out in the yard and pitched to a pitch back or through a tire swing. At my dad’s house I drove the neighbors crazy by throwing a ball against the steps for hours at a time.

I loved baseball. Even when I wasn’t playing I was playing. When I wasn’t outside playing ball, I loved to pretend to be the GM in simulated dice games. I even got into programming because I wanted to figure out how to simulate real-life. I quit playing the violin, which I was pretty good at, because I didn’t want it to interfere with me playing baseball.

I was a decent player but not incredible. I was a decent fielder but didn’t hit a ton. I played a solid catcher for a few years and was a decent pitcher but didn’t throw particularly hard. I tried hard, though.

In tenth grade I moved to Florida and made the varsity team. I played a little centerfield, got one chance to pitch (off a mound, which I had never done before), and came up to bat a few times but didn’t hit much. I was overmatched by the older kids and, it appears, needed glasses.

I played part of one season and quit.

That was the end of my playing days, at least baseball. (I played softball starting at age 19 until I had kids in my early 30s. It wasn’t the same, though.)

Quitting baseball is my one regret in life. I didn’t want it bad enough, I didn’t want to work at it, to become a better player, to suffer for the sport I loved.

My quitting baseball motivates me to this day. I recognize that if I want something bad enough I

need to keep working at it. No wall should be able to contain me. And talent alone doesn’t dictate success or failure. Effort has far more to do with it.

I went to Boston last week where my cousin works for the Red Sox and saw the second game of the World Series. Before the game started, he walked me to all corners of the stadium and even, at one point, into the outfield on the warning track near the centerfield wall.

It rekindled a lot of feelings in me about how badly I wanted to play pro ball and how I quit the minute it became hard. I’ll never let that happen again.