3 ms·

One thing that jumped out to me reading the article was the author’s (or the organization’s) aversion to writing requirement spec (“detailed documentation”). T

by achow 10y ago

One thing that jumped out to me reading the article was the author’s (or the organization’s) aversion to writing requirement spec (“detailed documentation”). That sounded very worrisome particularly considering the fact that the development was for a domain like that of Pharma, where rules & regulations shadows heavily on what and how things are done. I have some experience in developing software products for Pharma industry and it was quite an effort in keeping track of FDA updates which would impact the features that were under development or were planned for. Examples, basic and mandatory feature sets like Audits, Logging, Security, Access management, Reports etc. are heavily influenced by compliance regulations of FDA and equivalent bodies of Europe, Canada etc. And added layer of complexity is each regulatory bodies have different approach to regulation and compliance. Considering the fact that Pfizer were outsourcing to ‘code shops’ who would never ever get into that complexity; well thought out requirement documentation which has taken into consideration current and future landscape should have been number one priority. I would have sleepless nights if I was coordinating a project where ‘can do’ developers start working from a basic one-pager from ‘business people’. I guess it was perhaps because the author was the go between the domain experts (he mentions them as ‘business people’) and the developers. It would have been great if the author would have shed some light on what could client do from their end in terms of reducing ambiguity while working with teams where communication and loss in translation is one of the biggest risk. I suspect that there is a whole missing dimension in this story.

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 ago
  Some 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 ago
    Agreed. 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.)
zby 10y ago
Imagine that to compile your program you have to send it to India and wait two weeks. Every simple typo you make takes two weeks to be noticed. I used to work for Nestle when they were working on a global SAP implementation - all development was outsourced to India. I don't know what was the history of this - but when I was there the analysts were required to write so detailed specs that they were like a program in assembler. Only that you could not compile it, run and check if it does what it is supposed to do. That was insane!
- lisivka 10y ago
  Customer representative directly in outsource office solves this kind of problems. Otherwise you need developers which are both experts in development AND experts in the field of your application.
coredog64 10y ago
> One thing that jumped out to me reading the article was the author’s (or the organization’s) aversion to writing requirement spec (“detailed documentation”). That sounded very worrisome particularly considering the fact that the development was for a domain like that of Pharma, where rules & regulations shadows heavily on what and how things are done. He addressed that early on -- he mentioned that much of the development was "brochureware" websites. Don't think the FDA gives a wet rat about that.

by achow 10y ago

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 ago
Some 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 ago
  Agreed. 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.)

zby 10y ago

Imagine that to compile your program you have to send it to India and wait two weeks. Every simple typo you make takes two weeks to be noticed. I used to work for Nestle when they were working on a global SAP implementation - all development was outsourced to India. I don't know what was the history of this - but when I was there the analysts were required to write so detailed specs that they were like a program in assembler. Only that you could not compile it, run and check if it does what it is supposed to do. That was insane!

lisivka 10y ago
Customer representative directly in outsource office solves this kind of problems. Otherwise you need developers which are both experts in development AND experts in the field of your application.

coredog64 10y ago

> One thing that jumped out to me reading the article was the author’s (or the organization’s) aversion to writing requirement spec (“detailed documentation”). That sounded very worrisome particularly considering the fact that the development was for a domain like that of Pharma, where rules & regulations shadows heavily on what and how things are done. He addressed that early on -- he mentioned that much of the development was "brochureware" websites. Don't think the FDA gives a wet rat about that.