

Ask HN: The startup I just joined is in massive disrepair. What to do? - throwmeawaynow

First off, this is a throwaway. I'm an active member here, and in such a dire situation I have to turn to you guys to see what you will make of it.<p>The short story, for those of you who hate reading, is that I recently joined a startup. I expected things to be in good technical shape, but they're not. At all. In fact it's really fucked up.<p>Long story, if you've gotten this far. In my interview with the CTO, I was told that the language of choice was Java (I haven't any professional Java experience). I told him it wasn't a problem (which it's not). I started last week.<p>When I first stepped in the office last Wednesday, the code was uncompilable outside of Eclipse. Then I was in a meeting where the CTO mentioned how there is Java code in XSP templates (I didn't know what these were before this, god bless my soul now) that generates Javascript. This was good, he reasoned, "because Java and Javascript are so similar".<p>The rabbit hole just keeps on getting crazier.<p>I was tasked yesterday with writing some code to "log requests to the database". Shivers. There is no documentation, my entire first day was spent installing jar files, and there are hardcoded paths littered throughout the codebase.<p>The flipside is that the company is profitable. People are buying our stuff. And getting lots of investment. I'm considering bringing the issue up with the CEO, because I see the current situation as being a huge liability in terms of getting smart people to join the team.<p>I see four options:<p>1) Don't do anything. Watch the company crumble and struggle to hire new engineers.<p>2) Bring up the issues I've noted here with the CTO and see what happens.<p>3) Rewrite the codebase in a maintainable format and present it to everyone without telling the CTO.<p>4) Quit.<p>What do I do?
======
hackoder
I'm in a very similar situation to yours: A startup using java, quite
profitable, outside funding, bad code, stubborn CTO, database used as dumping
ground for everything: logs/stats/messages etc (this is very wrong when you're
working at the kind of scale that we're at).

(Hey...! Are you the new guy that sits by the water cooler?! I hope thats not
my code you were talking about!)

Here's what I did:

\- I ended up getting into a small argument with the CTO. He now knows that
I'm smart enough and treats me with respect. I stood my ground but also
offered solutions to improve and also accepted some of theirs.

\- After working for a few months, I've realized that even though there are
bad parts, some parts are actually good. New/other devs are improving the
codebase.

\- I file bugs with regularity- I didn't do this at the start but just picked
it up. This way things that I come across go into a bug tracking system and
can be handled eventually.

\- Now that I'm involved in more parts of the code, I can refactor small bits
as I come across them with my daily tasks/projects.

\- There are other things that I'm collecting in a document which I'll
converse with the PM etc about. Most importantly all these will be things that
I can do and will not blame the CTO. For e.g. setting up a wiki, documenting
the setup process for a new dev (win/unix both), common errors, people on the
team, machine ips, purpose for each machine etc.

You have to realize that the world isn't ideal. Because of whatever reasons
(bad coders, managers, deadlines etc) projects end up in a crappy state all
the time. Make small changes to help and improve that, and you'll be worth
100x more to the company rather than if you just whine about it and blame
someone else.

Note that this isn't about accepting crap policies just so you can have an
income- this is about realizing that a lot of this stuff is common and being
able to improve it. Also realize that you dont know everything in your first
week. Your views will certainly change in the coming months.

Finally, the company is _profitable_. A lot of companies get that way by
making compromises in the short term (one of those might be bad code quality).
This is a situation that can be improved upon. Bad code and a profitable
company is a better combination than elegant code and a bankrupt company.

------
patio11
Now is the perfect time to start refactoring and start using standard,
repeatable processes. You can sell it to the CTO as paying down technical debt
to bring new hires onboard quicker, make the code more robust for expansion,
and give you intimate familiarity with the code base.

Step one: single step, reproducible build process. This could take weeks (been
there done that) but it prevents the business entirely stopping if one of your
hidden dependencies dies on you.

Step two: documented Hello Newbie guide to turning a factory defAult machine
into a development environment in under an hour.

~~~
throwmeawaynow
This is so far my most likely plan of action. You are a sage!

~~~
shalmanese
Be careful though. You want to make sure that you get the appropriate
recognition for your work. Unless something is done explicitly to counter it,
the default is that unsexy work does not receive recognition commensurate with
it's impact. And paying down technical debt is the definition of unsexy work.

If the company is tech savvy enough (and it doesn't seem like it is), work
with stakeholders ahead of time to define key metrics and how they are
impacting the bottom line of the business. Then, get everyone to agree on what
the current values for all key metrics are and try and establish goals &
milestones you are shooting for.

eg: Time to deploy a release right now is 5 hours. This impacts the business
because developers are unable to push out changes in an agile manner so
currently, we release every 3 weeks. I propose to reduce deployment down to
less than 15 minutes such that we can aim for 3 releases a week. This has
business value because it allows us to respond to customer complaints in an
agile manner and empowers developers to build experimental features that might
end up turning into major business units. The value to the business in terms
of increased customer satisfaction and more innovative development is <you
have to fill this in yourself>

If you don't do this, you risk devoting blood, sweat and tears to a project
which, once you've completed it, everyone forgets how painful the old system
was and assumes that it was always this way.

------
maxklein
You are wrong! The code works. You are hired to make improvements. Do new
stuff, and slowly fix up the parts of the code you don't like.

What you are describing sounds TYPICAL for what people always feel when they
see a large chunk of code they did not write themselves. If you quit here, you
will quit most other jobs.

The correct way is to spend a year with the codebase slowly fixing it up,
while adding features (which is what you are paid to do). If you still feel
the same way after a year, then quit.

For now, you were hired to do a job, and you accepted the challenge. What you
see is how code usually looks like! Good code is rare. If you quit everytime
you see bad code, I guess you're not cut out for software engineering.

That's like a doctor quitting everytime he gets a bunch of patients who insist
on eating junk food and smoking cigarettes.

~~~
imalolz
I agree - I've been in a similar situation where I inherited a huge chunk of
Python code that worked great and played a very significant role in our
product's core, but was horrific to understand or maintain (in Python, of all
things!).

I stuck with it for the past 1.5 years and finally got the green light to
rewrite it from scratch. Because I worked so hard to figure out what the hell
was going on for so long, the actual coding from scratch took less than a
month. Bottom line - if you're being paid well, like the environment and think
the company has potential and that you have room to grow there, give it some
time before you decide to quit.

------
andrewf
I would go with #2, but in a non-confrontational manner.

Presumably the CTO got a lot of the existing codebase into place, and in a
rush. If the flipside of that is that the company has a successful product
which is attracting customers and investors, he had his priorities right.

There is a chance he'll get defensive and attempt to rationalise his
decisions. The odds of this go up if you're confrontational about things.

He may also think he's right on some fronts. He could _be_ right on some
fronts. If every engineer in the company is using Eclipse, is it really a
problem that people haven't spent time making sure the codebase compiles
outside of Eclipse?

I would advise you to be open about the way you would do things, and to do
things that way if you don't encounter opposition. Getting argumentative
and/or getting into commit wars is unlikely to help your cause.

(If you want to keep your job at all costs, shutting your mouth gives you the
best odds, especially if the CTO really is a dick. But it doesn't sound like
that's what you want to do).

~~~
throwmeawaynow
Yeah, absolutely.

You're probably right about everything here. I'm the third engineer, and you
guessed correctly that everyone else is using Eclipse.

I think the best way to go about it may be to formulate my opinion in a way
that makes it clear that I only have the company's best interests at heart,
and this is nothing personal. It's just an honest assessment of the situation.

------
kevinpet
The correct choice is 2. The CTO is the one who's officially tasked with
making those decisions, so that's the channel to go through. I'd approach it
as "this code is very hard to work with for new people coming on board, here
are some suggestions to improve, I'd like to spend 25% of my time working on
cleanup type tasks."

If he's not reasonable, look for another gig.

For now, use the tools the rest of the team is using. For the future, get it
building in ant on Hudson.

Step one on this path is probably to set up a wiki and write a "welcome to
company x, here's how to compile our garbage" page. When it's all laid out in
it's 35 step glory, it'll be apparent that you have a point.

------
brudgers
> _"The flipside is that the company is profitable"_

That's backwards.

The flipside is that the code is spaghetti. Profits are the hit single.

A good CTO puts profits before code aesthetics. The CTO is your boss. Going to
CEO is a bad move.

Option 1: Bad code may limit the companies growth, but businesses can muddle
along with less than optimum processes.

Option 2: Have evidence that the "issues" you anticipate are having an effect
on profitability before having this discussion. After a couple of days you
probably don't have enough information to make that judgment.

Option 3: Rewriting the code base is a team decision.

Good luck.

------
geophile
This sounds fixable, but you absolutely must create some space to fix the
problems. Don't even think about #3 -- it's not doable, and it sounds like the
problem isn't just software. Start with #2, pointing out that it's going to
get impossible to add features, scale, fix bugs, ... until the code and its
environment improves.

Read Joel Spolsky's famous list of 12 things that a software company must do
(<http://www.joelonsoftware.com/articles/fog0000000043.html>). If you aren't
doing at least 9-10 of these, (and it sounds like you don't), you have to fix
that. Or your company will die.

Your CTO may say that he'll fix things as you recommend, and then do nothing.
If that happens, then go to the CEO, and explain why these things have to
happen. If he says the right things and then does nothing, your company will
die. This will all take 6 months to play out, at least. If after 6 months
nothing has changed, you might want to consider your options. But hopefully
your CTO listens and really does something.

If hiring is a top priority, you could point out that the horrendous code and
environment will make it difficult to hire good people. Also, that fixing
things is likely to reduce headcount requirements. Don't make your case in
terms that make sense to you -- make your case in terms that make sense to
your CTO and CEO.

------
rdl
Technical problems at a company in a good market with a good team are the best
problems to have. I'd far prefer that to finding out the team and founders are
fundamentally defective, or that you've built an awesome product with a great
term in a market segment which just doesn't exist (luxury goods for the poor
and homeless, etc.)

Just remember, you need to resolve the technical issues while also building
rapport with the team and maintaining your relationships -- don't win battles
in which screw you in the long term.

------
retube
To be honest this sounds like a pretty typical gig. When you're rushing to get
code together short cuts get made - paths get hard-coded, documentation
doesn't get written.

Your gripes seem fairly minor. Not sure how something compiles in eclipse but
not outside it (env variables, classpath, VM args?). And spending a day
getting set up seems pretty rapid.

1) I don't think the business is going to crumble as a result of these issues.
In fact it sounds quite the reverse, what with the investment and sales the
business is making. If you quit they'll hire someone else who's maybe a bit
more realistic about what real-world code bases look like.

2) You don't want to starting whining too early. Go with the flow, make
incremental improvements as you go forward.

3) No. This will be a big job, and many things will have been doen the way
they are for a reason. You risk annoying all your colleagues this way, and
potentially creating more work when stuff breaks.

4) As I said above, this sounds pretty typical. Knuckle down. You are after
all moving to a new language, it will take some time to get up to speed.

------
agranig
The problem is not really specific to your company, we've been in the same
situation also, although we were quite experienced, and I guess it happens to
lots more companies. Fortunately we managed to turn it around.

We've started our company ~4 years ago and got our first customer immediately
without even having a product. We build carrier-grade VoIP platforms for
internet service providers, so it needs to be really reliable, and it needs to
handle hundrets of thousands of customers. So we started out building the
platform on a tight time-line (~6 months from nothing to go-live), taking all
actions necessary to deliver. It was a great success, but it was really
tailored specifically to that customer. Immediately afterwards, we did another
project of that scale, and then another one. All of them worked really well,
we've always been profitable, but it was quite hard to maintain them, let's
put it that way. Beside that, it was next to impossible to scale the business
in a reasonable way while keeping up the product's quality.

In order to fix this issue, we decided to make a bold move and planned to
release the product as open-source (we're quite deeply involved in different
large open-source projects, so we know the business behind it quite well).
This forced us to convert the platform into a stage that literally everybody
can install and maintain it. We hired two people to help us ripping apart all
the different parts, review, package and document them, re-put them together
in a standardized way and create a software bundle which allows reproducable
builds (there are like 100 different software components involved, half of
them from other open-source projects, half of them from us, and they need to
be integrated with each other really tightly).

The result was a clean, well-documented platform, which now can be installed
within 15 minutes with very small manual intervention. It now also allows
seamless software upgrades, and we can plug different commercial modules on
top of it to still have a viable business model. We're going to release it to
the public next week, so we definitely succeeded cleaning up our mess. It took
us 18 months to do so though, so it's hard, it costs a lot of resources
(money, time, dedication of the people behind it), but it's definitely
possible.

We did a presentation (sorry, German only, but you'll still get the idea I
guess) about the concepts of it, see
[http://glt09.linuxtage.at/slides/hochverfuegbare_voip-
system...](http://glt09.linuxtage.at/slides/hochverfuegbare_voip-
systeme_im_carrier-umfeld-glt09.pdf)

------
garrettgillas
The situation you are in sounds fixable but by no means easy. I agree with
patio11 in that you need to start trying to make changes incrementally and try
to presently in as positive manner to others as possible. Never try to start a
conversation with the phrase "so there's this really messed up code that I'd
like to fix".

The classic mistake that young, hungry developers make is wanting to come in
and shake things up by pointing out everything wrong and then trying to come
off as a savior by fixing everything. While this may actually be the possible,
it's not likely how your PM or CTO will see it. More likely you will just be
perceived as a "Dwight Schrute" and regarded similarly.

I would say go with your option #2 but make sure to:

A) Make changes in as small of increments as possible. Don't even call them
changes. It's less recognition but will be easier to pull of in the long run.

B) Make sure you don't hold back on crediting yourself in the documentation
though since that's what new hires will see first and should also be the first
"change" that you make.

C) Make sure that you communicate any changes that you make in as positive of
a manner as possible at all times. This is key for reducing resistance. You
will probably basically find yourself having to regularly "sell" things such
as new libraries, IDEs, ect...

D) If you consistently face ongoing frustration don't hesitate to send out
resumes and job apps. Even if your not serious I find that getting "We'd like
you stop by next week for an interview..." emails have been a great stress
reducer when I've been frustrated with my job.

Anyway, that's probably more crappy advice than you need so I'll stop there.
Honestly if I were in your situation, from what it sounds like, I would only
give myself about a 20% chance of actually being able to stay there with my
sanity.

------
fooandbarify
I agree with what others have said - if I were you, I would go for #2, and if
that fails, #4. If you like your co-workers and the other non-codebase related
aspects of the job, it is worth trying to make it work, but only if you can
get the CTO on board :)

------
mahmud
You were hired to engineer, so, fix things.

No one steps into their ideal work place, we all get crap and make it work.
Get your house in order, demand more power, put in more hours than you're paid
to, show initiative.

------
bitmonki
Have you asked the CTO (or another engineer) about the history of the
codebase? It certainly sounds like they were busy getting something working,
with little time for niceties.

After getting a bit more background, then maybe you could suggest that since
there are now paying customers, maintainability has gained significantly in
importance, especially since the company has gained a much better idea of what
works for the customers.

------
rgrieselhuber
Lots of good advice here.

One other thing to keep in mind: everything is a business decision, whether or
not the people knew it when they built it.

He may not be a great CTO but they do have a profitable product. There are
many companies with beautiful code bases and no money.

------
PloniAlmoni
How long have you been with the company? Do you like the people you work with?

~~~
throwmeawaynow
I've been with the company less than a week now. I like my coworkers a lot.

------
manicbovine
I find it most efficient to simply ask questions in these situations. (e.g.
"Why do we ...?", "Have we discussed...?", "Is it a concern that....?)

------
pitdesi
I think #2 is the best option... If the CTO still doesn't have a clue, then
you consider #4, but there's no reason you shouldn't be completely upfront
with the CTO first.

~~~
throwmeawaynow
That's also my first inclination. I wouldn't want to do something that's
completely rash and burn bridges. OTOH, I'm not really sure how I might bring
it up.

------
aneth
As with any problem, I think the solution is to solve it:

1) Identify the problem

2) Come up with a solution

3) Present to your CTO

Don't just complain. That's probably the worst thing you can do. You might
hint that you feel things need work and offer to fix them before putting too
much effort in. If you're shut down, start looking for a new job.

If it was your company, what would you want your new engineer to do?
Definitely not just identify the problem - because that's just easy and
doesn't carry much credibility. Nobody likes a nay-sayer.

