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.<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'd love for any opinions on this matter.
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.<p>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 <i>Startup Infrastructure Magazine</i>.<p>Make business decisions in a business like way.<p>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.<p>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 ;)).<p>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?!"<p>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.<p>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.<p>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.<p>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.<p>Now of course the opposite to all of these point are:<p>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.<p>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.<p>If you can't deploy, redeploy, or move your installation easily, that is a risk to your entire business.<p>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.
The only discipline I truly push for when asked this question is Test Driven Development. Reasons:<p>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).<p>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.<p>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.<p>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.<p>For me, everything without TDD feels like a cowboy<p>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.<p>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!