Oh, no, that wasn’t what I meant. I meant that the analyst may have not thought much past “16 digit number”, and the programmer may be aware of it being a credit card (probably due to the heading!), but doesn’t do anything, you know, useful like say “Hey, this is a credit card. Are you sure you don’t want something a little better than just a 16 digit number?”.
The vast majority of programmers (especially foreign ones for some reason) will take the spec as gospel, not ask questions, not point things out, and just build it as-is, putting the entirety of the responsibility on the analyst, rather than sharing in the responsibility of producing a good finished product. It’s like they’d rather knowingly write something half-featured than bring up a question or make a suggestion when the specs aren’t as feature-rich as they ought to be, or worse, if the analyst left something out by accident.
Just thought of another possible scenario. Few developers today have the experience that I got when I was a young whippersnapper. Case in point:
I never worked for a company that had business analysts or even separate system analysts. We programmers were responsible for all of that, plus our coding work and end user support. As I mentioned earlier, this was back in the dumb terminal days. i had been asked to implement an invoicing system with a few accounting reports coming out the back end of it. One day I was presented with a monthly report and was told that it didn’t add up correctly so fix it.
The short story is that I spent three full days, with no interruptions, with the report program running in debug mode on my terminal, iterating slowly through the loop that added up all of the thousands of line items, the printed report on the desk in front of me slowly flipping through the pages correlating with the loop iteration, and a hand calculator next to that adding up things as I went along to make sure my hand math matched what the computer was getting. (I had tried some faster techniques first, that didn’t pinpoint the error, so I ended up doing this agonizing exercise.) Early on the fourth day I found the culprit: some user of the invoice system had typed a “?” into a price field. The system and report happily accepted it and somehow managed not to puke but just made the report not total correctly. The idiot who failed to code validation routines in the invoice front end was… of course, me.
Actually, that kind of thing is no small part of why I get so chapped at what I tend to think of as lazy programmers who follow the specs slavishly, and who never ask questions or suggest anything.
I started out as a combination BA / programmer, and eventually shifted into the BA role full-time after about 6 years. So I’ve seen both sides, and it frustrates me when the mentality is that the safe thing to do is to follow the spec to a T and not ask questions, because that’s the safe and easy thing to do.