Comment by jon_dahl | Hacker News Reader

Comment by jon_dahl | Hacker News Reader

Parent Full thread

I tell my clients that cutting corners is "an hour of savings today, 5 hours of cost tomorrow". I've worked on too many projects that raced to cram in features by a deadline, and ended up with a sloppy app that took forever to maintain and made developers miserable. Far better to take a measured pace and ensure that rapid development can happen in months 12-24, not just months 1-3. Especially in startups - startups are a marathon, not a sprint.

Of course, cutting corners isn't the only kind of code debt, and the author makes some good points. If you're spiking something or prototyping it, and intend to rewrite or throw away, technical debt might be a good tradeoff.

I also take issue with this:

Early on at IMVU, we incorporated in tons of open source projects. This was a huge win... The downside was that we had to combine dozens of projects whose internal architectures, coding styles, and general quality varied widely. It took us a long time to pay off all the debt that incurred – but it was worth it.

The more you can offload to open source libraries or third party APIs, the less your application has to do, and the less you have to maintain. If the library or API sucks, then sure - you're incurring technical debt. But if the library/API is good, or you can contribute to make it good, then it's a win all around.

Sometimes it makes sense to take that hour of savings today at the cost of 5 hours later, though. I've been on projects where we knew a competitor was coming to market soon, and sacrificed a bit on code quality to beat them. We ended up launching 2 weeks before they did, which meant that when they finally did launch, the press was all like "But can they compete with Company X, who launched a similar feature two weeks ago?" Doing things the right way would've added about another month and a half - if we'd paid that cost up-front, the press reaction may've been "But their relevance may be fading, because Company Y launched similar features a month ago."

I agree. You really have to be disciplined to do this, though, because there is always something in a startup that needs to be done right now. Rushing for a month and then taking two weeks to refactor/improve code is fine. But doing the same for 12 months is a big gamble.

I also take issue with this:

Early on at IMVU, we incorporated in tons of open source projects. This was a huge win... The downside was that we had to combine dozens of projects whose internal architectures, coding styles, and general quality varied widely. It took us a long time to pay off all the debt that incurred – but it was worth it.

I think that's more or less exactly the point he makes. Some external dependencies are good, some are dreadful. At some point, you need to address the bad ones.

I tell my clients that cutting corners is "an hour of savings today, 5 hours of cost tomorrow".

Re: cutting corners, it really depends what you mean by "cutting corners". There's a whole continuum of code quality from "omg this sucks I want to kill the person who wrote it" to "this is the most beautiful piece of code every designed by man. Anything short of the latter is effectively incurring debt. I don't think Eric Ries is advocating dirty, nasty coding. Instead, I'd say he's suggesting that you should be comfortable with not writing the best possible code, rather than always feel like you're not doing well enough.

I don't entirely agree with the last paragraph. IMO you should ALWAYS write the best possible code. Any assertion otherwise is equivalent to saying you should be willing to put bad code into production.

The trick isn't in reducing code quality to save time. The trick is simplicity. Too often developers equate quality and complexity; the two are orthogonal.

A simple architecture with high-quality code will take far less effort to maintain than a complex architecture with high-quality code OR a simple architecture with low-quality code.

In my experience, the vast majority of the technical debt I've seen has resulted from building complex solutions to simple problems.

Keeping the solutions as simple as possible to fit the needs of the project is a very good way to keep down technical debt AND facilitate rapid development.

Reply on news.ycombinator.com