8 ms·

> this code generates more than 20 million dollars a year of revenue From a business perspective, nothing is broken. In fact, they laid a golden goose. > team

by fny 4y ago

> this code generates more than 20 million dollars a year of revenue From a business perspective, nothing is broken. In fact, they laid a golden goose. > team is 3 people, quite junior. One backend, one front, one iOS/android. Resistance to change is huge. My mistake, they didn't lay a golden goose--they built a money printer. The ROI here is insane. > productivity is abysmal which is understandable. The mess is just too huge to be able to build anything. But you just told me they built a $20M revenue product with 3 bozos. That sounds unbelievably productive. > This business unit has a pretty aggressive roadmap as management and HQ has no real understanding of these blockers You should consider quitting your job. As far as the business is concerned, there are no problems... because well... they have a money printer, and your team seems not to care enough to advocate for change. Business people don't give a damn about code quality. They give a damn about value. If 2003 style PHP code does that, so be it. Forget a rewrite, why waste time and effort doing simple refactoring? To them, even that has negative financial value. From their perspective, you're not being paid to make code easy to work with, you're being paid to ship product in a rats nest. Maybe you could make a business case for why its valuable to use source control, dependency management, a framework, routing outside of nginx, and so on... but it doesn't sound like any of that mattered on the road to $20M a year, so it will be very difficult to convince them otherwise especially if your teammates resist. This, again, is why you should consider leaving. Some developers don't mind spaghetti, cowboy coding. You do. Don't subject yourself to a work environment and work style that's incompatible with you, especially when your teammates don't care either. I guarantee you will hate your job.

ncmncm 4y ago
$20M revenue is not the same as $20M profit.
- hnfong 4y ago
  > team is 3 people, quite junior. Even at FAANG salaries this wouldn't be that much compared with $20M
  - colinmhayes 4y ago
    You don't know what the costs are though. The site could have huge costs of content acquisition or any number of reasons to not be making anywhere near $20 million profit.
  - k8sToGo 4y ago
    The engineering team might be 3 people but not the whole company.
  - jtsiskin 4y ago
    Yes, but the parent is saying this could be an e-commerce website, or construction company, etc. But having an iOS app feels unnecessary for most of these businesses
    - zem 4y ago
      a lot of field operations these days are done on phone or tablet apps, so I can totally see an ios developer being vital for internal processes
  - OJFord 4y ago
    Revenue isn't the same as Earnings Before Salaries either. E.g. maybe it's an e-wholesaler or widget reseller, bought $19M goods and sold $20M. Or maybe it was much slower than expected, they actually bought $25M goods and are burning 500k/month on warehousing. Or whatever.
- ivlad 4y ago
  It’s not the same, but if those 20M is primarily generated by the software, then it’s those 3 ppl, who contribute to the top line. The rest, like sales, marketing, are irrelevant: fire them and the product will keep generating revenue off the existing customer base. It will stop doing so, however, if the product brakes. So, the post above is right to an extent, this is the golden goose. ))
  - ncmncm 4y ago
    Unless the revenue is for products ordered on the site and shipped to paying customers. Believe it or don't, this is still done at some sites that are not Amazon.
  - mattmanser 4y ago
    Not if they're spending $19m in google ads to make $20m in revenue.
- snapetom 4y ago
  Assuming profitability is even a problem, if $20M in revenue is coming from just 3 devs, the driving cost of the company isn't the tech. It's other parts of the company. That would be be another red flag against the leadership.
Flankk 4y ago
This is the sanest answer. No amount of leadership is going to help an incompetent team. A codebase with massive technical debt, tight coupling, and accidental complexity will be hard to improve incrementally. Impossible without competent engineers.
- rocqua 4y ago
  I agree it's the sane answer. But I don't think these engineers are incompetent. They lacked direction, accidentally followed worst practices, and _still_ came out on top. I would say they are good engineers but perhaps bad project managers / architects.
  - OJFord 4y ago
    You don't not use source control because nobody directed you to and you 'accidentally' .. what, forgot about it? You don't use it because you haven't heard of it; = not competent.
    - Aeolun 4y ago
      I find it hard to imagine you’d never heard of source control by now. You’d have to have been living under a rock for the past 15 years.
      - hef19898 4y ago
        Or been drinking to much of the "move fast and brake things" koolaid for all of the 5 days of your career.
      - OJFord 4y ago
        Or be a bona fide 'script kiddy', learnt some WordPress PHP or whatever and got a job as 'webmaster' or something straight out of school (UK-sense, I specifically mean no university), no formal CS/software eng. training, never properly an intern/junior trained by people who know what they're doing. I'm sure it happens. And then you get the next job with 5y PHP experience or whatever, employer doesn't mind no formal training (not that I'm saying they should in general - but if they're non-technical hiring someone to 'do it', or first hire to build the team or whatever, then they probably should as a reasonable proxy!), rinse and repeat.
stormbrew 4y ago
I'd bet it's B2B and has an expensive sales division that top management believes (tbh maybe even rightly) is the real revenue driver.
iforgotpassword 4y ago
Best answer. If the money is ok, and the environment not too toxic/stressful, you might just see it as a challenge to secretly improve a codebase without anybody noticing, while still delivering what the higher-ups want to see. Or maybe just scratch the first part and try to see how much further you can push that turd with every coding crime imaginable. One-up the juniors in ugly hack Olympics. Ship a feature and put it on your CV before leaving. Otherwise, walk away immediately.
- unity1001 4y ago
  > a challenge to secretly improve a codebase without anybody noticing That is how it should be done in any case anyway. Improvements should get slowly rolled out without disturbing the users and the business.
  - marcosdumay 4y ago
    > That is how it should be done in any case anyway. Not exactly. IT management should be always telling people stuff like "did you notice that the integration with XYZ that never worked well stopped failing?" or "did you notice that we delivered those few last features at record time?" and explaining why.
    - unity1001 4y ago
      That is assuming that things are failing. $20m/year with 3 people does not look like anything is failing to me.
      - marcosdumay 4y ago
        That is assuming things are improving. If you aren't improving anything, then yeah, you don't have anything to say.
Scarblac 4y ago
It wasn't necessarily written by those 3 devs. They're just the current team. Granted, they probably have been that for a long time because of the resistance to change, but the brightest minds are probably long gone.
dmje 4y ago
Great answer. Developers are gunna hate it
atoav 4y ago
This is why we as a software world need some minimum standards for stuff that deals with sensitive information of users. Don't get me wrong, if it works it works, but the question is for how long and who will suffer when it doesn't? Also from a business perspective: If I were the CEO of that company I'd probably like to know that there is something built on sand and a huge technological dept. It is a cashcow now, but I'd like to ensure it still can be one in the future. And for this some level of maintenance would be expected. Same thing for reliabilty. If as a CEO I knew the entire functioning of the thing that brings the cash hinges on one developer remembering whether index_john-final.php or index_peter-final-final.php is the latest code I would probably have a hard time sleeping. That means the minimum OP should do is explain the situation neutrally and your point of view is certainly something he should weave into this. In the end the higher ups need to know this, and what they decide to do is their thing, but OP needs to make them aware of why this could potentially endanger the service in the future. If they then decide to take that risk — so be it.
Aeolun 4y ago
I think the thing is that the codebase after 5 years of development was already capable of making 19M/year, and the past 7 extra years have just added 1M/year. The next year of development will not add any more because the thing is collapsing under it’s own weight.
- throwaway5371 4y ago
  so it will just be 20 mil a year with 3 jr devs sounds ok?
  - Aeolun 4y ago
    Only in absolute terms. Kind a feels like a missed chance if you actually have a 100M market.
eru 4y ago
>> team is 3 people, quite junior. One backend, one front, one iOS/android. Resistance to change is huge. > My mistake, they didn't lay a golden goose--they built a money printer. The ROI here is insane. We can not make that conclusion. Presumably the business still needs salespeople, support, etc.
- eru 4y ago
  P.S. I am not saying that ROI is bad, either. Just that we can't say very much either way.
kilroy123 4y ago
That's what I was thinking as well. Run for you hills. It's likely a losing up hill battle.
threatripper 4y ago
This is very insightful. I learned it kind of the hard way. The business world is a mess. Requirements are a mess and always changing. This leads to messy code that requires a lot of time to clean up. You don't have time for that as long as there is always more customer wishes and projects coming in. As long as the business keeps working there's always something of top priority coming in. The pain starts growing but the steaming pile of code just doesn't collapse. It just kind of keeps on working while you are adding more and more code. Sure, the pain is big and progress is quite slow but what's the alternative? My advice would be to listen to the developers, to understand them and the business. To understand what they really need. What a viable path forward would be. A complete rewrite, a second system for new developments, many more developers or something. Or maybe it is the optimum solution right now because the whole company is so messy and your job is not to change the company structure. Then you maybe you could support them by slowly enhancing their skill set and accept what you can't change. Doesn't sound like fun? Then leave soon, staying won't do you any good.
mikewarot 4y ago
The profit at all costs, just make the next quarter's numbers (so we get our bonus), attitude is what leads to disasters like Twitter. Their pursuit of profits above all else have likely gotten people killed. They represent a clear and present danger to US National Security.
hef19898 4y ago
Additional reason to switch jobs: It is perfectly working for now, as far as the company is concerned, the three man team is doing a tremendous job, and the team conviced itself of the same. Now they have to ship additional stuff, and think they are perfectly able to do so. You are there to make sure they ship, most likely they wont, because things work until they don't anymore. When they don't, and the team isn't shipping, guess who gets the blame? The one team member, the one thing that changed. And after that, the mess will only grow. Edit: Typos. I suffer severe typing legasteny more often than not...
rendall 4y ago
In my opinion OP should seriously consider this advice. I really mean nothing patronizing here, but I suspect OP does not have the corporate experience to handle this situation. This is a corporate equivalent of a double-black diamond downhill route. OP was hired by people who have little understanding of tech and already came in with guns blazing. I might almost wonder if OP's a sacrificial lamb. But, the tech advice of not doing a rewrite, making tests, soothing any hurt feelings, creating local instances will help. Make the everyday coding experiences of the tech team nicer. Source control, local instances, and unit/integration/E2E tests are a gimme. The old rule of thumb applies: pick only 2 of speed, cost or quality. You cannot have 3.
- unity1001 4y ago
  > OP does not have the corporate experience to handle this situation Even before that, s/he doesn't even seem to understand any measure of business. $20m/year with 3 people is BIG. Any disturbance to whatever makes that happen will hurt the business greatly. When a full rewrite shakes the boat and causes a few millions of revenue loss or the loss of potential market share or opportunities, they will rightly fire him. Best route would be to improve things without hurting anything. It doesn't matter things are 'properly done'. It matters whether the organization survives and prospers. What's 'proper' is redefined every 3-5 years, most of the time without objective basis anyway. So no need to hurt the business to force the current software paradigm.
  - mgkimsal 4y ago
    Is the entirety of the whole company just 3 people? It doesn't sound like it. That 3 person team is just 'tech' it seems - there may be 5-10 managers/sales/support/etc people. And... $20m is revenue, not profit. If the cost of their sales is, say, $15m... and there's 15 people working at the company, that's quite healthy, but it's not some money-printing goldmine at this stage.
    - unity1001 4y ago
      > Is the entirety of the whole company just 3 people? From what is told in the summary, it seems like the software stack and these 3 people constitute the core of the business that is going on. The business may be something totally different. But it seems to be running on that software. > And... $20m is revenue Even if they have lower margins than what you yourself imagined, $20 m revenue/year is still a gigantic amount. You can improve upon whetever margin or inefficiency in the process and increase the net profit - optimize vendors, costs, sales pipeline. The difficulty in modern Internet business is getting to some place at which you can command $20 m revenue from any market. Finding the customers and the users. Not the margins.
tomohawk 4y ago
So there was a physicist, an engineer, and a business guy, and they were discussing God. The physicist said that God must be a physicist, because He had to know about matter and energy and so on. The engineer said that God must be an engineer, because He had to do something useful with the matter and energy - turning chaos into order. And the business guy asked, "Where do you think all that chaos was coming from?"
hcks 4y ago
Good answer. Some developpers seem to think that their jobs is to engineer nice and beautiful systems. It's not. As a developper, you're getting paid (fyi the minimum so you don't leave the company) in order to maximise total shareholders' returns. That's it. The business doesn't care if the codebase is garbage, with massive technical debt, nor if you struggle working with it. That's literally not even a problem as long as it is concerned.
- yjftsjthsd-h 4y ago
  Nice and beautiful systems aren't the job, but a system that will continue working in the future while still allowing people to keep adding features and that won't suffer massive security breaches really is. It sounds like the current system is one bad feature implementation away from hosing the database, one hardware fault away from no longer existing, and one interested hacker away from a complete compromise.
  - hcks 4y ago
    You are right and obviously good engineering practices are not incompatible with the company’s interests. I was more reacting to OPs attitude, where he asks how to fix everything without even being clear if he is managing the team or officially in charge of the product. I may be mistaken but the impression I have is that the management is perfectly happy with a bad system and expects the engineers to simply go along. This is then a management decision. It may blow up later and sink the business (or not, it can just hold for the lifetime of the product). As far as OP is concerned, this situation would mean that he should probably leave the ship now. (As staying would probably result in 1. No marketable skill development (being stuck with a garbage codebase) 2. Burn-out has he takes on the Herculean task of cleaning it up. 3. Be blamed if something bad happens.
- vborovikov 4y ago
  Usually nothing changes for me as a developer if shareholders get bigger returns on their investments. So I don't really care. What I care about is the code quality because good code makes my job easier. I inherited the code, not the business.
Merad 4y ago
This 100%. This line is an immediate nail in the coffin: > This business unit has a pretty aggressive roadmap as management and HQ has no real understanding of these blockers. And post COVID, budget is really tight. I've been at a company not unlike this... several MLOC of VB WinForms that was total spaghetti, but a highly successful app that brought in a lot of revenue. In our case the majority of the dev team was in agreement that the situation wasn't sustainable, and at first (meaning when I joined the company) we had engineering leadership who mostly agreed. They brought in several rounds of consultants to evaluate the code base and announced plans for a major modernization effort. But the consultants largely agreed with the dev team that the code was in such bad shape that it effectively needed a rewrite. At one point we did a prioritization and t-shirt sizing exercise and came up with _30 man years_ worth of items in the "critical tech debt" bucket. Apparently engineering leadership was not aligned with the C level suite about how much money they were willing to spend on this thing, because within the next year there was 100% turnover of management in the engineering org. A couple of (talented!) people who had been hired for the modernization effort left first, then the other engineers who knew the code base well followed. Last I heard the company was limping along relying on Eastern European and Indian contractors to keep the lights on. In short OP, you can probably get some wins; maybe some major process improvements like using source control, maybe more minor things like introducing patterns or frameworks so that net new code isn't a total mess. But there is zero chance that you're to do anything like a rewrite or major refactoring without leadership understanding that they're in an unsustainable situation and a willingness from them to invest time and money to fix it.
- ryandrake 4y ago
  Seems so many of us have been hired at one of these companies. Same here. No source control. No bug tracker. No tests. There was no formal system for producing builds--releases to customers were simply copied from the workstation of whichever engineer could build it successfully today. There were so many bugs and crashes, it was hard to even get through basic customer use cases. There was no spec. There was no product roadmap or plan. Sales would sell something, then run downstairs and say "We just sold XYZ, you need to implement XYZ in the software blob somewhere!" The CEO/Founder wouldn't even consider a refactoring or cleanup session, let alone a full or partial rewrite. Only features drive sales, and we've sold so many things we don't have, so all he wanted was feature cram. Every so often, a VIP customer complained about some major use case that simply didn't work, so only in those cases was bug fixing permitted. And in those cases, the VIP customer would get a custom bespoke build made with the bug fixed. I was hired because the last person of my seniority could not cram features in fast enough and gave up in disgust. They only got source control because I came in on a weekend, unpaid, to do it. I lasted a little over a year. Bootstrapped founder (and sole shareholder) eventually sold the company for ~$150M. Sometimes it seems there is no justice in the world :)
jogjayr 4y ago
Only 3 developers maintaining a horrible codebase is a massive business risk. In this market, they could easily leave for better jobs within months of each other. Especially if they're junior and not company lifers. They money printer will print money until one day, it suddenly doesn't.
humbleMouse 4y ago
mgkimsal 4y ago
> But you just told me they built a $20M revenue product with 3 bozos. That sounds unbelievably productive. This doesn't indicate how profitability, and seems to ignore that management/owners might have had something to do with it. A well-connected industry player is better poised to start/found/build/grow a company to that level than someone with 0 experience. And... yes... quitting to something which matches the OPs expectations will likely be better all around than trying to 'fix' something people aren't asking to be fixed (it seems).
msluyter 4y ago
Exactly. I often think of scenarios such as this in evolutionary terms. Imagine a doppelgänger competitor in this space, exactly the same, except they're pretty content with their crappy tech ecosystem and focus on delivering features (albeit, more slowly than they might with a more modern system.) And so... 1. You focus on the advice here, adding tests (which IMHO is actually pretty difficult on a legacy poorly architected/documented system), source control, refactoring, etc.... with any time remaining in the schedule devoted to adding features. 2. Your doppelgänger chugs along and releases several more features than you do, giving them a market edge. What happens next I suppose depends upon what difference those extra features make. If the delta is small, you may be able to pull out ahead, in the long run. But if it's large, then your company may start to lose revenue / customers. Then, the screws will likely tighten even harder, and you'll be forced to sideline refactoring efforts and double down on delivering features. And then those refactoring/cleanup efforts will bit rot and you'll find yourself back roughly where you started, except now you're behind your competitor. There's a quote I can't seem to find atm that summarizes this. It was something along the lines of "With php our product is already up and gaining market share meanwhile our competitor is still futzing with their rails configurations." (If you know the actual quote I'd love to see it.))
noobermin 4y ago
Sheesh, I had to look this far to find this comment, half of the top comments were discussing how much testing OP should do and what manner he should approach the act of refactoring things while ignoring that the "monster" generates a boat load of money for the company. I love hacker news a lot but people seriously need to get out of their developer box and look at the big picture.
fuzzfactor 4y ago
Smells like executive stupidity to me. There is some consensus that you can't fix stupid. Even if you are very talented at repairing airplane engines in flight.
zcombynator 4y ago
THIS. A million times this. The world is about solving real user problems. And obviously this code solves a huge 20M USD problem. And the code is obviously so good, that even 3 "bozos" (to use your language) can manage and maintain in for decades. This is the holy grail. I wouldn't change a thing and instead ask: how can you make this generate 40M USD a year? This is how you will add real value to the company, and management will love you.
Southclaws 4y ago
If the mess generates $20m a year, that's great and I agree with you! If the mess generated $20m last year and it's projected to generate $20m next year, that's a problem. If the second case is true, I believe it's somewhat the responsibility of the OP to sell solving this long-term problem to the _rest of_ business. If they hired him as an expert in that area, they should listen to him. If that fails, leave.

by fny 4y ago

ncmncm 4y ago

$20M revenue is not the same as $20M profit.

hnfong 4y ago
> team is 3 people, quite junior. Even at FAANG salaries this wouldn't be that much compared with $20M
- colinmhayes 4y ago
  You don't know what the costs are though. The site could have huge costs of content acquisition or any number of reasons to not be making anywhere near $20 million profit.
- k8sToGo 4y ago
  The engineering team might be 3 people but not the whole company.
- jtsiskin 4y ago
  Yes, but the parent is saying this could be an e-commerce website, or construction company, etc. But having an iOS app feels unnecessary for most of these businesses
  - zem 4y ago
    a lot of field operations these days are done on phone or tablet apps, so I can totally see an ios developer being vital for internal processes
- OJFord 4y ago
  Revenue isn't the same as Earnings Before Salaries either. E.g. maybe it's an e-wholesaler or widget reseller, bought $19M goods and sold $20M. Or maybe it was much slower than expected, they actually bought $25M goods and are burning 500k/month on warehousing. Or whatever.
ivlad 4y ago
It’s not the same, but if those 20M is primarily generated by the software, then it’s those 3 ppl, who contribute to the top line. The rest, like sales, marketing, are irrelevant: fire them and the product will keep generating revenue off the existing customer base. It will stop doing so, however, if the product brakes. So, the post above is right to an extent, this is the golden goose. ))
- ncmncm 4y ago
  Unless the revenue is for products ordered on the site and shipped to paying customers. Believe it or don't, this is still done at some sites that are not Amazon.
- mattmanser 4y ago
  Not if they're spending $19m in google ads to make $20m in revenue.
snapetom 4y ago
Assuming profitability is even a problem, if $20M in revenue is coming from just 3 devs, the driving cost of the company isn't the tech. It's other parts of the company. That would be be another red flag against the leadership.

Flankk 4y ago

This is the sanest answer. No amount of leadership is going to help an incompetent team. A codebase with massive technical debt, tight coupling, and accidental complexity will be hard to improve incrementally. Impossible without competent engineers.

rocqua 4y ago
I agree it's the sane answer. But I don't think these engineers are incompetent. They lacked direction, accidentally followed worst practices, and _still_ came out on top. I would say they are good engineers but perhaps bad project managers / architects.
- OJFord 4y ago
  You don't not use source control because nobody directed you to and you 'accidentally' .. what, forgot about it? You don't use it because you haven't heard of it; = not competent.
  - Aeolun 4y ago
    I find it hard to imagine you’d never heard of source control by now. You’d have to have been living under a rock for the past 15 years.
    - hef19898 4y ago
      Or been drinking to much of the "move fast and brake things" koolaid for all of the 5 days of your career.
    - OJFord 4y ago
      Or be a bona fide 'script kiddy', learnt some WordPress PHP or whatever and got a job as 'webmaster' or something straight out of school (UK-sense, I specifically mean no university), no formal CS/software eng. training, never properly an intern/junior trained by people who know what they're doing. I'm sure it happens. And then you get the next job with 5y PHP experience or whatever, employer doesn't mind no formal training (not that I'm saying they should in general - but if they're non-technical hiring someone to 'do it', or first hire to build the team or whatever, then they probably should as a reasonable proxy!), rinse and repeat.

stormbrew 4y ago

I'd bet it's B2B and has an expensive sales division that top management believes (tbh maybe even rightly) is the real revenue driver.

iforgotpassword 4y ago

Best answer. If the money is ok, and the environment not too toxic/stressful, you might just see it as a challenge to secretly improve a codebase without anybody noticing, while still delivering what the higher-ups want to see. Or maybe just scratch the first part and try to see how much further you can push that turd with every coding crime imaginable. One-up the juniors in ugly hack Olympics. Ship a feature and put it on your CV before leaving. Otherwise, walk away immediately.

unity1001 4y ago
> a challenge to secretly improve a codebase without anybody noticing That is how it should be done in any case anyway. Improvements should get slowly rolled out without disturbing the users and the business.
- marcosdumay 4y ago
  > That is how it should be done in any case anyway. Not exactly. IT management should be always telling people stuff like "did you notice that the integration with XYZ that never worked well stopped failing?" or "did you notice that we delivered those few last features at record time?" and explaining why.
  - unity1001 4y ago
    That is assuming that things are failing. $20m/year with 3 people does not look like anything is failing to me.
    - marcosdumay 4y ago
      That is assuming things are improving. If you aren't improving anything, then yeah, you don't have anything to say.

Scarblac 4y ago

It wasn't necessarily written by those 3 devs. They're just the current team. Granted, they probably have been that for a long time because of the resistance to change, but the brightest minds are probably long gone.

dmje 4y ago

Great answer. Developers are gunna hate it

atoav 4y ago

This is why we as a software world need some minimum standards for stuff that deals with sensitive information of users. Don't get me wrong, if it works it works, but the question is for how long and who will suffer when it doesn't? Also from a business perspective: If I were the CEO of that company I'd probably like to know that there is something built on sand and a huge technological dept. It is a cashcow now, but I'd like to ensure it still can be one in the future. And for this some level of maintenance would be expected. Same thing for reliabilty. If as a CEO I knew the entire functioning of the thing that brings the cash hinges on one developer remembering whether index_john-final.php or index_peter-final-final.php is the latest code I would probably have a hard time sleeping. That means the minimum OP should do is explain the situation neutrally and your point of view is certainly something he should weave into this. In the end the higher ups need to know this, and what they decide to do is their thing, but OP needs to make them aware of why this could potentially endanger the service in the future. If they then decide to take that risk — so be it.

Aeolun 4y ago

I think the thing is that the codebase after 5 years of development was already capable of making 19M/year, and the past 7 extra years have just added 1M/year. The next year of development will not add any more because the thing is collapsing under it’s own weight.

throwaway5371 4y ago
so it will just be 20 mil a year with 3 jr devs sounds ok?
- Aeolun 4y ago
  Only in absolute terms. Kind a feels like a missed chance if you actually have a 100M market.

eru 4y ago

>> team is 3 people, quite junior. One backend, one front, one iOS/android. Resistance to change is huge. > My mistake, they didn't lay a golden goose--they built a money printer. The ROI here is insane. We can not make that conclusion. Presumably the business still needs salespeople, support, etc.

eru 4y ago
P.S. I am not saying that ROI is bad, either. Just that we can't say very much either way.

kilroy123 4y ago

That's what I was thinking as well. Run for you hills. It's likely a losing up hill battle.

threatripper 4y ago

This is very insightful. I learned it kind of the hard way. The business world is a mess. Requirements are a mess and always changing. This leads to messy code that requires a lot of time to clean up. You don't have time for that as long as there is always more customer wishes and projects coming in. As long as the business keeps working there's always something of top priority coming in. The pain starts growing but the steaming pile of code just doesn't collapse. It just kind of keeps on working while you are adding more and more code. Sure, the pain is big and progress is quite slow but what's the alternative? My advice would be to listen to the developers, to understand them and the business. To understand what they really need. What a viable path forward would be. A complete rewrite, a second system for new developments, many more developers or something. Or maybe it is the optimum solution right now because the whole company is so messy and your job is not to change the company structure. Then you maybe you could support them by slowly enhancing their skill set and accept what you can't change. Doesn't sound like fun? Then leave soon, staying won't do you any good.

mikewarot 4y ago

The profit at all costs, just make the next quarter's numbers (so we get our bonus), attitude is what leads to disasters like Twitter. Their pursuit of profits above all else have likely gotten people killed. They represent a clear and present danger to US National Security.

hef19898 4y ago

Additional reason to switch jobs: It is perfectly working for now, as far as the company is concerned, the three man team is doing a tremendous job, and the team conviced itself of the same. Now they have to ship additional stuff, and think they are perfectly able to do so. You are there to make sure they ship, most likely they wont, because things work until they don't anymore. When they don't, and the team isn't shipping, guess who gets the blame? The one team member, the one thing that changed. And after that, the mess will only grow. Edit: Typos. I suffer severe typing legasteny more often than not...

rendall 4y ago

In my opinion OP should seriously consider this advice. I really mean nothing patronizing here, but I suspect OP does not have the corporate experience to handle this situation. This is a corporate equivalent of a double-black diamond downhill route. OP was hired by people who have little understanding of tech and already came in with guns blazing. I might almost wonder if OP's a sacrificial lamb. But, the tech advice of not doing a rewrite, making tests, soothing any hurt feelings, creating local instances will help. Make the everyday coding experiences of the tech team nicer. Source control, local instances, and unit/integration/E2E tests are a gimme. The old rule of thumb applies: pick only 2 of speed, cost or quality. You cannot have 3.

unity1001 4y ago
> OP does not have the corporate experience to handle this situation Even before that, s/he doesn't even seem to understand any measure of business. $20m/year with 3 people is BIG. Any disturbance to whatever makes that happen will hurt the business greatly. When a full rewrite shakes the boat and causes a few millions of revenue loss or the loss of potential market share or opportunities, they will rightly fire him. Best route would be to improve things without hurting anything. It doesn't matter things are 'properly done'. It matters whether the organization survives and prospers. What's 'proper' is redefined every 3-5 years, most of the time without objective basis anyway. So no need to hurt the business to force the current software paradigm.
- mgkimsal 4y ago
  Is the entirety of the whole company just 3 people? It doesn't sound like it. That 3 person team is just 'tech' it seems - there may be 5-10 managers/sales/support/etc people. And... $20m is revenue, not profit. If the cost of their sales is, say, $15m... and there's 15 people working at the company, that's quite healthy, but it's not some money-printing goldmine at this stage.
  - unity1001 4y ago
    > Is the entirety of the whole company just 3 people? From what is told in the summary, it seems like the software stack and these 3 people constitute the core of the business that is going on. The business may be something totally different. But it seems to be running on that software. > And... $20m is revenue Even if they have lower margins than what you yourself imagined, $20 m revenue/year is still a gigantic amount. You can improve upon whetever margin or inefficiency in the process and increase the net profit - optimize vendors, costs, sales pipeline. The difficulty in modern Internet business is getting to some place at which you can command $20 m revenue from any market. Finding the customers and the users. Not the margins.

tomohawk 4y ago

So there was a physicist, an engineer, and a business guy, and they were discussing God. The physicist said that God must be a physicist, because He had to know about matter and energy and so on. The engineer said that God must be an engineer, because He had to do something useful with the matter and energy - turning chaos into order. And the business guy asked, "Where do you think all that chaos was coming from?"

hcks 4y ago

Good answer. Some developpers seem to think that their jobs is to engineer nice and beautiful systems. It's not. As a developper, you're getting paid (fyi the minimum so you don't leave the company) in order to maximise total shareholders' returns. That's it. The business doesn't care if the codebase is garbage, with massive technical debt, nor if you struggle working with it. That's literally not even a problem as long as it is concerned.

yjftsjthsd-h 4y ago
Nice and beautiful systems aren't the job, but a system that will continue working in the future while still allowing people to keep adding features and that won't suffer massive security breaches really is. It sounds like the current system is one bad feature implementation away from hosing the database, one hardware fault away from no longer existing, and one interested hacker away from a complete compromise.
- hcks 4y ago
  You are right and obviously good engineering practices are not incompatible with the company’s interests. I was more reacting to OPs attitude, where he asks how to fix everything without even being clear if he is managing the team or officially in charge of the product. I may be mistaken but the impression I have is that the management is perfectly happy with a bad system and expects the engineers to simply go along. This is then a management decision. It may blow up later and sink the business (or not, it can just hold for the lifetime of the product). As far as OP is concerned, this situation would mean that he should probably leave the ship now. (As staying would probably result in 1. No marketable skill development (being stuck with a garbage codebase) 2. Burn-out has he takes on the Herculean task of cleaning it up. 3. Be blamed if something bad happens.
vborovikov 4y ago
Usually nothing changes for me as a developer if shareholders get bigger returns on their investments. So I don't really care. What I care about is the code quality because good code makes my job easier. I inherited the code, not the business.

Merad 4y ago

This 100%. This line is an immediate nail in the coffin: > This business unit has a pretty aggressive roadmap as management and HQ has no real understanding of these blockers. And post COVID, budget is really tight. I've been at a company not unlike this... several MLOC of VB WinForms that was total spaghetti, but a highly successful app that brought in a lot of revenue. In our case the majority of the dev team was in agreement that the situation wasn't sustainable, and at first (meaning when I joined the company) we had engineering leadership who mostly agreed. They brought in several rounds of consultants to evaluate the code base and announced plans for a major modernization effort. But the consultants largely agreed with the dev team that the code was in such bad shape that it effectively needed a rewrite. At one point we did a prioritization and t-shirt sizing exercise and came up with _30 man years_ worth of items in the "critical tech debt" bucket. Apparently engineering leadership was not aligned with the C level suite about how much money they were willing to spend on this thing, because within the next year there was 100% turnover of management in the engineering org. A couple of (talented!) people who had been hired for the modernization effort left first, then the other engineers who knew the code base well followed. Last I heard the company was limping along relying on Eastern European and Indian contractors to keep the lights on. In short OP, you can probably get some wins; maybe some major process improvements like using source control, maybe more minor things like introducing patterns or frameworks so that net new code isn't a total mess. But there is zero chance that you're to do anything like a rewrite or major refactoring without leadership understanding that they're in an unsustainable situation and a willingness from them to invest time and money to fix it.

ryandrake 4y ago
Seems so many of us have been hired at one of these companies. Same here. No source control. No bug tracker. No tests. There was no formal system for producing builds--releases to customers were simply copied from the workstation of whichever engineer could build it successfully today. There were so many bugs and crashes, it was hard to even get through basic customer use cases. There was no spec. There was no product roadmap or plan. Sales would sell something, then run downstairs and say "We just sold XYZ, you need to implement XYZ in the software blob somewhere!" The CEO/Founder wouldn't even consider a refactoring or cleanup session, let alone a full or partial rewrite. Only features drive sales, and we've sold so many things we don't have, so all he wanted was feature cram. Every so often, a VIP customer complained about some major use case that simply didn't work, so only in those cases was bug fixing permitted. And in those cases, the VIP customer would get a custom bespoke build made with the bug fixed. I was hired because the last person of my seniority could not cram features in fast enough and gave up in disgust. They only got source control because I came in on a weekend, unpaid, to do it. I lasted a little over a year. Bootstrapped founder (and sole shareholder) eventually sold the company for ~$150M. Sometimes it seems there is no justice in the world :)

jogjayr 4y ago

Only 3 developers maintaining a horrible codebase is a massive business risk. In this market, they could easily leave for better jobs within months of each other. Especially if they're junior and not company lifers. They money printer will print money until one day, it suddenly doesn't.

humbleMouse 4y ago

mgkimsal 4y ago

> But you just told me they built a $20M revenue product with 3 bozos. That sounds unbelievably productive. This doesn't indicate how profitability, and seems to ignore that management/owners might have had something to do with it. A well-connected industry player is better poised to start/found/build/grow a company to that level than someone with 0 experience. And... yes... quitting to something which matches the OPs expectations will likely be better all around than trying to 'fix' something people aren't asking to be fixed (it seems).

msluyter 4y ago

Exactly. I often think of scenarios such as this in evolutionary terms. Imagine a doppelgänger competitor in this space, exactly the same, except they're pretty content with their crappy tech ecosystem and focus on delivering features (albeit, more slowly than they might with a more modern system.) And so... 1. You focus on the advice here, adding tests (which IMHO is actually pretty difficult on a legacy poorly architected/documented system), source control, refactoring, etc.... with any time remaining in the schedule devoted to adding features. 2. Your doppelgänger chugs along and releases several more features than you do, giving them a market edge. What happens next I suppose depends upon what difference those extra features make. If the delta is small, you may be able to pull out ahead, in the long run. But if it's large, then your company may start to lose revenue / customers. Then, the screws will likely tighten even harder, and you'll be forced to sideline refactoring efforts and double down on delivering features. And then those refactoring/cleanup efforts will bit rot and you'll find yourself back roughly where you started, except now you're behind your competitor. There's a quote I can't seem to find atm that summarizes this. It was something along the lines of "With php our product is already up and gaining market share meanwhile our competitor is still futzing with their rails configurations." (If you know the actual quote I'd love to see it.))

noobermin 4y ago

Sheesh, I had to look this far to find this comment, half of the top comments were discussing how much testing OP should do and what manner he should approach the act of refactoring things while ignoring that the "monster" generates a boat load of money for the company. I love hacker news a lot but people seriously need to get out of their developer box and look at the big picture.

fuzzfactor 4y ago

Smells like executive stupidity to me. There is some consensus that you can't fix stupid. Even if you are very talented at repairing airplane engines in flight.

zcombynator 4y ago

THIS. A million times this. The world is about solving real user problems. And obviously this code solves a huge 20M USD problem. And the code is obviously so good, that even 3 "bozos" (to use your language) can manage and maintain in for decades. This is the holy grail. I wouldn't change a thing and instead ask: how can you make this generate 40M USD a year? This is how you will add real value to the company, and management will love you.

Southclaws 4y ago

If the mess generates $20m a year, that's great and I agree with you! If the mess generated $20m last year and it's projected to generate $20m next year, that's a problem. If the second case is true, I believe it's somewhat the responsibility of the OP to sell solving this long-term problem to the _rest of_ business. If they hired him as an expert in that area, they should listen to him. If that fails, leave.