

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

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).<p>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.<p>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):<p>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.<p>b) The code is more tightly coupled than not, which is making life tough when implementing new features. Many parts could be refactored.<p>c) There is no unit testing, which makes things harder than they should be when it comes to testing/hunting bugs.<p>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.<p>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.<p>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.<p>I'm the only engineer right now; we're funded and looking to hire more people, but it's going slowly.<p>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.
======
chill1
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.

------
brownegg
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!

------
codewright
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.

------
debacle
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.

------
duiker101
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.

