Ask HN: product doing very well but growing technical debt; what to do? | Hacker News Reader

Ask HN: product doing very well but growing technical debt; what to do?

6 pointsunderthesea5 comments

About 4 months ago, I joined a friend of mine as a tech co-founder for a company he had been working on (he's biz, and darn good at it).

He had been contracting out the code for the MVP, and as things were working out, he figured it was time to fully delve into it and bring a full time cofounder on board. The contractor had no interest in doing so, and that's where I came in.

The code has been working well for all intents and purposes, and we have users (in the high 4 digits) who use the product everyday and love it, but it's showing limitations. Here's a quick overview (it's a Django webapp):

a) There are many inefficiencies in the code, and now that our userbase is starting to grow fast, it is causing major slowdowns. My current solution is to throw more dynos at it, which sort of works but is an ugly temporary workaround.

b) The code is more tightly coupled than not, which is making life tough when implementing new features. Many parts could be refactored.

c) There is no unit testing, which makes things harder than they should be when it comes to testing/hunting bugs.

d) Nothing is commented; and even though Python tends to be somewhat self-explanatory, it gets pretty dense when trying to understand what certain things do.

e) The architecture of it all is very monolithic; based on our plans for the future business development, quite a few parts should be decoupled and made more independent of each other.

A full rewrite seems out of the question, as we have many users and we need to keep on moving with bug fixing + shipping new features. For that same reason, it's hard for me to justify blocking 2 weeks to refactor a subpart of the application.

I'm the only engineer right now; we're funded and looking to hire more people, but it's going slowly.

Has anyone been in a similar situation before? Any recommended books/articles? If you're in SF and have relevant experience, I'll gladly buy you lunch in exchange for your thoughts.

I have limited knowledge of Python / Django, but I have quite a lot of experience dealing with large projects in PHP and many of the frameworks and applications built with it.

Are you using Git for your source control? If so, you may want to start a new branch and work in it before doing any major re-factoring.

To start, I would try to find a small part of the application that you feel would be possible to re-factor in an hour or so. Before changing anything, I would load up the app locally in your browser and navigate to the portion that is dependent upon the code you're going to re-factor. Then I would re-factor things in as small a chunk as possible, constantly checking in the browser to make sure things still work properly. This is a rather bastardized approach to test driven development, but it can be quick and effective.

> The architecture of it all is very monolithic; based on our plans for the future business development, quite a few parts should be decoupled and made more independent of each other.

As a side note.. This type of thing I have seen way too much of in my time in the industry. It's very easy to get carried away and over-engineer a solution. I've found it's best to create a solution that solves only the problems you currently need solved. It's always easier to go back and extend while re-factoring than it is to try to re-factor a giant-freakin'-thing after the fact.

Congrats on your success--you have the best kind of problem.

1. You have a working product--do not do a full rewrite. Rewriting has so many pitfalls in the best of cases, and if it's just you, the context switches between the "old" (which you will still be spending most of your time maintaining) and the "new" systems will be brutal.

2. This is the prototypical "real world" case. You're basically asking how you can prioritize immediate enhancements vs. long-term flexibility and maintainability. But maintainability is a feature. Any (good) book on agile development methodologies will tell you that consistent refactoring and cleaning of the code has direct user benefit, in that future velocity (user enhancements) will be better.

3. The prudent way forward is to chip away at the problems. As you "touch" various parts of the system, start doing small refactoring work, adding comments, tests, etc. Remember, you're starting from nothing--anything you do in this regard is improving your situation.

4. If you're not doing some sort of iterative development methodology, start. Personally, I have a preference for Scrum, because of its time-boxed nature. It lends itself well to devoting a section of each dev cycle (sprint) to the kind of cleanup work you need to do.

Good luck!

I have a fair amount of experience dealing with this, as a contractor, full-time employee, and CTO. My background is even predominantly Python (used to do Django back in the 1.0-1.2 days).

The best advice I can give you is to do it step by step and don't let yourself get overwhelmed. It's just work. Just do the work. Here are some steps to take:

1. Start cleaning up and commenting the code. Start using a linter. Don't attempt to refactor aggressively here. Don't refactor at all. Just surface details for now.

2. Start adding unit and functional tests. If you have an API, test against it. As much coverage as possible.

3. Start refactoring, breaking things, then fixing the tests.

4. Repeat #3 until it's a clean codebase. This is the point at which you'd start looking at performance and coupling too.

A little bit at a time and don't get overwhelmed.

I'll send the consultancy invoice tomorrow.

1. Introduce continuous integration.

2. Slice up the codebase with encapsulation. If you have something that is incredibly tightly coupled that you can't refactor, just put a bubble around it.

3. Base all of your optimizations on statistical analysis of your logs. If you don't have log data to that level, introduce some RUM.

b,c,d and sometimes even e,a are normal, I would say, normal, every company has them, because we can always do better but we have always too little time. If you are making any money try to hire someone to give you some help.

Reply on news.ycombinator.com