These time-sucks will add 3 months to your launch date.

http://www.47hats.com/index.php/2008/05/30/these-time-sucks-will-add-3-months-to-your-launch-date/

by dshah • 18 years ago

36 8 18 years ago

tlrobinson• 18 years ago

Also, not starting small and iterating will add significant time. If you constantly feel like you just need to add one more thing before it's perfect for launch it's going to take forever.

Come up with a subset of the features you ideally want to have and focus on those so you can launch earlier, then iterate based on your other ideas AND user feedback.

swombat• 18 years ago

Ok article, if fairly superficial, except for point 4. Advocating that someone should write something as changeable as a startup product without any unit tests is just plain bad advice.

alexk• 18 years ago

I do agree. Test driven development really encourages the software to be more flexible since it allows to change the code immideately getting the impacts on the other parts of the system ( what is impossible without auto tests ); moreover once you test the code you try the interfaces and approach for usability, what improves the design speed and quality.

BrandonM• 18 years ago

I can see where the author is coming from with Point 3 (Don't build a framework or library). In fact, I personally suffered from the problem of spending time on a framework when I really should have just been building the application, but that was partly because it wasn't my application and the framework was more interesting. But that's a different story....

So I do agree that rolling your own framework right from the start is probably a bad idea, but I wouldn't say the same for a library. A library is much-smaller-scale than a framework. In general, a well-built module in your program can likely be converted to a more general-purpose library with just one small iteration (in my experience at least). This should be especially true if you only generalize the functionality that you're currently using and avoid adding every function/method that you will ever possibly need.

The benefit of building a library is that once you do, you can consider that part finished for a long time. You can build a little test that checks the library's edge cases while also serving as a good example of how to use your library (it's always good to have simple code to refer to in 6 months). And if the library isn't too proprietary, you can throw it up on a public-facing server, where you can both help others and have a decent chance of receiving good feedback (if not patches) for better algorithms, bugfixes, or additional helpful functionality that others have implemented.

Specifically if you're working in a language that you will use for the majority of your projects, having a collection of personal libraries is invaluable. You will have this wonderful repository of functionality that you're already intimately familiar with, and instead of having that nagging feeling that you're re-coding something that you've done in the past, you will be able to go back and use a solid piece of tested code with very little effort expended on (re-)learning an API.

jrockway• 18 years ago

Look - the problem with frameworks is that by nature they’re general. But your application is specific.

So by building frameworks or libraries, you have to write a lot more code to cover a lot of use cases, which have nothing to do with your application!

Spoken like a true PHP weenie.

This is why most programming languages are useless; nobody writes any worthwhile libraries. I've found that writing a library rarely affects how quickly I get something done -- solving a general problem and a specific instance of a general problem usually involve the same amount of thinking (and a bit more code). Thinking is slow, and typing is fast... so I wouldn't worry about this being a time sink.

Plus, when you release the library, the other people that happen to use it will start fixing it for you. Now you have people working on your specific problem for free.

Anyway, once you get a culture of library building going, the net result is a huge time savings for everyone in the community.

nostrademons• 18 years ago

All of these have "Yes, but..." corollaries that can bite you just as bad:

1.) Yes, but...a little time spent refining your idea at the beginning can save you a lot of wasted time later. For example, my startup is a webapp to let people create their own casual games. We decided, early on, to start with an arcade proof of concept, because arcade games are what everyone thinks of when you say video games. All our competitors did the same thing. But most of the growth in the casual games market has actually been puzzle and word games, which are also more personally compelling to me. A little thought might've saved months of work. (Or maybe not, since it's looking like the sweet spot for our app may be in multi-genre games that don't fit into any archetype.)

2.) Yes, but...it's often not clear what the right tool for the job is until you've explored the problem domain, and you need to pick a tool in order to do that. What if, after building that Window's GUI app in C#, you find that it really should've been a webapp? If you'd written it in heavily macro-ized Lisp, you could probably just change some macro definitions to generate HTML pages instead of Windows GUI forms.

3.) Yes, but...when you find yourself doing the same thing over and over again, it's time to abstract it into a library. Otherwise you end up like one of my old employers, who found they were invoking some DNS call wrong and said, "Well, we can fix it...but we'll have to fix it in 109 places."

Another example comes from my current project - I've got this abstraction called a SpriteReference, which basically picks out one or more sprites, possibly in a context-sensitive way. I built a custom (JavaScript) GUI widget for this, which is used in lots and lots of places. When I went to clean up the GUI for this, I spent a day changing the widget and it's instantly reflected everywhere I use it, instead of hunting down the several dozen places where SpriteReferences may appear in the UI and changing each one.

4.) Yes, but...oftentimes, you need those tests and documentation to build the rest of your application. You can't build upon code that doesn't work. There've been several times that I went back and added unit tests simply because that was the only way I could make further progress. The alternative is "hope and pray programming", which is unfortunately quite common in real companies (both my previous employers have practiced it, and they were in security/remote-access and financial software).

5.) Yes, but...if you can do it in 6 months, so can all of your competitors. It seems like there's a wide variety in launch times of successful products, ranging from 3 weeks for Reddit to 5 years for the Apple Macintosh. I definitely agree that you should put something up on the screen as soon as you can though - I'd say more like 1 month. That gives you something to react to so you're not designing against a vacuum.

Really, this is why software entrepreneurship is hard. A lot of advice is right but incomplete, and could easily go the other way depending on circumstances you have no way of foreseeing.

j2d2• 18 years ago

Time sink.

fish• 18 years ago

6) Visiting http://news.ycombinator.com/

These time-sucks will add 3 months to your launch date.

Related Stories