If a prospective employer told you they "outsourced bug fixing because developers hate fixing bugs", What would you think? What might be your concerns?
Tell me more
×
Programmers Stack Exchange is a question and answer site for
professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
|
|
Fixing our own bugs actually makes us a better developer. And it's a pretty enjoyable moment for me. Especially when they are nicely reported. If they don't like to fix bugs, the problem lies elsewhere. I suspect the problem is how bugs are perceived by the management or worse, by bad design decisions and/or no (unit) testing, causing bug fixing painful. Outsourcing bug fixing will probably make thing worse. Developers may be tempted to do reduce quality. Who cares? Some offshore guys are there to clean up their mess. Until the offshore guys replace the onshore guys. |
|||||
|
|
Leave, run away... fast and never look back... I have worked for such a company, they thought they were smart,
for a manager that sounds like a really good plan and the devs were finally freed to tackle the more interesting task of creating the next best thing!! ho... but wait... after two years, they went from a team of 5 devs in their main office who handled it all to a team of 2 that create new stuff and a team of 30 that find and fixes bugs. you know what... the bug fixing team is struggling, they can't keep up. this made the "seniors" completely unnacountable for their own mistakes. Worst still, because it all happened so far away the management did not realize either and the code quality plumetted VERY fast from an already abysmal quality level. When I left they already opened two more offices for bug fixers and they still cannot keep up behind the now only dev that create them. they actually think it's because the new guys are not smart enough... so yes, from now on, if a company say they outsourced their bug fixing to an overseas office trust me.... i run... fast. This is the Paper Bag management methodology. Stand on a railway, wait for a train to come, when you see it, put a paper bag over your head and... POOF.. train gone !!. Magic ! |
||||
|
|
|
Having the company pay someone else to clean up my mess sounds like a good idea except when I'm expected to take their 'clean' code and add new features. And if they get it so screwed up that they can't fix it, you'll be debugging the debugging. Not being adequately compensated because they have to hire additional developers is not desirable. Having to spend a disproportionate amount of time educating the other developers when you could have fixed it yourself is counter-productive. Part of me feels like those who create problems should be the ones to fix them or there is no incentive to avoid creating bugs in the first place. |
|||
|
|
|
Are the developers not interested in learning from their mistakes? Can you fix bugs without specific domain knowledge, and does the outsourcing partner has this knowledge? The fixing part is the easiest most of the times, its the analyse portion that takes the time. From my perspective it is a dumb decision. |
|||
|
|
I would run far, far, far away. A developer is always, always, always responsible to fix his own bugs. Eating one's dog food is a basic tenet of good engineering. Furthermore, bug fixing is as important, perhaps more so than development. I mean, development is code writing, testing and debugging/fixing. What I get from this company is that they are treating bug fixing as a second-class task. That on itself is pretty disturbing and I would highly question their work quality (and ergo, their work environment.) More disturbingly is that they delegate what for them is second-class work to workers offshore. That is more disturbing. Clearly there is social stratification enshrined in their engineering process. A defect is always root-caused to a change, and typically the bug is the responsibility of whoever introduced the change. Who better than the originator to understand the nature of the bug and its resolution? If it is delegated across the world, how do make sure the original author is available to the offshored engineer? Will he even be available, leaving the offshored engineer who has nothing but a backlog of bugs and deadlines, but no support from the Metropole? What type of bug fix could a person possibly hope to perform? Who fixes his bugs? And what prevents the Metropole's developers from learning via bug fixing post-mortem? There are assholes in all fields. This specially true in software. Since it is inevitable, your only option is to work with assholes that know more than you or are doing things right. This company does not seem to fit that description. In short, run away. |
|||||||
|
|
Do they really expect a bunch of off-shore junior developers to be able to fix up a bunch of senior developers code? Its like having a nurse double check all of the neuroligists work and redoing it where he made mistikes. BAD IDEA! |
|||
|
|
|
I would be concerned how well their employees actually know the code they are developing. Fixing broke code is part of the process of writting code it allows you to have a better understanding of what you did wrong 6 months ago, so you don't make the same mistake, if some other developer fixes your mistakes how do you prevent that bug from happening again and again? |
||||
|
|
|
This sounds vaguely like my previous employer, except for the "prospective employer" bit. They've been losing developers to attrition and have lost too many to support existing products while adding new features required by changes in laws and regulations (60% of the office's revenues come from a VB6 based product, and MS has stated that the VB6 runtimes will not be distributed in any future operating system, so it will be like when Vista came out - a mad scramble to fix things). The powers-that-be want to bring the company public soon, so they're starving everyone for resources to make the balance sheet look better than it is - so hiring offshore is the only way to even come close to staying in the market. Based on my experiences, what the quote says is that your prospective employer is cheap. |
|||||||||
|
|
It depends what they mean by "fixing bugs". If this is fixing bugs during the dev/test cycle then it is very odd, this is the job for the original developers. If, on the other hand, they mean they have outsourced maintenance of a released product then this is not unusual and not something I'd worry about. |
|||||||
|
|
My experience has been that bringing in an external team after the fact will burn about as much time as just fixing your own bugs -- they need to be brought up to speed and brought into the development process. And then kept up to speed continuously. Coordination is harder than writing code. |
|||
|
|
|
If I'm going to work on a codebase, I'd like some assurance that everybody with commit privileges is reasonably competent. This includes quite a few people in India, say, but not the ones that are usually offshored to. Moreover, most of my bugs are in more complicated sections of code, and those are the ones the offshore programmer is least likely to understand before applying a bug fix. |
|||
|
|
|
This policy actually exists subconsciously in some companies. I work for an outsourcer; myself and my colleagues are more proficient programmers than the guys onsite, they ask us to teach them how to use tools etc., but the other side of that is that we will spot problems in their code more quickly than they do. Generally the client's programmers are physically located in the same building as at least some of the users, so they are more likely to get context that doesn't reach across hemispheres. We find it works well, the missing part for me is that they are not reviewing our code so when the contract finishes they may have some surprises or questions, not due to any shoddy practices on our part necessarily but just the usual problems you have when taking over someone else's project. In any case I'm glad that in our case it's not an official policy, as such I think it would erode the onsite programmers to being little more than BAs. |
|||
|
|
