Application from external vendor seen as a black sheep in team
Posted by Refmak@reddit | ExperiencedDevs | View on Reddit | 45 comments
My team has become responsible for an application from an external vendor, that we're now supposed to integrate into our own in-house application.
The caveat is that the application from the external vendor is both very antiquated, overly complex and somewhat lacking in documentation. On top of that, the external vendor is hard to work with and constantly trying to up-sell consultancy hours for their lack of documentation (lol).
As a result, the application from the external vendor has become the "black sheep" within the team, which no engineer wants to have anything to do with if they can avoid it. Instead, all focus is on the in-house application.
This makes the aforementioned integration difficult to design, since a big part of it is to properly understand the external applications APIs, which is a task no one wants to undertake - likely due to some level of fear of personal ownership (i.e. becoming the external vendor applications "support person" within the team).
It's become to the extend that engineers will pass off assumptions about what the applications APIs allow us to do as hard facts, both to business and to ourselves in-team, without doing any testing whether the assumptions are correct at all.
Because of this we keep running head-first into a wall when designing the integration. Basic restful API endpoints are assumed to function one way, and it's a coin toss if it really does until someone - usually me - gives in and tests it by spending 5 minutes just calling it using the open api specs.
How would you go about turning this team dynamic regarding the external application around, when it's so crucial for the success of this integration?
suncrisptoast@reddit
I come from the "it's your job" era. Debug it. Theres also the good ol' "still want your paycheck?" point too.
I can't believe people are that entitled over a REST API.. Holy hell.
Get real devs on your team
Refmak@reddit (OP)
I'm under the same train of thought, but it sucks being the only one "doing smth about it".
For what it's worth, it's not just a REST API. It's 15 auto generated REST APIs in a trench coat on top of some dated software from the mid 90's. It's """SaaS""" in the sense that the software runs on some cloud hosted windows VMs, but now the contract is subscription based.
So while yes the software is atrocious, it's much more atrocious if one person is the designated person to work with that software 24/7. It's not unlikely that this person would just quit.
suncrisptoast@reddit
Well when you need someone to handle it, you know where to come lookin ;)
Morely7385@reddit
You should, Fix it by treating the vendor app as untrusted and making the work a bounded, team process with a thin facade and proof-based rules, not a single owner. Pitch a two-week discovery spike: list the top 10–15 calls you must use, write Postman/Insomnia checks and curl scripts, and log actual behavior, edge cases, and error codes. Add a rule: no claim about the API without a link to a reproducible test or doc. Build a tiny anti-corruption layer in front: normalize payloads, add retries/circuit breaker, idempotency keys, and contract tests (Pact, Schemathesis, or Dredd). Set SLOs and an error budget so you can say “we degrade gracefully” instead of firefighting. Run a rotation: one person per sprint on “vendor duty,” capped hours, with pairing on day 1 and a required runbook update on day 5. If morale tanks, ask for a contractor or a bonus tied to documented deliverables. We used Kong and AWS API Gateway to front flaky vendor endpoints, and DreamFactory to quickly expose stable REST over data we mirrored when the vendor was unreliable. Bottom line: bound it, prove it, and front it with a facade so no one becomes the permanent owner.
Zephilinox@reddit
is it fun to work on? it doesn't sound like it
is there a benefit for working on it? cv bullet point? promotion? bonus? doesn't sound like it
is there a downside to working on it? being the forever-support person for this application seems like a dead end
is there a downside to not working on it? replacing the whole team? demotions? I doubt it
I would either change some of these factors and give them a reason to care, or if you can't, then just force it to happen
there's always stuff that people don't want to do, so spread the load and dedicate a whole sprint to understanding it as a team. don't let anyone off, and don't allow any in-progress work to continue since it'll get dragged out the whole time
and if you can't do either then it's not your problem and you should let the status quo continue. if it somehow is your problem. then it's now your managers problem.
Sheldor5@reddit
enforcing something is never a good idea ... the devs will simply quit and look for another job
forgottenHedgehog@reddit
If they are not delivering the value the company is asking for, what are they good for?
lawrencek1992@reddit
I was in the position of maintaining the third party awful bullshit before. I threatened to quit if it was given to me longterm instead of passed around. Like I’ll do it this time but not every time.
Because I bring a ton of value outside of working with the shitty service, they weren’t willing to lose me over it. I suspect the same is true with op.
Sheldor5@reddit
they are people and not slaves, if the job sucks they will find another one ...
forgottenHedgehog@reddit
Sure, but the company has no reason to pay people not to do the job they were tasked to do.
HK-65@reddit
Yeah, but it comes back to supply and demand. If there were people who would do better work at that price point, the company would hire them.
This way, the company will either have to pay up for consultancy for the vendor product, or pay up for people willing to deal with it.
If you have a movie place and fire your ticket inspector for not being willing to sell popcorn, you probs won't find another ticket inspector who is also a popcorn seller, else you would have hired them in the first place.
Refmak@reddit (OP)
Is it fun? No. Is there a benefit? No. Is there a downside? At least a perceived one, yes. Is there a downside not to? We won’t make the artificial deadline set by business.
Thank you for outlining it like this. I’ll highlight this to leadership, as I don’t have any power here - I am also an engineer on this and not a lead.
lawrencek1992@reddit
Yeah we have had this problem too. No one wants to dive deep for fear of the whole thing becoming their longterm responsibility. In our case we also had business constraints that basically mandated building brittle systems around the third party thing.
On a managerial level the options are: - Hire a contractor specifically to do this - Tie a financial incentive to the work - Require everyone work on it in a rotation
On an individual level, I’ve gotten stuck with this work. I made it crystal clear to my manager that this work made me unhappy and was a detriment to my career (I want experience building reliable systems). I said I’d complete the work with ample documentation so that someone else could work on it next time.
If I hadn’t been taken off that work, I’d have quit. I started DSA practice and putting out applications. This is the risk of forcing it on people. I’m the most senior backend engineer at work, and they’d have lost me if they tried to force me to be the person for this service longterm. Really contracting out the work seems like the better move to me.
throwaway_0x90@reddit
What's missing is accountability.
Someone(s) should be officially assigned to deliver a working feature and not doing so will impact their performance rating.
But before getting to that point, if you feel strongly about this not being worth the time then you should outline all of this in a document and share it with the team. Ensure the majority think it's junk, collect more detailed examples of how it wastes engineering hours. Present to management how many estimated engineering hours are wasted on it. Show them proof. There's a good chance they'll look at your report and just tell all of you to drop the app.
dfltr@reddit
Right? Assign a DRI, make sure they have the power to delegate/assign resources, then plan the work and work the plan.
FelixStrauch@reddit
Does every developer get to veto the work assigned to them? Is work actually assigned to them or do they pick and choose the work they like? Is it a business or a co-op? Are devs paid or are they volunteers?
It sounds like the project is missing a manager.
Manager says: Dev A and Dev B work on the external app's API documentation. Expectations are X. We'll look at training up more people when the initial work is done. Now get to work.
That's how it's done in the real world.
HK-65@reddit
I mean every developer gets to veto the work assigned to them, they can always quit. And if you push someone into a position where you hire them for one thing and then go "do this other thing that you don't like and will deadend your career, now get to work", you can be sure they will stay up every night to do applications elsewhere.
And in the end, you will need to get more expensive devs, as retention is always cheaper than hiring, and if you're lucky, you didn't actually pull the "We'll look at training up more people when the initial work is done, but actually we won't" play, because then you'll lose your "expert" at the most inopportune time.
One of the biggest and foremost tasks a manager has is motivating people. Approaching a problem like this is not how even a senior dev does it, much less an EM. At least in western work cultures they don't, as long as they are not either way overpaying for people or braindead.
FelixStrauch@reddit
In 25 years I've never worked a job where everything was greenfield C# or all new React or exactly what I wanted to be doing. That's not how real world projects work.
There's always legacy code that has to be looked at, external APIs that are far from perfect and unusual non-standard problems that need to solved in non Resume producing ways. If a dev can't hack that without crying and looking for another job, then they're not a whole lot of use outside of early stage startups.
HK-65@reddit
It's not about looking at legacy code, or a single external API, it's about maintaining and integrating a whole application that:
The scenarios you are describing are normal, this scenario is not. Dealing with legacy code, integration work with external APIs is absolutely resume-producing by the way.
The big difference is that whoever you put on this kind of project is absolutely set up for failure, and apparently everyone at OP's company knows that too.
washtubs@reddit
I'm guessing asking for access to source code is out of the question? If everyone agrees the docs are ass, that can be a negotiating lever: update your docs or send us your source code.
I don't get it. If it only takes you 5 minutes, why don't they do the same?
Possible_Cow169@reddit
Tell someone what you told us or build a plugin layer to prevent cross contamination. Bonus points if you can use the outside app more like an api
Refmak@reddit (OP)
The outside app supplies an api, but no one wants to experiment with it for the reasons mentioned in the post. The external vendors aim is to sell consultancy hours to build these integrations, the budget of which is out of my control (there is none).
Possible_Cow169@reddit
NGL. Sounds like your company is getting scammed. Like the Sinclair/McDonald’s ice cream machines
Refmak@reddit (OP)
We probably are (believe me, I’ve seen the bill), but they’re dominating in the market - likely because other companies got tied up like this too and can’t leave haha.
Material-Smile7398@reddit
Scammed is a good way to put it, this kind of scenario is rife in our industry. I think the only thing you can do is push up reports to senior management about endpoints not functioning as expected and try to tie that back to the bottom line cost for consultancy.
They wont care about messy integrations but they will care about having a bait and switch pulled on them.
PaleontologistNo2577@reddit
Just use augmentcode to index that entire project and create documentation for you… just a thought
Refmak@reddit (OP)
What do i index, the swagger documentation? The web pages? What?
PaleontologistNo2577@reddit
Ah makes sense, yeah I had the impression you had the source code. In that case I would just implement your own lean version and reach out to any potential vendor APIs within that legacy software to get direct access if absolutely needed. It will take shorter time in rebuilding than trying to figure it out blindly 🤷🏻♂️
kaevne@reddit
You have another option. You need to swallow the idea that you cannot possibly simply understand and a complex logical system that you don't have documentation for.
Hire a consultancy (or your own devs) to reverse-engineer the external application and slowly rebuild it in your in-house application with an abstraction layer in-between.
Codify your interaction in the abstraction layer and do a shadowed switchover of the calls between your new in-house code to your vendor's code so that you can mitigate risk.
Write a processor for the shadowing so that you can create a few exclusion rules (e.g. assuming correctness when datetimes are just off by microseconds due to normal processing), otherwise fallback to vendor when there's a parity issue.
Once a call hits 100% correctness world-wide, deprecate this part of the vendor code. Eventually you'll hit 100% for all interactions and be able to squeeze them out.
Refmak@reddit (OP)
Sure, but how do I make my team swallow that idea too? Also we aren’t aiming to replace this whole application lol. This system is a requirement from our business partners.
kaevne@reddit
By presenting the problem set and the plan to stakeholders. Your team is downstream from that decision. You don’t need their buy-in, you need engineering leadership to buy-in.
Refmak@reddit (OP)
The project is already started, leadership also placed their buy-ins. We have budgets and timelines. But I can guarantee, that is no one swallows their pride and tries to learn how the external application (and it’s apis) work, then we will not succeed no matter the buy-in and extended deadlines.
kaevne@reddit
You’re saying, you created a reverse-engineering project with an adapter layer and parity processor that I outlined above, and basically no one will do the work?
Refmak@reddit (OP)
No, because you’re providing a technical solution to a non-technical problem (and making no coherent sense while at it).
kaevne@reddit
I am trying to get you to view this as a technical problem, not a people problem. As long as you continue to view your problem as a people problem, you will never solve this.
You might as well just clone work items that say "Do Better" and assign it out to everyone.
David_AnkiDroid@reddit
Are there consultants/contractors working with this software who are external to the vendor?
Or is there someone you can farm out the exploratory work (API testing/docs) to?
Sheldor5@reddit
replace the external application with an alternative or implement it on your own
Refmak@reddit (OP)
I thought I asked experienced devs, not mid-level “just refactor the whole code bro”-devs.
We can’t simply replace the external application since it’s a requirement for working with our top tier business partners.
Sheldor5@reddit
and my experience tells me that your team hates the application and soon will look for another job if things don't improve or are getting worse
you can't force people into doing something they hate for too long ... everybody has a limit
Refmak@reddit (OP)
Yeah probably that will happen, and that’s entirely outside of my control as an engineer too.
I hate the application just as much as everyone else, but everyone would hate it a lot less if everyone took up the task to experiment with it and not just one person.
wickanCrow@reddit
This is a very casual way of suggesting what may be years of work. It’s not always that straightforward.
People almost always underestimate what is actually going on underneath and assume it can’t be that much. Then start implementing details and run into so many road blocks and realizations.
forgottenHedgehog@reddit
Especially if the team is incapable of understanding what's likely a small surface area of the overall API of the system.
Puggravy@reddit
In these situations it actually may be the best choice to contract the work out to someone who is a domain expert on the specific product. My company did so with Salesforce, and although salesforce is obviously not the same level of difficult as what you are describing, my experience during that project was extremely positive and saved months of time for what was essentially a small premium on a senior dev salary for a few months.
Historical_Cook_1664@reddit
put all work on the app on hold until sufficient documentation is provided... atm you're throwing good money after bad
jmfsn@reddit
Rotate daily/weekly who's the support person. At the moment it sounds like it's you...