Re:These time-sucks will add 3 months to your launch date.
by nostrademons on Saturday May 31, 2008 @03:43PM
(#205381)
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.
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.