0

I work as a developer for a startup. I maintain a product (let’s call it P) which is an integration tool for 3 years now. The product has a considerable functional and technical dept:

Business side:

The product P has started as a prototype, not even an MVP. After several attempts to convince some tech companies to integrate it in their SAAS, we end up pivoting and changing its domain to become an annex tool for a known regional SAAS which is somehow a competitor of us.

This competitor partner is only interested in the clients we already have in our platform. In exchange, this partner which has a strong sales team will promote and sell my company’s other products.

Technical side:

We made a lot of hacks and shortcuts to support both the original domain and the partner’s requirements.

The original features of the product are not functionally nor technically matures enough and not used by clients. But my company for some strategic reasons doesn’t want to improve them nor to abandon them.

The P product doesn’t belong anymore to my company core business, it prefers to focus efforts on other products to rich its goals:

  • I often do both dev and client support, and sometimes they ask me to get contact with the partner business side
  • I often help other teams while mainly continuing to maintain the P partnership
  • My company refuse to rewrite/refactor the P product (but we continue to refactor other products that belong to the core business)

I’m the only developer in the company who knows well the P product, and the only one who maintains it (among 1x devs) these last 2 years which is a long period.

I ask my company to delegate it to someone else, but it looks hard for it to take this decision, and it continues to take the risk (to keep one dev in this project)

The original idea behind the P product is technically very interesting but it seems that it doesn’t find its product-market fit. So the product can't rich a stable shape, and I still stuck within.

Is it common for a dev to risk his technical career if he takes/maintains a secondary project with a low budget/business-interest?

How can I gracefully quit the job in such a situation?

Improve this question
8
  • 10
    Is there a reason why you think quitting is different in this situation to any other time someone quits? – BittermanAndy Aug 16 '20 at 22:22
  • 1
    Location might help a little in this question. Quitting may impact a career differently in different regions. – Joel Etherton Aug 16 '20 at 22:48
  • 1
    @BittermanAndy I need to ensure a knowledge transfer that is not easy and may take time. I don't want to keep in contact with the company and doing some hotfixes as a contractor. it's a common practice here to keep contact after quitting the job... – reda la Aug 16 '20 at 23:07
  • 1
    @redala: What is stated in your comment has literally nothing to do with the question asked. I would recommend you reconcile those 2 disparate ideas. – Joel Etherton Aug 17 '20 at 3:03
  • 1
    @Erik, yes I main competitor, thks – reda la Aug 17 '20 at 8:02
2

This sounds like a typical "trashware" application.

An application is cobbled together as something quick-and-dirty to solve an immediate problem. The intention is always that its shelf life will be limited and that it will be replaced by something considered and more robust at a later date. However, as long as the software continues to satisfactorily perform the task for which it was intended, there is no pressing need to replace it. There is always something that is considered a better use of resources or budget so the shelf life gets extended.

Then at some point it starts to grow arms and legs. Somebody has a bright idea of tacking on another "helpful" feature. That's thrown together quickly too. (Well, it would be a waste of time to spend too long designing something we're going to throw away soon anyway, right?) As soon as the first enhancement is released, it's suddenly open season on your app. Feature after feature is added, always with a Band-Aid approach. And, because it's "trashware", no real thought has gone into maintainability and extensibility to date. This means there is no choice but to pile hack on top of hack and let the technical debt continue to pile up. Nobody cares - it's doing what we need. Well, that's not true, any developer who has worked on it is, at best, uneasy and wants to rip it up and start again. Ironically that is even less likely to happen now because the throwaway app you created 3 years ago does too much and is too important. "We don't have the time, resources or budget to replace all of that functionality... plus it's working just fine".

It's bonkers but this happens the world over. In my experience it seems largely confined to organisations whose primary business area is not in the technology space but who have an internal technology/development department. (Or where there is somebody senior enough and stubborn enough to ignore the good advice of their tech folk and demand something be whipped up in a week).

In answer to your question: As a developer I think we all want to work on the newest and most exciting technology. Unfortunately there will be always be "grunt" work - something using dated tech or tedious and repetitive tasks. This work has to be done by somebody and sometimes that somebody is you. When it is all you can do is suck it up because they pay your salary.

In this instance however, I think it's reasonable to be frustrated since this appears to be your main source of work, it is very different from the type of thing you would like to do and there also appears to a steady supply of other "quality" work available. You are also right to have concerns about your career prospects. It's one thing to tackle a nasty task because (a) it has to be done and (b) you're being paid to do it, if there is a light at the end of the tunnel. That doesn't seem to be the case here.

That said, at this stage, I don't think you need to think of leaving to remedy this problem. Speak with your manager. Explain your concerns about the product and it's design. Explain how you think it could be improved and what you would like to do in order to do that. Explain also your concerns about your career and the type of work you would like to be doing. Then suggest working together to find a solution acceptable to everybody.

If that approach is unsuccessful, then you should be prepared to find a new role. It is your career. It is your responsibility to nurture it. You are right not to be prepared to let it wither in an unfulfilling role.

If you do decide to leave, very politely explain that you see your career going a certain direction and you don't feel your current role is setting you out on that trajectory. Explain that you liked the company and would have like to continue working there but that clearly no suitable resolution was found to the problem

Improve this answer
2
  • I find "trashware" a bit hard as a definition, but unfortunately, you've said some facts that already happened in the project... your answer helps a lot, thanks – reda la Aug 22 '20 at 10:08
  • 1
    "Trashware" refers to the intention to consign it to the trash after a short shelf life. Its no reflection on the quality of the code. – amcdermott Aug 22 '20 at 15:02
7
  1. As presented you appear to be overly paranoid.
    You can ask to be taken off it, either fully, or to only work on it part time instead of full time; how well that will go will depend on company culture and your relationship with your boss.
    As long as they're paying the bills to do so, companies often do keep secondary projects running long term. This is because ERP systems tend to be very important for the companies using them, and very difficult and expensive to change, and as a result the current customer base tends to be very sticky. Even if the module only has a handful of users, there's a good chance they'll be willing to pay to keep it running long term in its current state.
  1. "I am resigning my position with CompanyName. My last day will be StandardNoticePeriod days from today."
Improve this answer
2
  • Only needs part 2 tbh... – BittermanAndy Aug 17 '20 at 10:05
  • @BittermanAndy much of the post (and the first of two explicit questions) is about why the OP seems to think this is a dangerous situation; my first point directly addresses that. – Dan Is Fiddling By Firelight Aug 17 '20 at 10:08
3

It boils down to these questions:

  • Will product P last over long enough timespan to make up significant percentage of my career ?
  • Is there large chance that product will be will be acquired by other company if current one goes down ?
  • Is product unique/irreplacable ?
  • Are any there any other products that satisfy above criteria while being dependent on this one ?

If at least two are positive then, do not let this chance slip by, small niches like this will keep you in armchair while others will be laid off. Here is my cold and pragmatic thought process.

Improve this answer
1
  • 1
    Of course, it’s a startup, so if he takes this strategy it’s quite possible that he’ll just wind up riding it all the way to the ground. – nick012000 Aug 17 '20 at 8:39
3

A company I worked for had a similar situation and it was resolved by selling the product to the client, and the developer moving to work for the client directly.

Our company was rid of an unprofitable, non-core project. The client got to bring it in-house and avoid needing to negotiate for every small change. The developer was recognised as the expert (i.e. got a pay rise) and got to work on a project that was important to his employer.

Working for a start-up is always a bit of a risk. If you have stock and if the company succeeds, you could get a nice pay out. Or you may get rapid promotion as the company grows, but it's equally likely that the company will fold without notice, leaving you short of a month or two of salary. You need to consider your future, and three years is plenty of time to demonstrate to a potential employer that you don't job-hop on a whim.

Improve this answer

Not the answer you're looking for? Browse other questions tagged .