Ask HN: Cowboy vs. disciplined coding in startups? | Hacker News Reader

Ask HN: Cowboy vs. disciplined coding in startups?

8 pointsceeK7 comments

I've found I mainly have been cowboy coding my startups in the initial stages; tests don't get written, warnings often get ignored, and generally things aren't built for maintainability.

My argument for this was simply speed: I needed to confirm the hypotheses about my startup as quickly as possible.

However recently this has started biting my in the ass - the project is quite large now and previous technical debt is forever haunting.

As such, I'd love for any opinions on this matter.

View on HN

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.

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.

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.

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.

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.

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.

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!

Reply on news.ycombinator.com