ideas

[caption id="attachment_800" align="alignright" width="234" caption="In the future, we will rule this world!"][/caption]

Ideas are interesting things, we have them all the time, we dismiss them frequently, and we value them heartily. Some people don't like to talk about their ideas, don't want people to steal their million dollar brain baby, and I can respect that, but a million dollar idea with zero execution is worth nothing.

Ideas, like misery, love company, if I tell you an idea your brain will immediately start thinking about it, having its own ideas and interpretations. Then you tell me your ideas that my ideas caused and I get more ideas and so on and so forth, this is the basis of a conversation. That our ideas can grow and change organically, that we can piggy back off of each other, this is the basis of our society. But let's get out of the woods of the abstract and into the city of concrete.

What I want to talk about today are those entrepreneurial ideas that we all have from time to time. Those things that you are certain will make you rich and famous, or the ideas that leap back into our minds when we see some new thing, a worldwide pornography distribution network, Tim Berners-Lee stole my idea! What should you do with these ideas, how should you handle them, and why and what and huh.

Every person will have their own way of handling the little lightning bolts that leap into their head but I want to take you through the path that I've found helpful for me.

1. Write it down - I write down almost every business thought I have, no matter how far fetched, and no matter how overloaded with tasks I am. This seems a little silly, if you are actively working at one thing it can even feel disloyal to start thinking about something else, what am I a squirrel easily distracted by a shiny piece of tinfoil? No, in my opinion you can never have enough ideas in reserve. It doesn't take too much time to jot down enough information to be able to recall it later, and it doesn't mean you aren't serious about your current set of priorities. We would all like to think that everything we are working on will always work out, but you will never be sad that you have more ideas to fall back on.


2. Percolate - Go do something else, even if you aren't actively thinking about something, after writing it down it will be floating around in your brain someplace. Great ideas refuse to fall to the wayside, if you find yourself coming back to something in your head more than a few times, move onto step 3.


3. Talk it out - Share your idea with other people, sanity check it, see if they laugh at you. Don't get discouraged too easily though, great ideas can sound crazy and still be great ideas. After discussing it with a few people you can get a handle on how realistic it is and how excited you should be about your new idea.


4. Prototype or Shelf - If you've made it to step 4 you have to look around and prioritize, it's easy to be swept up in the novelty of a new idea, but strive to objectively adjudicate whether or not you have the free time to move forward. If you do, grab some technology you are comfortable with and make a prototype, don't invest too much time or money. If not shelf the idea, keep a short list of things ready made to work on and add this idea to it.


5. Focus Group Lite - If you made a prototype put it in front of some people, or float a pilot program. See how people react, sometimes an idea can sound great until you see it, then you realize some fundamental flaw. If this stage is good then move onto step 6.


6. Jump in with both feet - Get cracking. If you have the time, passion, and indication that people could use your idea, go for it. It will be difficult and you will probably fail, but you will be better for it.

Ideas are nothing without execution, but they are still valuable. Make sure you save your ideas, bounce them off of other people, and if your gut and other people tell you to go for it, take the chance. You may not always succeed, but you will rarely be disappointed that you tried.

simplify

[caption id="attachment_515" align="alignright" width="293" caption="simplicity is sometimes surprisingly complex"][/caption]

I love abstractions, most people do, they allow us to take complex things and wrap them in simple things and everyone is happy. The thing to realize is that there are degrees of complexity and different goals of abstractions.

Programming is one of those things where more often than not our abstractions are really helpful. The problem becomes one of perceived complexity vs. actual complexity. A good example is network protocols.

Network protocols are these complex beasts that let us talk across networks with some degree of certainty. Its really quite the marvel of engineering prowess, man has taken the various blinkenlights and cables and a big ole' pile of Cisco and now you can watch a video of a cat playing keyboard whenever you like. Network protocols were designed to simplify the process of two programs on physically distant machines sharing information.

When you first try to learn a complex abstraction it can seem daunting, UDP, TCP/IP, sockets and fifos and netcats oh my! Sometimes it can seem overwhelming, but take a step back and realize that no matter how complicated a piece of software is, its just moving around bytes.

Perl has a philosophy that at the end of the day, everything is strings. That's why its the glue that holds together the interwebs, because it's just a really good string manipulation language. At the end of the day that's all the internet is, strings floating around, normally between angled brackets.

Like most of the things I write I'm almost certain I had a point... oh there it is. When I started writing prosper it seemed like an impossible mountain to climb. I wanted to write a library that would bridge the gaps between all supported database backends, to have it be a sort of universal data access object.

[caption id="attachment_516" align="alignleft" width="354" caption="This was much easier to think about than the actual problem"][/caption]

I had a few false starts on my project until I took a step back, I simplified my problem domain, and created an architecture that worked. Instead of focusing on the end result of prosper I thought about it in a more abstract way, prosper was a mapper from function calls to string snippets. This isn't actually what prosper does today, prosper is in fact much more complex now than I would have ever imagined when I first started out.

The obstacle that stood in my way the most when starting out on prosper was being overwhelmed and unsure. The problem domain I was trying to tackle was too big, even when I tried solving it i ended up painting myself into a corner by focusing too much on how one specific backend acted. I needed a simpler problem that was more easily solvable, but one that would in the end help me reach my actual goal.

As much as I wish I could take credit for this idea, it's not mine, it's something called Minimum Viable Product. I wanted something that at its core would produce cross-platform SQL, so the first iteration was to make something that did exactly that. If you go on GitHub and pull one of the earlier commits you will see that that's exactly what I built. Over time I have added the ability to execute those strings, connection and transaction management, standardized results, prepared statement support, and much more.

I couldn't have accomplished any of this though if I hadn't taken a step back from the problem domain and looked at the simpler problem at the core of what I was trying to do. I stumbled in the beginning, I've refactored again and again, over the break my good friend Ian took a look at the library and found a whole slew of problems, and I thank him for it. Prosper isn't perfect yet, but it is moving toward being something really worthwhile, and to begin moving it required that I have something, anything, to start with.

So here is my suggestion for you for the new year. If you have some project that you've wanted to do but couldn't figure out how to start, step back from the problem domain and try to find the core of the problem and solve it with the simplest thing that could possibly work. Don't worry about the first iteration, or the first 20 iterations, you have to just get started. Once it is started you can iterate and refactor and maybe throw everything away and start again. No matter what the outcome of the first iteration it will be worth it, the best case scenario is that you can use the first iteration as a core moving forward, the worst case is that you learn a bunch about the problem domain and have to try again.

It's the start of a new year, resolve to start your dream project, because that's the hardest part. Once you get rolling momentum has a fantastic way of carrying you through.