
These time-sucks will add 3 months to your launch date. - dshah
http://www.47hats.com/index.php/2008/05/30/these-time-sucks-will-add-3-months-to-your-launch-date/
======
nostrademons
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.

------
BrandonM
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.

------
swombat
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
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.

------
jrockway
_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.

------
fish
6) Visiting <http://news.ycombinator.com/>

------
tlrobinson
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.

------
j2d2
Time sink.

