The Gamer Corner
Because god gets his power from your tears.
Lost your password?

Programmer Cockiness Levels

Programmer Cockiness Levels – December 30, 2008 9:25 PM (edited 12/30/08 4:25 PM)
Balerion (1224 posts) Elite Powergamer
Rating: Not Rated
So, I've never gotten this vibe from you guys before, but I thought I'd check in and see what you think:

I just had a meeting with one of the main programmers we work with at work. He's in IT and we're in Operations, so, same company but different departments and there is definitely some interdepartmental politics at work.

My boss mentioned in passing about an error that they were having with another project and the programmer's immediate reaction was to shake his head and say "no, that's not your error". This seems pretty mundane and didn't bother me too much. But then it spawned into a fifteen minute long conversation in which the programmer's default belief was that there was no problem with the code (please bear in mind that the testing phase for this code stretched on a good month past its due date and the changes were particularly massive, so the possibility for there to still be a bug or too is not exactly absurd).

I guess I'm just wondering if this is standard behavior? It seemed to me like it was just a major communications gap, scabbed over with obstinancy, but part of me is wondering now.

Also, who usually handles testing with you guys? The programmers or the department who requested the project?

I really think the three “!”s really captures the exuberance that Clair must have been feeling when he almost said it. -Cuzzo
Re: Programmer Cockiness Levels – January 5, 2009 6:35 PM (edited 1/5/09 1:35 PM)
Cuzzdog (1522 posts) Head of Gamer Corner R&D
Rating: Not Rated
For me and my department, it kind of depends on the type of problem being brought up. If the users are thinking there's something wrong with code that's well proven and been in place for years, then it would be the default position that there's nothing wrong with the code. If it's something with a project just recently put in, then there would be some serious concern that there was a bug. Also, there's the chance that the "problem" being described isn't actually a problem at all, but a misunderstanding of how the new code's functionality works. In this case, it's not an issue of there being a bug (which would demand immediate attention), but a flaw in the original business requirements that will take a new project (to be prioritized among other pending projects) to enhance the in place logic. I will say that no matter what, I would take at least a cursory look at what the users are bring up to verify what's being said.

Project testing is a multi-stage affair for us over here. The first line is unit testing where individual parts of the code is tested in isolation from the whole process. This is where most of the bugs are going to be found and I would say most of the time this should be done by the programmer. This testing could be handed off to a secondary programmer, but that doesn't work nearly as well as when the main coder is checking for his own bugs. After all, it's very difficult for a second person to come in cold and know where to expect to find bugs.

Second line of testing is integration testing. This where the code by itself looks solid, and now it's put into the system as a whole to make sure that the entire flow doesn't break your new code and that the new code doesn't break something downstream. Again, this is often done by the lead programmer, but will often also include other programing teams (if you're feeding data to them) or second sets of eyes. At this phase there shouldn't be too many bugs.

Finally there is user acceptance testing. This is where the users who requested the change in the first place comes in and actually checks that things are working to their specifications. At this point, it's more a check that the code is functionally working as the user expected it to rather than looking for bugs. Anything found here should be more along the lines of "When I clicked this button, I expected the numbers to be added, not multiplied", and then you have to go back to the documentation to find out how it's meant to work. Actual "Opps, I just locked the screen" type bugs found here are really embarrassing to the programmer to be pointed out by the users. And the embarrassment of having bugs found here pales in comparison to having bugs pointed out in production released code which very well be why you're getting the "It's not a bug! We're not even checking!" push back from your programmers.

Re: Programmer Cockiness Levels – January 5, 2009 7:36 PM (edited 1/5/09 2:36 PM)
Talraen (2373 posts) Doesn't Play with Others
Rating: Not Rated
I have to disagree regarding testing your own code. The problem with testing your own code is that a large number of bugs are caused by faulty assumptions (generally that the input won't be retarded), and often if you didn't code outside those assumptions you're likely not to test outside them either. Having a fresh set of eyes test your code is like having someone else read a paper you wrote - it may not be the primary method of checking it, but it's always a good idea.

Re: Programmer Cockiness Levels – January 5, 2009 8:02 PM (edited 1/5/09 3:02 PM)
Cuzzdog (1522 posts) Head of Gamer Corner R&D
Rating: Not Rated
Oh yeah. I'm not trying to say you should be the sole tester of code, but I find it's more helpful for the second set of eyes to come in during the integration testing part and not the unit testing part. Integration testing is, after all, where the crazy input assumptions gets tested with real data anyway. What I meant was that for unit testing, that initial line of testing, it's more a time waste to get someone else up to speed compared to the types of bugs you're trying to catch.

For instance, when I was interning here one summer I was put on a project with another programmer that used me as the sole method of unit testing his code. He would take all this time programming his code and then would pass me the freshly compiled results. I would spend 10 seconds looking at the program before noting such small bugs as "none of the new code is showing up on the screen", and then passing the bug report back to him. Now, I don't know if he was doing that to teach me to debug or if he was just very lazy or whatever, but that wasted a lot of time in just passing this program back. It would have been much quicker for him to take a cursory look at his finished product to see, "oh yeah, nothing I coded worked at all". So unit testing is the main programmer, integration testing is the main programmer plus others, user acceptance test is the end user with the main programmer frequently checking in.

Re: Programmer Cockiness Levels – January 6, 2009 12:44 PM (edited 1/6/09 7:44 AM)
chaoscat (452 posts) Ambassador of Good Will
Rating: Neutral
You people test code before it goes into production? I dream of such an advanced environment.

Talraen (11:16 AM): That, and I've learned to parse through Tozzi's contempt
Re: Programmer Cockiness Levels – January 6, 2009 12:52 PM (edited 1/6/09 7:52 AM)
Cuzzdog (1522 posts) Head of Gamer Corner R&D
Rating: Not Rated
Yes. We even budget time for testing right in the project plan. Of course, we don't put a realistic amount of time for testing in the project plan, but it is in there. Maybe one day you too will know the magic of having one week to test things before they get released. Just keep reaching for those stars Tozzi.

Re: Programmer Cockiness Levels – January 6, 2009 3:25 PM (edited 1/6/09 10:25 AM)
zippy1981 (4 posts) The Wonder Squirrel
Rating: Not Rated
First of all sorry for mis-clicking on the description icon. There should be an undo button.

Secondly, its really not about the testing process, its more about the people doing the testing. You can have all the process and scheduling in place, but if everyone just marks the tests as passed and writes the wrong unit tests, it doesn't matter.

Active Users: (guests only)
1 user viewing | Refresh