Ask HN: The startup I just joined is in massive disrepair. What to do?
19 comments
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.
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.
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....?)
How long have you been with the company? Do you like the people you work with?
I've been with the company less than a week now. I like my coworkers a lot.
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.
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.
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.
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.
This is so far my most likely plan of action. You are a sage!
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.
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.
Be very careful, expect if you were specifically engaged to fix that kinds of issues, that's fine. Otherwise you might end up in the role of the guy who is disatisfied of anything he does.
Get some things out first, once you get more confiance from others, it'll be ok. Keep in mind that they have no reasons to trust you more that people that have worked with them for month, years before.
Beyond there might be extra issues/constraints that you do not know, that might have lead the code to end up in the state it currently is.
Get some things out first, once you get more confiance from others, it'll be ok. Keep in mind that they have no reasons to trust you more that people that have worked with them for month, years before.
Beyond there might be extra issues/constraints that you do not know, that might have lead the code to end up in the state it currently is.
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).
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).
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.
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.
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.
(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.
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 :)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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...
>"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.
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.
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.
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.
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".
The rabbit hole just keeps on getting crazier.
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.
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.
I see four options:
1) Don't do anything. Watch the company crumble and struggle to hire new engineers.
2) Bring up the issues I've noted here with the CTO and see what happens.
3) Rewrite the codebase in a maintainable format and present it to everyone without telling the CTO.
4) Quit.
What do I do?