4 ms·
The process of writing software involves some interpretation and making good small-scale design decisions. Think of things like checking for buffer overflows an
by ploxiln 10y ago
The process of writing software involves some interpretation and making good small-scale design decisions. Think of things like checking for buffer overflows and error handling. If you completely specify how this is handled everywhere you've practically written the software already.
One trivial and silly real-world example: I'm currently working on a C codebase with a few developers in India. Sometime before I started the project, the American company I now work for contracted out a security audit of the code, and one of the obvious conclusions was that "safe string functions should be used" - strcpy() had been used to copy user input to statically sized buffers such that it was vulnerable to classic buffer overflows, all over the place. Requirement set, requirement followed - now strncpy() and strncmp() etc were used everywhere, but always either uselessly (25% of the time) or wrong and unsafe (75%). Most typical was to use the length of the source, calculated with strlen(). Now, I guess it was not specified "use strncpy() correctly, with the size of the destination". Failure of specification, right?
For what it's worth, the root of the problems on this particular project are that the original American lead dev was not that great and set some bad examples, which the outsourced devs copy diligently and industriously.
(But then again, it's not enough to say "this is clearly wrong, it will overflow if (expr)" - they tend to need explicit examples to copy. Sometimes they impress me by figuring the cause of a tricky bug. Sometimes they write smart but actually useless code, like using floats and log() to figure out how big a buffer is needed to print a uint16_t in decimal - 5 bytes will suffice, no float math needed. Sometimes they write 20 lines of code to calculate how long the string result of snprintf() will be, instead of using the size of the destination, right after I've lectured on what strncpy() is for. They often seem less thoughtful than a neural net. I've even seen "buf[strlen(buf)] = '\0'" - I just have no words sometimes.)
- fgpwd 10y agoSome of these examples made me smile. But this cannot be taken as a representative of all developers in India. I am an Indian developer, and have met several very smart people. Most of them are presently working for big US companies like Google or Adobe. Often when I meet a programmer, I can tell if they are genuinely interested in programming, or just happen to be a programmer because of circumstances or because it's what they decided to do to make money. The latter when writing code for you would just want to somehow meet the specifications and head off for the next lunch. They would be the first ones to complain about their job on social networks. As sad as it is for them, you really don't want to hire them if your aim is to build high quality products. There are still a lot of good, capable developers in India, available for hire and at affordable rates. You just need a good process to find them and filter out those without a genuine passion for writing code or for building products. Hiring random people without a thorough selection process is always a bad idea, no matter which country you hire from.
- ploxiln 10y agoAgreed. It's not about India, it's about outsourcing. Good developers get better jobs where they are not a fungible resource. (And sometimes they move to the US or the UK.)