If a prospective employer told you they "outsourced bug fixing because developers hate fixing bugs", What would you think? What might be your concerns?
3
-
2Developers hate fixing bugs? I think it's more they hate finding a reliable way to reproduce the bug, which is what testers are for. If you're outsourcing bug fixing, you may as well outsource the entire development team. No one understands the code as well as the person who wrote it themselves.– RobApr 12, 2011 at 6:21
-
2Sounds like a terrible idea.– Andres F.Oct 12, 2012 at 12:58
-
2@AndresF. +1. This will create an environment where devs just throw crap at the wall and hope it sticks. Ain't their problem if it doesn't, right?– MrFoxOct 12, 2012 at 14:23
Add a comment
|
12 Answers
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.
-
-
1@Aditya : nothing scary here, this is EXACTLY what is happening at my last employer. The offshore guys had enough of bug fixing all the time and their manager (amen to him) started to provide training. At one point they got good enough to start simple refactors, clean ups etc. In the mean time in the main office nothing changed. I can very easily see that within the next year the offshore guys will do most of the work and the main office guys ... well... just too bad they did not see the train coming ;-P Apr 12, 2011 at 9:17
Leave, run away... fast and never look back...
I have worked for such a company, they thought they were smart,
hey we've got all them bugs but our seniors complain they spend too much time fixing bugs.
let's open an offshore office and let the others deals with this.
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 !
answered Apr 11, 2011 at 14:40
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.
If a prospective employer told you they "outsourced bug fixing because developers hate fixing bugs", What would you think? What might be your concerns?
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.
answered Apr 11, 2011 at 14:10
-
2"Furthermore, bug fixing is as important, perhaps more so than development." I know what you mean there, but I'd go as far as to say: I can't fathom any such dichotomy. Bug fixing is an intrinsic, fundamental aspect of development.– Dan RayApr 11, 2011 at 14:46
-
1@Dan - yep, your statement is far more correct. No such dichotomy exists. Apr 11, 2011 at 20:06
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!
answered Apr 11, 2011 at 15:32
I would be concerned how well their employees actually know the code they are developing.
I also would wonder the reason there are enough bugs to justify the added costs that this brings. I would also worry about long term future of the company, there are many articles on the web that claim these firms, use the same code for multiple projects even in the same industry.
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.
answered Apr 11, 2011 at 14:37
-
+1 for having the worst possible job ever. It sounds like they didn't use enough of that revenue back into the project.– RamhoundApr 11, 2011 at 14:44
-
-
-
@Ramhound, David, Greg, It was a better place when I started, I left the place at the end of December (shortly after my 5th anniversary). No one had been hired since I was hired, and in the past 2 years, 6 developers have quit. The latest one to depart had been there 11 years. Apr 13, 2011 at 0:22
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.
-
-
@Greg & Steve - I don't believe it matters to be honest. If they are fixing bugs in say a release version how can those fixes ever get merged into the test build if the developers don't write the bug fixes themselfs.– RamhoundApr 11, 2011 at 18:40
-
If the bug fixes are checked in to source control they can easily be meged by another team in to another branch. It's not a big deal at all.– SteveApr 17, 2011 at 19:33
-
You make a good point though I'd really approve this scenario only in a case where the application is a legacy system that is no longer being actively developed but needs to be kept functional for some reason. Say a new generation that is a complete rewrite form the one in question. Dec 14, 2017 at 17:26
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.
answered Apr 11, 2011 at 18:27
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.
