Us developers have a problem, and at the heart of that problem is the fact that we are developers. We are creators. Whenever we see a problem around us, our immediate instinct is to develop a solution to that problem. Build a solution first, ask questions later.
More often than not, this results in us spending time developing things that we don’t actually need to be working on. And this hurts us. Sure, we may be learning, but we are wasting time creating solutions to problems that have already been solved, at least partially.
What I didn’t do before building devWatchr was research to see if a good solution already existed. And if you use any of the existing solutions, you already know that devWatchr is essentially obsolete. Check out grunt for instance.
After noticing that I was wasting a ton of time, I made a promise to myself to always do some research before I dove head on into development. So I developed a 3 step process that everyone can follow (this was referenced in my post “Batman vs Bane: Building a Software Startup“) to develop quickly and effectively.
Each of these 3 steps should be performed for every feature that you are planning on adding to your project:
1. Find It (Open Source)
So, you’ve got a great idea for a new feature in your product. I’m going to use an example from Kobra, my side-project. One of the biggest features that I wanted to include was actually the ability to video-chat right from within the tool.
If you’ve ever worked with WebRTC before, you know that it is not fun to program, especially when taking into account cross-browser. So I did some Googling around and tried to find an open source solution that I could use instead of programming it from scratch myself. I tried about 3 different solutions before I finally found EasyRTC. I was up and running in TWO HOURS and under 300 lines of code.
There is a lot of open source code out there, use it to your advantage. Now, sometimes you won’t be able to find -exactly- the open source solution that you’d like to use, but don’t stop there.
First start googling for concepts instead of specific solutions. WebRTC is a specific solution, but one thing that I wanted Kobra to be able to do was automatically save files back to your server. I knew that you could do this right over SSH/SFTP, and I was using Python as my backend programming language. I started googling for things like “sftp python library” and “ssh file transfer python library” and found a tool called Fabric.
Those of you that work in Python might know that Fabric is traditionally used to write deployment scripts. However, all I needed to do was transfer single files back and forth when a user saved them. Even though I didn’t use Fabric for its intended purpose, its functionality definitely matched what I was looking for, so I used it!
Don’t be afraid to use a piece of open-source software for something that it isn’t advertised for.
2. Buy It (Closed Source)
So you’ve scoured the interwebs and you cant find the solution you need for free. You’ve searched for specific keywords and broad concepts and nothing for free.
I want you to step back and realize something about yourself though before we move on. I want you to truly comprehend that your time is worth money. I’ll say that again:
YOUR TIME IS WORTH MONEY.
Sometimes you can’t find any free code, but that doesn’t mean you should start building the solution yourself quite yet. Do a time analysis first, how much time is programming this part going to take you? Will it take you 2 hours, a week, a month? What is your hourly rate?
I usually take my best guestimate to how long a feature will take me to program, than multiply that by my hourly rate at my day job.
If I can find a solution for less than that cost, I buy it. I’ll be able to launch sooner that way as well.
A good example of this is the general premise behind Kobra, the ability to code collaboratively online. There are two major portions to this: the ACE Editor (open-source) and the actual ability to collaborate online. I found a solution called Firepad that lets you use the ACE editor online to collaborate, but it’s backed by Firebase (a Database-as-a-Service company). Firebase isn’t a free service, it costs a monthly fee starting at $50/month once you get past the free threshold.
However, if I actually needed to program the collaborative functionality into Kobra, that would have taken me MONTHS. Especially since I was working on it as a side-project. $50/month? That is a no-brainer. Sold.
Don’t be afraid to invest some money into your feature if it will let you launch that feature faster.
3. Build It
If you’ve made it to step three, I would heavily encourage you to repeat steps 1 and 2. There’s a saying out there that no idea or thought is unique. Chances are something out there exists that will make it so you don’t have to program your feature from scratch. Go double check.
If all else fails, then set out to build your feature from scratch. If you find yourself in this circumstance, I would also advice that you build this feature in a modular way so that, if need be, you can utilize it in other projects that you are working on. Or you can open-source it to share with the world, or you may even be able to sell it. There’s another saying you may have heard of that was made popular by 37Signals, and that is to sell your byproducts.
So remember to follow this 3-step process when developing and I guarantee you that you will cut your development time in half. One of the comments I receive about Kobra frequently is “You built that in 6 weeks? How!?”
- Find It: Use open source to your advantage. If something exists to make your life easier, use it.
- Buy It: Your time is worth money, be sure to value your own time and buy solutions to make your life easier.
- Build It: When all else fails, build your functionality, but see if you can modularize it to make open-source or a paid product.
It only took me 6 weeks because I was able to find other software to help me out. I completed probably 90% of my development time using step 1 and 2. In the end, the only thing I had to build from scratch was the piece that tied all of the other pieces together into one app.
Programming is like a puzzle, try to use as many pieces that other people have made as possible, and only program your own pieces when you absolutely need to.
For more product development tips like these, sign up for my email list below! I’ll send you the weekly recap of all my posts as well as email-only tips.