In a previous life we outsourced to Indian companies because it saved a lot of money (on paper)[1]. The good ones seemed competent, but they weren't cheap so we didn't use them. The cheap ones we did use (disclaimer: limited experience and observations) were staffed by young, inexperienced engineers. The code I worked with, I would put at second year CompSci level.
Incidentally, coding standards are quite limited in their ability to raise the competence level of software.
One example was the coding standard requirement that the number of global variables was to be minimized. In this particular application, there was only one global variable. Minimized pretty well... until I saw it was a typedefed struct, the struct was huge and had several nested structs in it. Abort Retry [FAIL].
Another example in the same application, there were several (not one, not two, but several) funny looking loops that called a function, passing a bunch of parameters. After puzzling through the code, I realized that the code had failed the McCabe complexity measurement, so they had simply cut out the guts of the loop and made it a called function. That wasn't the worst of it... the icing was that they passed the loop counter as a pointer and side-effect modified it in the called function. Owwwwwwwwww!
[1] My gross observation was that it took 3x longer to get a job done, but we paid the outsource company 1/2 as much as the internal engineers. The way accountants run numbers, the longer it took an outsource company to get the job done, the more they thought the company saved.
For the love of Knuth, stop using Quality as one of your project axes!
Quality is non-negotiable - as soon as quality slips, everything else slips, too. Better options are Cost, Scope and Schedule (or Features, Price, Speed): http://en.wikipedia.org/wiki/Project_triangle
Not necessarily. Having code that is easier to modify or has fewer errors is a competitive advantage. Given that all your competitors are trying to improve their codebases, you should be trying to improve yours as well.
I don't think you understood my point. I agree with you up to a point. No programmer I have ever met has felt that any significant codebase they are working on is perfect. At some point you have to say that it's good enough and move onto new features or new projects.
I'd love to see that, but all too often it's the opposite - stuck on bugfixing antique, crappy code because somebody did a dodgy hack and figured it was "good enough". Taking the time to do it properly means that you ultimately go faster, not slower.
going faster doesn't matter if you're out of business. There is a point at which you have to say it's good enough. You can always make it better, unless you're arguing that all code you write is perfect. If not, then you agree with me, but want to repeat a talking point for some reason.
I agree that often people don't surpass the bar of "good enough". This is usually a result of bad programmers or bad employees, not a result of a company wanting to go too fast.
Going back to my original point, let me give you a real world example. I once worked at a startup doing a web app where there was an elaborate ajax heavy content entry process/forms. The javascript code for this page was an ugly hack, but it worked and was bug free as far as we could tell. The code could have been refactored but we decided not to because no other code on the site depended on this javascript code and it was highly unlikely that we'd need to change that page in the next year. We left it as it was and moved onto adding new features and that was the right choice. We never changed that code, and never needed to, but it wasn't great code. If we'd spent a week refactoring it then we'd have been late with some important feature that wasn't late because we decided to leave the js code as it was.
You're the one missing the point. Don't write the ugly hack in the first place, and you'll find that that code can be written faster, debugged much faster, and won't be an albatross in the long term. I also find that the crappier the code, the buggier it is and the more support requests are generated (the Pareto principle definitely applies here) - which sucks developer time away from more important things and compounds your problems.
This is something that I've seen several times, and in every case the people involved severely underestimated the time suck of crappy code. "It's not that bad" often means that the developer is spending 50% or more of their time working around deficiencies.
ugly hacks, assuming decent programmers, is usually a result of not knowing exactly what you are writing when you first start. This is common, and often it's not worth refactoring it as in the example I gave.
You ignored all the points in my last comment. Let me be more explicit. Bad code is only an albatross if you have to work with it again. What I'm arguing is that it's usually wiser to leave it as it is until the next time you have to work on it, then fix it. It's only an albatross if you don't fix it, and you only save time by fixing it if you actually have to touch the code again. So wait until you're certain that you're going to have to touch the code again, and fix it when you touch the code again, and not before that.
How often have you written a piece of code and known ahead of time that you'd never have to touch it again? Even throw-away code, like data migrations, often gets revisited several times while you're writing it.
So why is your supposedly decent programmer writing crappy code and assuming that they'll never have to touch it again?
Which is my original point. Traditionally the expectation is crappy-fast-and-cheap vs. perfect-slow-and-expensive, but that rarely holds. Instead it's usually the crappy code that ends up being slow to write and expensive, stuck in endless code and bugfix cycles trying to get it right.
I don't think quality and cheap are compatible. I can't envision a scenario whereby a project taking a long time will allow it to be done cheaply and well.
Find a good freelancer, offer him/her some interesting work with a deadline of "when you get around to it", and negotiate on price? I don't think this is impossible. (Of course, you'll need to find a freelancer who can do a good job but can't fill 100% of the hours (s)he wants to work. That may not be trivial, but it's possible.)
Doing it yourself over a long period of time as a personal project. That way you could do it as time permits, which is pretty much free, and then the code would also be up to your own standards because you did it yourself.
India is no longer the place of cheap software development. The Philippines and parts of of the old Soviet Eastern Bloc are where the cheap labor now lies.
Actually, ex-Soviet nations have a huge emphasis on mathematics and similar scientific disciplines. You may get quite a few "Your requirement is stupid", but the code quality will probably be not that bad (assuming the code you need is heavy on algorithms).
Actually that would be quite a breath of fresh air, because one of the biggest problems I remember in my experience with outsourcing to an Indian agency in '04/'05 was the complete lack of feedback or collaboration. They basically expected us to give exact details specs, and provided no evaluation of the product as they went. The code was alright, but it was as if they were doing a school programming assignment, seemingly without consciousness of the fact they were building a product that required people to interact with it. I can understand this as a strategy to maximize billable hours, but it doesn't do shit for building repeat business.
Hmm, having handled some of these assignments, I would say it's not done to increase billing hours. People keep their traps shut for two reasons: deeply hierarchical Indian org structures that don't tolerate opinion, and wanting to reduce friction as much as possible. The times we have pushed back we have been faced with "well, what do you know?" When that happens, the first guy to get slammed is the guy who asked questions. Rinse and repeat over a couple of projects and you get teams that will unquestioningly build you a handcart with a rocket engine.
Wanted to add, for every dollar an Indian firm makes, the average developer gets probably around 8-10 cents or less. When you are at a subsistence level like that, it's difficult to ask questions. You focus on the insecurity instead.
Hm yes, I recall an article about how there's a distinct cultural dichotomy where different countries tend to fall on one side or the other and the implications for management. How an Indian boss, for instance, knows that clues of things going awry are more subtle, and he must draw them out through questioning, whereas for an American boss that might be considered micro-management that would rub the employees the wrong way.
For every dollar a good Indian firm makes, the average developer gets anywhere between 50 and 80 cents. Good devs are equally expensive anywhere, but oddly enough in India the salaries don't grow linearly when compared with first world salaries. A dev with a year of experience will cost 1/5 what he/she would cost in the first world. A (good) dev with 15 years of experience would cost 1/2 what he/she would cost in the US.
This is my ignorance showing, but are there actually Indian devs with 15 years experience? I was under the impression that the culture forced devs into management roles before they reached that point.
Eastern bloc is awful communication wise - I don't know about India but I know about eastern Europe.
When people are told for a couple of generations that they should shut their mouths and look down if they don't want their families hurt. They tend to obey.
As someone who worked in an outsourcing company of former USSR, I don't think that's the case really, most developers are pretty young. If anything, they are unnecessarily opinionated.
How about their managers? To me its the other side of the coin - like depressive people have manic phases.
My experience was that I was development lead of a project that had development outsourced to a former Yugoslav republic. We had clear agreement (on all levels) that we shall use direct communication on appropriate levels. But what happened in reality was that every memo or inquiry I did - the local development lead would not respond to me directly in a timely fashion. Instead the information would be passed up to the CEO of the company who would then proceed to send this information to my Executive Director who would then send it to me (in an understandably untimely fashion). Needles to say we had to break the effort and search for local developers.
And further east you go more of this effect you see - people refuse to convey information that is clearly in their jurisdiction, because their boss might not agree with everything.
I actually began writing about it, but then decided I shouldn't generalize about all of Eastern Europe from just my experience.
Management tends to be poor to atrocious, effective management is seriously lacking through all industries there. Add to that resource constraints and competitive pressure you have in outsourcing shops, and it multiplies many-fold.
That sounds very much like my experience with outsourcing to Romania. The core library and algorithms where very solid, the actual UI and whole application experience was somewhat less so.
Good devs are expensive everywhere (especially when GazProm used to pay 300 euros an hour for SAP support person) and some jobs are outsourced to neighbours.
I've had some decent code written by people in the Bloc countries for a pittance. Was for pretty simple stuff, though, no idea how they would have fared on more challenging things.
Not true. There are good software companies in India to whom you can outsource your work and be somewhat confident that it's done in a reasonable manner.
Many people won't go to them because they are not cheap.
Part of the problem is also the relationship between the managers and the outsourced programming team.
If you spend time in terms of vetting the team for people you are comfortable with, take the time to be as clear and detailed as possible with the requirements, have a good continuous build system so that you can see the software being developed daily, and have direct, continuous communication channels to the coders, one would have a far better experience.
Untrue. They represent only a part of the talented people. I know, we constantly hear about the quirkiness of people at the freelance sites and forums. Perhaps, that's not the best place to look.
If you're not looking for an overtly complicated project, try hiring undergraduate students. Not from any university though. Try the students IIT's and BITS Pilani. These are the foremost technical institute in the country.
So, how do get in contact with them? Visit their Computer Science Association websites, contact their student president to help you out. More often than not, you will find brilliant programming talent this way. Some of them will value a letter of recommendation (that may help in their MS or PhD) very highly.
If not that way, always insist on seeing the portfolio/previous work of the guy you'll be outsourcing too. Else chances are you might end up outsourcing, say a e-commerce implementation, to someone just learnt how to echo in php.
I have been predicting this to friends for a couple of years now - there's absolutely no depth. Infosys, for instance makes only ~15% of their revenue through app development, per their latest quarterly report. When the IT boom started, it was mostly all s/w dev and maintenance. Slowly it has been replaced by non s/w dev activity to the point that s/w dev is only a minor activity (revenue wise).
