About two weeks ago, I wrote a provisional patent application.

According to our attorney, a patent application needs to describe the product with enough detail so that anyone skilled in the trade would be able to follow the instructions and build the product.

So I didn’t include a diagram of my database. I figure that somebody skilled in the trade would understand how to design an adequate database schema when I say stuff like “since the system supports sending the same information to many people, where some people receive SMS message, and others get a voice call using text-to-speech, I keep the message data separate from the details about who receives that message and by what means.”

Likewise, when I say the system can forward an incoming SMS message from an employee to a supervisor’s email address, I don’t go through the details of how I parse the binary crapola from the SMS and then construct an email message. Somebody skilled in the trade knows how to do that already, or they know how to learn how to do it.

And I didn’t talk about which web application framework I used or how exactly I deploy my code on the production server. I figure that a skilled programmer can figure out those details without my help. Furthermore, there’s probably a lot of different possible solutions.

So I left a lot of detail out. I focused on how the system responds to certain events and what problems the system was designed to solve.

Even after taking all those shortcuts, I ended up with nearly 10 pages of text and it took nearly an entire week to crank out. After I finished, I learned a few things:

1. My code follows patterns. I build one feature, then I build another feature using the same style. By the time I’m writing the third feature, again using the same style, similar code now lives in three places.
2. The application lacks symmetry. There are obvious examples, like where you can download data into a spreadsheet from one screen but not from another. In less-obvious cases, two different methods might solve the same problem, but one method uses a superior technique.

The second point is the opposite of the first point. Instead of solving different problems in similar ways, I’m solving similar problems in different ways.

I need more abstraction. I need to write code that is easier to reuse, and then actually reuse it rather than dashing off some ad-hoc fix.

All of this happened because of my design strategy. I talk to a pool of customers and then I make a list of their problems. Then I sort those problems by (A * B) / C, where:

A = size of the market with this problem
B = how severe it is (i.e., how much would they pay for the solution)
C = how difficult is it to solve.


I pick enough of the best candidates to fill up about 30 days of work. Then I build, test, and deploy, and the cycle starts over again.

So far, I’m happy with working this way, but there’s clearly a downside to only focusing on defining and building the next feature. A colleague calls it “not seeing the forest for the trees.” I think that’s about right. I don’t think of my work as a gestalt as much as a bag of magic tricks. Anyhow, for a few brief moments, after taking a week off from writing code to see write that patent application, I saw the forest. It’s a nice view.