How You Can Leverage Technical Debt & Why You Should
Neap Nic
1386

“Technical debt” is unavoidable. But to me this post glosses over the issue of “wrong by design”. I think that it ignores the cost of throwing away a software base.

I can’t tell what exactly Neap is. Looking at the Twitter feed it looks like there’s a lot of reference to phone apps. Building phone apps and building scalable web applications tends to be two different things. Often you can get away with hacking something out with a phone app. That is not true of a scalable web application like nderground.

I built nderground to scale. This has a real cost. But I do not want to arrive at a place where the architecture is wrong. I simply can’t afford to throw away tens of thousands of lines of Groovy/Java code.

Instead of putting all of the data in RDS/Postgres, I only put transactional data in Postgres (data where I need ACID reliability). All other data is stored in S3 and DynamoDB. This means that nderground will scale. But implementing AWS services is time consuming (especially given the documentation).

I’ve come to the conclusion that you might was well build to succeed. And for a Web application that means building to scale.

As to not hiring experienced people: you get what you deserve.

I could build nderground because of decades of experience with software architecture. I see in this post the implication that experience people can’t hack. Well, fuck that.

Inexperienced people can’t do architecture. They constantly rewrite their systems because they didn’t have the experience to build them on a strong foundation the first time.

Here’s the thing about code: the less you have to write, the better. The objective is not to hack out a huge code base. The more code you have, the more bugs you have. So someone who just hacks out a huge volume of software is not a big asset to your start-up.

The objective is to build a strong foundation and leverage as much reliable software as you can. That’s why nderground is built using Grails. nderground can leverage the massive Java infrastructure. That means there’s less software to write and fewer bugs.