38 ms·

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

by swombat 17y ago

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.

Tamerlin 17y ago
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.

by swombat 17y ago

Tamerlin 17y ago

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.