But who can blame a hell-desk guy for assuming that rewriting a complete application in a completely new language can not possibly create any bugs.....
Oh, I can go one better ... project proposal earlier this year: "We will avoid this technical risk [excessive test/bug-fixing workload] by producing multiple prototype applications in different languages". Yes, actually thinking that developing the project multiple times in different ways would be easier than testing and debugging it properly ...
I do the second to last one sometimes. If the code that can fail and the prior code that prevents it from failing are too far apart to not fit on the same screen, my brain gets nervous and goes into "can't be too cautious" mode.
People make the exact same mistakes, regardless of which language or framework they are using.
If the mistakes are characteristic of the problem domain, yes. If the mistakes are characteristic of the programming language, no. Unless the different languages used to make the versions are similar. (For example, Ruby and Python have pretty similar semantic models on some levels, and will attract some similar language-induced problems. You'd get different ones with OCaml.)
There's no assurance that producing lots of versions will give you a bug-free version. Not unless one of those versions happens to be done with the aid of a superb test suite…
This totally happened in our team. Just couldn't pin down the source of that bloody error.
Only that the coder in question put in "F**ing Sht" AND the message then popped up in production with several users.
We got a very loud and insistent phone call from quality management. :laughing:
part. Under what circumstances will i then be less than 10, 100 or 1000 ... or greater than 10000, 100000 et cetera? (And just how many further powers of 10 were snipped?) The implication is that this is a copy-and-paste function that occurs repeatedly in the code, for differing ranges of i each time. The wtfs multiply...
Ok, exact same mistakes was a bit of a hyperbole, but my understanding is that Knight & Leveson showed that there was a statistically significant correlation in the errors that were made, regardless of language or methodology. Its not that nvp has no effect at all, its just that the bang for buck is a lot lower than you get with proper design and testing. Especially if the spec itself could have errors in it.
@jas88, maybe you could still salvage this. Tell them you think its a great idea, and that they should take it one level further by having one team design each unit, and have some process call that unit with a variety of inputs and record the outputs, then get the next team to implement the same unit, and check that it has the same outputs for all inputs. Et Voilà, your company just invented unit testing.
@Buddy: "one team" ... "next team" ... that would rather require the project to have a non-trivial number of developers, wouldn't it? Having a design and some sort of spec would be nice too. (At my last count it had 3 people, none more than 20% FTE.)
So far, the goal is to track sensor input from a building .. and somehow use that to feed back into CAD systems. (Yes, plural.) They'd forgotten to mention that aspect in the funding bid though...
Last time I was thinking about their aims, I was comparing it to the idea of a manned mission to the sun: not just impossible, but certifiably insane to contemplate in any way.
Files are shared resources, and it's pretty easy to run into concurrency issues. So you check if the file exists again... and cross your fingers and hope it doesn't get renamed or deleted in between
Especially for local files, because the idea of file locks is patented, afaik. Network files are not so much of a problem, for network connections are 100% reliable, as we learned from one of our clients*.
* indirectly - they asked why the heck we'd rather use a local copy of a 5 KB file instead of just Doing It Right™, that is, using a web service.
I'd also initially failed to identify the snippet as VB, because back when I used VB having all keywords in all-caps was still mandatory.
AFAIK it was never mandatory that they be all caps, although the editor might have automatically changed them to all caps as you typed.
Anyway, that fragment of code doesn't use curly braces, used ' for comments, and If ... Then ... Else ... End If syntax... combined, that is pretty indicative of VB (Fortran has END IF, but uses ! for comments and I don't think it supports Throw either).