

Ask HN: Cowboy vs. disciplined coding in startups? - ceeK

I&#x27;ve found I mainly have been cowboy coding my startups in the initial stages; tests don&#x27;t get written, warnings often get ignored, and generally things aren&#x27;t built for maintainability.<p>My argument for this was simply speed: I needed to confirm the hypotheses about my startup as quickly as possible.<p>However recently this has started biting my in the ass - the project is quite large now and previous technical debt is forever haunting.<p>As such, I&#x27;d love for any opinions on this matter.
======
brudgers
When there's a business case for paying down the technical debt then it is
worth paying down. Prematurely paying it down is no more or less than a
premature optimization...only perhaps worse because it comes at an opportunity
cost. In the ideal world, the technical debt is forgiven because your company
grows at a pace that requires a complete rewrite. In the typical case the
technical debt is forgiven because the startup's outcome is typical.

Best practices are a means to an end. StackOverflow was running production and
development off of a single box well after it became "a thing." Doing so was
good enough because it worked and StackOverflow's successful growth was
dependent on product not getting a glossy photo on the cover of _Startup
Infrastructure Magazine_.

Make business decisions in a business like way.

Good luck.

------
hammeringtime
It is infinitely better to have a product, customers, and technical debt, than
to have no product or no customers and no technical debt.

Personally, I focus on avoiding technical debt when the cost of the debt will
outweigh the costs of cleanup even within three or four months. So I try to
keep to some best practices - having tests, having a good build system,
running a linter, because I find those systems help me reduce bugs. And every
time I have to fix a bug for a customer in production, it is a major time
sink. Every time I have to manually test a new release, or fix problems after
the fact, or block my teammates because I checked in bad code, then I am
wasting time. So I try to do enough clean up to make sure I avoid breaking
things all the time.

------
trcollinson
I find it quite interesting how many times we hear stories like this about
"cowboy" startup engineers. I subscribe to an XP (Extreme Programming)
methodology which includes things like TDD, DevOps, and Pairing. I have done
this at both existing large companies as well as tiny startups where I was
engineer #1 or co-founder (of course, pairing started with engineer #2 ;)).

When people ask me later, how could you do all of that and still run a lean,
agile startup environment I always wonder "how could I have been lean and
agile without it?!"

Is testing really all that hard? No, I am well versed in testing and pretty
good at it. It doesn't get in the way of my process and does help with my
design.

Is pairing really restrictive? No, it's liberating! I get to work hand in hand
with another engineer to get ideas out quickly, tackle bugs fast, and stay
focused.

Is DevOps really a huge problem? It sure is nice to know, early in the
development of a new product, that I can deploy RIGHT NOW and continually and
have continuous integration and test coverage. There is a lot of value in
that.

Do all of these things slow me down? I don't think so, if anything building a
new product or company isn't a sprint, it's a marathon.

Now of course the opposite to all of these point are:

Adding tests later is really hard. So is removing technical debt. That hurts,
a lot. A newly formed companies can't always cross that chasm.

Multiple engineers all trying to solve big problems without communication can
lead to architectural and engineering issues down the road. These are hard to
solve. Pairing sure helps with that.

If you can't deploy, redeploy, or move your installation easily, that is a
risk to your entire business.

One added benefit of not being a cowboy (outside of your technical debt not
biting you later) is in the financing and acquisition discussions become a lot
more fun and lucrative. A number of Angel and VC organizations are becoming
extremely tech-savy. They want to know if you have test coverage. They want to
know that one day your servers won't go down and you won't be spending two
weeks trying to remember how to get your entire environment configured. They
want to know that their money will be placed in a great investment. These
disciplined principles of development go a long way towards showing them that
they will meet that goal.

~~~
brudgers
Extreme programming also includes work weeks approaching forty hours...it's
about people after all. That sort of approach to work-life balance isn't
really to the burn the candle at both ends and the middle rocket fuelled
startup aesthetic.

That's not to say that there aren't sound practices there that can be applied
to a startup, but XP comes out of the world of consulting where there are
clients to prioritize features and decide when enough value has been created
to pull the plug on the iterations. So there is a bit of an impedance mismatch
between the technique and the brutal reality of going all in for several
years.

~~~
trcollinson
You are right about the fact that XP pushes for (and should achieve!) a 40
hour week. Again I think it's unfortunate that in the start up world we have
thrown out work life balance. As if working 16 hours a day, 7 days a week is a
reality that is necessary for a successful start up. I disagree. My two start
ups were both quite successful without having to work people more than 40
hours because we had good principles.

We realized very early on that we honestly didn't get a huge amount of value
out of the hours after 40. Why do start ups work late into the night? To
deploy a feature that is having trouble? Continuous integration and deployment
help with that. Adding a new amazing feature that has to be in by morning?
When you have a prioritized backlog of features you can tell potential
investors or customers when something will be done and they can schedule
around that. No need to work until 4am to present at 8am.

I guess I am very against reactionary development. When I am at the helm of a
company or a development department, big or small, I don't allow others to
dictate my schedule or my ability to make great software. I have been quite
lucky, maybe, that my investors and customers have very much appreciated, and
paid for, my approach.

~~~
brudgers
It's less unfortunate in the startup world where a rainbow chasing deathmarch
has at least a theoretical possibility of ending at a pot of gold. It's the
deathmarch on the corporate culture treadmill where the carrot is climbing the
ladder at best and keeping your health insurance more typically that really
sucks.

On the other hand, a big push can be worthwhile when the timing of milestones
is outside your control. Sometimes a December 26th ship date might as well be
November 1, next year. Likewise, ramen is cheap but not endless and the pace
at which leases burn through capital is calendar days not hours worked. The
alternative isn't irrational.

I'd even go so far as to say that there is a certain buzz that comes from the
occasional all-nighter...always 8-5 is the life of a shoe clerk. None of which
is to suggest that balance isn't good and a worthwhile pursuit, but if the
muse never visits, it's just a job not art.

------
nstart
The only discipline I truly push for when asked this question is Test Driven
Development. Reasons:

1) You can still code pretty fast (trust me on this, code moves only a tiny
bit slower and then gains heavily when it comes to debugging even while
coding).

2) You tend to think smarter. Stuff that escaped you in your hastily done
whiteboard/skype meetings will show itself when writing quick test cases.

3) Your code gets partially arranged at least thanks to TDD. You can skip the
refactoring after passing tests, but when technical debt catches up to you
(and it will), you'll be ready because your tests will tell you where you
broke stuff.

I look at TDD as a great foundation to build any crap on. At the end of the
day, it tells you if your features are working. So even if the features are
implemented with crap code, you can rest easy knowing that there's something
watching out to tell you if you broke anything while redoing stuff.

For me, everything without TDD feels like a cowboy

PS - My experience in this. I've coded full on idiot style. No tests, no
design, just code. It's only caused me grief when I look at things 6 months
later. I've worked with a company coding full on idiot style. Most miserable
time ever. I've coded again in my next company as a smarter person but without
any tests. Ok design, no tests, still made my life miserable 8 months later.
And then I've coded a full blown system using TDD and meh-ish design. Over
time, I've updated the design and I continue to love working on this system. I
really do. I look forward to getting back from work and coding on it. Where I
work right now, I'm looking at very advanced OOP but no tests. It's ok-ish
when someone explains it to you, but it's still really scary to even think of
making changes in there.

So to sum up: my own idiotic coding, someone else's idiotic coding, my own ok
design, someone else's advanced super disciplined design, and my meh-ish
design backed by TDD. TDD wins. Rawr!

