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.