A Brief History of BitBacker

[Gary Bernhardt]

I just wrote a blog post about BitBacker's history. Since I talked to
a lot of people at clepy about it (and it hosted 15 meetings), I
thought I'd link it here. Your thoughts are welcome, of course. :)

[1] http://blog.extracheese.org/2009/07/a-brief-history-of-bitbacker-a-startup.html

--
Gary
http://blog.extracheese.org

[Adam M. Dutko]

Nice post Gary. Good luck on your next adventure.

-Adam

[Christian Wyglendowski]

Interesting stuff. Would you say that perfection was an ally or an
enemy? In other words, did things go better when you were striving
for perfection or were you better off with good-enough?

I find that I get frustrated with most code I have written, certainly
code that spans a few years of work. It's still useful code though,
in the end. Still, that itch to get in there a gut some ugly bits for
little perceptible gain remains.

Christian
http://www.dowski.com

On Thu, Jul 23, 2009 at 8:31 PM, Gary Bernhardt<gary.be...@gmail.com> wrote:
>

[Ralph Heimburger]

It's nice to have beautiful code, but without a business model to support it, all you have is good code.  On the other hand, if you write extremely maintainable and scalable code you can code yourself out of longterm revenue (e.g. support/maintenance).   When I designed eFile I had no idea on how to store multiple tax forms and subforms and link them all together to create a tax return, I quickly built a very simple and highly scalable model that has since proven to be an enormous work saver in terms of new form rollouts, the downside is that it now only takes 1-2 days of development and the rest is UAT.

Suggestions:
Release early and release often.  Some projects do up to 40 elevations per week.  Add new features and constantly work on the UI, esp for web apps.  Although it's a good idea to determine the equity model up front, understand that it will change and the business will undergo competition and market saturation.  Adaptability is key.   That and $2 will buy you a beer...

--
Ralph Heimburger
1stpOint incorporated
www.1stpointinc.com
Ph. 216-906-3640
Fax 702-995-3640

---------------------------------------------------------------------------------------
The information transmitted in this e-mail is intended for the exclusive use of the person or entity to which it is addressed and may contain privileged or confidential information.  
If you are not the intended recipient of this e-mail, you are prohibited from reading, printing, duplicating, disseminating or otherwise using or acting in reliance upon this information.  
If you have received this information in error, notify the sender at 1stpOint inc. immediately, delete this information from your computer
and destroy all copies of the information.
Thank you.
---------------------------------------------------------------------------------------

[Gary Bernhardt]

On Thu, Jul 23, 2009 at 6:28 PM, Christian
Wyglendowski<chri...@dowski.com> wrote:
>
> Interesting stuff.  Would you say that perfection was an ally or an
> enemy?  In other words, did things go better when you were striving
> for perfection or were you better off with good-enough?
>
> I find that I get frustrated with most code I have written, certainly
> code that spans a few years of work.  It's still useful code though,
> in the end.  Still, that itch to get in there a gut some ugly bits for
> little perceptible gain remains.

I don't really like the word "perfection"; instead, I'll talk about
quality. The fact that I was striving for quality wasn't a problem. My
comparative lack of discipline at the beginning of the project was,
however, because it did slow us down when I went back and fixed the
mistakes. If I did it again, I wouldn't have that particular problem,
because my level of discipline is now much higher and more stable over
time.

As I said to people all along, including my cofounders, I'd rather
fail than build something that sucks. For a backup app, losing any
data, ever, is sucking. Backup software can't make mistakes. The
hardest part is that the most important thing the software does
(restoring data) rarely happens – most people back up but never
restore. Backup apps don't have the luxury of letting the user find
bugs. The unfortunate thing is that BitBacker doesn't suck, but died
anyway, for reasons unrelated to its technical merits.

Now, if we were building some random website, things would be
different. While working on BitBacker, I was practicing a level of
paranoia that is natural for me and good for backup apps, but probably
bad for most software in general. :)

> On Thu, Jul 23, 2009 at 8:31 PM, Gary Bernhardt<gary.be...@gmail.com> wrote:
>>
>> I just wrote a blog post about BitBacker's history. Since I talked to
>> a lot of people at clepy about it (and it hosted 15 meetings), I
>> thought I'd link it here. Your thoughts are welcome, of course. :)
>>
>> [1] http://blog.extracheese.org/2009/07/a-brief-history-of-bitbacker-a-startup.html
>>
>> --
>> Gary
>> http://blog.extracheese.org
>>
>> >
>>
>
> >
>

--
Gary
http://blog.extracheese.org

[Christian Wyglendowski]

On Sat, Jul 25, 2009 at 10:37 PM, Gary
Bernhardt<gary.be...@gmail.com> wrote:
>
> As I said to people all along, including my cofounders, I'd rather
> fail than build something that sucks. For a backup app, losing any
> data, ever, is sucking. Backup software can't make mistakes. The
> hardest part is that the most important thing the software does
> (restoring data) rarely happens – most people back up but never
> restore. Backup apps don't have the luxury of letting the user find
> bugs. The unfortunate thing is that BitBacker doesn't suck, but died
> anyway, for reasons unrelated to its technical merits.

That makes complete sense. I didn't really stop to consider what a
different beast backup software is.

> Now, if we were building some random website, things would be
> different. While working on BitBacker, I was practicing a level of
> paranoia that is natural for me and good for backup apps, but probably
> bad for most software in general. :)

Yeah, recording data and storing it reliably makes me nervous enough
at times. Writing software that only performs its most crucial
function when everything is on the line sounds even more nerve
wracking.

Christian