Product / Code Release


I work on the Product team in our company, and we have our Dev team outsourced to an agency in another country. Our company is growing at a significant rate (1000 new users oer day, increased revenue and employees) yet, the Dev team is becoming more and more of a problem:

  • constantly missing new product deadlines
  • take weeks to fix or adjust small things (which sometimes are literally a case of changing one simple CSS value)
  • they will only publish code once every 2-3 weeks
  • every time they publish code, we (the Product team) spend the next few days reporting bugs, highlighting the lack of attention to detail, and all of the problems that come with each release of code
  • when we ask a question, it takes at least 24hrs for a reply

We’ve tried changing the processes on numerous different occasions, yet they continue to let us down each time, and their quality is sub standard.

We are now working with the company to bring some of their dev team in house into our company, so we can work hands on with them, along with instant communication, and then hire around them.

I have a question which I hope someone can help with.


How often should a company push code? I know if depends on the setup, etc… but I read about companies pushing code every day, and even hour. How does a company who is pushing code once every 3 weeks, change so they can push at least once a day?

Thanks in advance to anyone who can help with this.

IMHO this pretty much sums up your problem. If you are not getting the results you want its time to either find a new Dev team or hire talent in-house. I assume you went out of country for cost, but like in many things, you get what you pay for.

If you are interested in a US Dev team for outsourcing let me know. We will provide the results and response you are looking for. None of this 24 hours for a reply stuff. If your spending a substantial amount of time reporting bugs they probably are not as experienced as they should be.

I would be happy to review the work that has been provided to you at no charge as a professional courtesy.

I’ve worked in places where we push code right after tickets are confirmed tested/complete and I’ve worked in others where there has been set deployment schedule except for critical issues which are applied as hot fixes. It will depend on the project management methodology, bandwidth, continuous integration sophistication, and overall risk of changes. Every set-up is going to be different.

I suggest you have a conversation with your vendor about this. There is no hard and fast solution. Every company is going to have its own infrastructure, architecture, programming practices, and project management methodology that might not make this a reasonable request.

1 Like

Are they missing deadlines on “larger” projects because they are busy fixing operational, “HIGH PRIORITY” unplanned bugs?

Are you properly prioritizing such changes as highest priority and adjusting longer term efforts time lines appropriately when these types of operational disrupt longer term work?

Sounds like they are an agile shop with 2 week sprints. That is a well known project management methodology. However, in the real world sometimes things need to be fixed right a away. In that case the bug/ticket becomes a hot fix and outside of the normal flow. However, if you have enough hot fixes then that is going to significantly impact the ability to get the work in the sprint done unless you add more resources to the project.

That sounds like a fundamental problem with the resources themselves. There might be some incompetent and/or unexperienced people working on the project. Turn-over also causes a major problem when it comes to maintaining large software projects. A few people leave and no one knows what is going on.

That sounds about typical of an agency.

All this being said everything comes down to cost. You get what you pay for. If you hired a bunch of Indians for a few dollars an hour than you shouldn’t be surprised at the quality of product and service you are receiving. I’m not saying you did that but I mean that is what you can expect when dealing with those people.

A lot of companies will out source the work and after it is done bring everything in house for the reasons you mention. Again though having project managers to answer questions, devs to respond, etc all costs money. I don’t think what you are receiving is necessarily bad service. It all depends on what the contract with this vendor.

1 Like

You need to prioritize the bugs, tell them to work them in the order you gave them (3 at a time) and setup daily conference calls to go over the status of the 3 bugs they are currently working. This way there is daily oversight to the process and you can track what they have accomplished and they have a direct line of communication with you to ask any questions/concerns about the issues they are working on.

Oh boy, you have asked a lot of good questions and rightfully so!

First let’s start with the miss-steps. A company that is struggling to provide quality isn’t that uncommon. In fact, I’d argue, it is almost the norm (sadly). However, you hint on a few issues that need oversight, and need it now.

I worked with a third party vendor over the course of 8 months to get their product launched for us, it took a lot of my time and effort, along with our product team as well. We had the same issues you are experiencing and this is what we did, which helped immensely. We held daily standups.

We setup a conference number, and told them they had to call in each day at 10:00 AM to talk about the issues we’ve reported, what they are currently working on, blockers they have with resolving them (do they need clearer requirements from us, better reproduction steps?), and estimated timelines on completion. HOWEVER! This hurt us bad at first. We had 20+ bugs with them and the daily standups turned into reporting on all 20 bugs, it was a NIGHTMARE.

So take a lesson from me, do not just start with standups, instead prioritize the bugs. What is the most critical to fix to the least? Yes, they may all be equally important for a successful product launch, but they can be prioritized, do this first! Then send that list to the vendor. Tell them to work 3 at a time (start there, change the number accordingly to their progress). Have them estimate the top 3, how long will this take and how many of their team will be working on it? (ex: It will take 2 weeks and 2 developer) Have them justify it. What is unique about this bug that requires it to take 2 weeks and 2 developers, will throwing a 3rd developer into the mix help or hinder the progress? Be sure to make these sound like concerned questions and not like you are trying to tell them how to do their job!

Once you have prioritized the bugs and sent them over, then setup a meeting to go over meeting daily via a phone conference call, why it is important to you, what you plan to get out of the call (a status of the bugs they are currently working), expectations of how long the call should last (15 minutes? 30 minutes? an hour?), who you want there (developer, tester, managers?), who will be there on your end, etc. Then setup the daily meetings.

It isn’t going to solve itself overnight, in fact, you will still have struggles over the next month.

Now lets focus on your questions.

This is a very difficult one to answer, as it is entirely dependent on the company, their practices, and how much red tape they have built into their process.

Most companies should aim to be able to produce some sort of progress in a week or two. If they operate in an Agile workflow, it should at a minimum be the length of their iteration (this is a question you can ask them about). If they use Waterfall, well, that is more complicated, as usually you complete all work, then deploy. Which is painful and why a lot of companies are moving (or have moved) to Agile.

In short, they have to change internally and be willing to change. Keep in mind, as you discuss this, you are not suggesting they sacrifice quality, but rather deploy a smaller set of changes at a time (hence why I focused on 3 bugs at a time). It gives you and them a win in a shorter time frame and you get to see the benefit of it sooner, rather than later.

As much as I think that is a nice offer, I think that may be taking things a bit too far too soon. The last thing you want to do is tell a vendor that you are having X review their work. It adds stress and can lead to frustration on the vendors side of things. Although they are not producing the quality you expect, adding strife will not remedy the situation, and instead you need to take a process that forces oversight on the issues on a regular basis, so they, themselves, can see the progress you expect to be made and have a dedicated time every day they can ask for clarification, more information, or any concerns/questions with resolving the issues.

@oo7ml, last but not least, if they ever mention they cannot meet on X, be sure to remind them to send their status via email. Just because you can’t meet on a given day doesn’t get you out of the conversation. You need to set the expectations you want an update even if they can’t call in and it is expected to be received by the time they would call in.

1 Like

No one says go run to them and tell them the code is being reviewed by a third party. My main concern in wanting to see the code is to make sure they are not getting some mysql_* hack and that the code is to current standards.

I pretty much echo what others have said.

In our case when we do work for clients we like to prioritise tasks where necessary so we know what we’ve got to do first, additionally these tasks are usually allocated a deadline like today, this week, by the end of December and so on. This helps both us and the client so we both know where we are.

Regarding pushing code we do it whenever it’s necessary. If it’s bug fixing this could be several times a day/week, major changes we’ll push when ready or at the time the client wants - even if that’s at 2am on a Sunday morning. Sometimes if it’s something really urgent we’ll push a change while we’re actually talking to the client on the phone/skype!

It does sound in your case that you probably need local developers whom you can meet face to face?

Thats not necessarily fair considering the circumstances of how the project was built and maintained over time. If the project was built 10 years ago and is still running on php 5.3 then its a little unfair to hold it to the same standards as building a brand new project on the latest and greatest in the ecosystem. I’m not saying that this couldn’t be a goal but it also takes labor and cost which the client is going to need to pay for and possibly de-prioritize other initiatives. If you have trusted the agency for this long and project has been relatively successful you should at least have the decency to discuss all these concerns with people of importance at the agency. The poster said it their self that their company has grown significantly and needs have evolved. Perhaps in the end the agency which you hired originally can no longer satisfy those needs but you should definitely talk it over with them before going behind people backs having audits of code by people who are completely unfamiliar with all the challenges that have been faced in developing the project.

The OP hired a contractor. It is hardly “going behind peoples back” for him to have a neutral source review the work if he/they do not have the technical know-how. Not really any different then getting a second medical opinion.

If the code is old and the OP doesn’t understand about that now is the time for them to know. To continue building with obsolete code that will not run in current versions of Php will be much more costly down the road if not dealt with sooner than later.

Sure they should talk to them, but I would be surprised if they have not already numerous times. This is not a situation that came up overnight. The OP coming here sounds to me like he/they are at their wits end.

Whether they tell them upfront or afterwards hardly matters, because if an audit does turn something up, you have to relay that information over. And they are going to ask why/how it was found.

We do audits with our vendors all the time. We also tell them that upfront so they understand when we bring issues up, that we consider it a high priority. Doing it behind their back to learn there are issues is meaningless unless you 1) inform the vendor, or 2) plan on dropping the vendor and going elsewhere … but that is usually costly as the new person is likely to start from scratch (if the issues were that large).

I still feel it would be too soon to go that route. They obviously have a long standing relationship with the vendor, they more than likely have cut them slack over the years and it has progressed to a level they need to reel it back in. More oversight on their work is a good way to do that.

All, thank you for your detailed replies and help. It is much appreciated and very informal.

I will report back in a few weeks with a plan that I actioned yesterday. Thanks again for your help.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.