5 ms·
Good. Cheap. Pick one. In a previous life we outsourced to Indian companies because it saved a lot of money (on paper)[1]. The good ones seemed competent, b
by gvb 16y ago
Good. Cheap. Pick one.
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.
- hartror 16y agoIsn't it: Quality, price, speed pick any two.
- anujkk 16y agoVery true.
- redthrowaway 16y agoI 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.
- jarek 16y agoBreed monkeys, give them keyboards, wait a million years.
- redthrowaway 16y agoEven then, you'd still only get Perl.
- JoachimSchipper 16y agoFind 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.)
- retroafroman 16y agoDoing 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.
- anthonyb 16y agoFor 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 http://en.wikipedia.org/wiki/Project_triangle
- Stormbringer 16y agoYes! That is it. Software must be one of the few things in life where going for the higher quality actually makes it cheaper and faster to develop.
- jshen 16y agoYou only have to get over a certain bar. Improving code after that point isn't a good ROI
- quanticle 16y agoNot 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.
- jshen 16y agoI 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.
- anthonyb 16y agoI'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.
- gvb 16y agoIn this case, speed wasn't a variable. I intentionally left it off. (Thanks for being my straight man ;-).