Slashdot Mirror


October, November the Worst Months For Writing Buggy Code

chicksdaddy writes "Data from application testing firm Veracode suggests that the quality of application code submitted for auditing is pretty much constant throughout the year — except for the months of October and November, when the average density of vulnerabilities in the code jumps considerably. But why? Is it the pressure of deadlines? The stress of developers' lives (kids back to school, etc.)?"

7 of 136 comments (clear)

  1. A little late? by Anonymous Coward · · Score: 5, Funny

    Why do they warn us in December?

    1. Re:A little late? by M.+Baranczak · · Score: 5, Funny

      So you have ten months to prepare.

      I bet if we all work hard, we can produce even more bugs next October.

  2. Useless information - currently by willaien · · Score: 5, Interesting

    Are there other jobs that have their job performance drop considerably during these two months?

    If not, what can be used to explain this anomaly? Bogus study? Something unique to programmers?

    Is it consistent throughout IT? Are there more reliability issues that can be traced to those months?

    1. Re:Useless information - currently by Anonymous Coward · · Score: 5, Funny

      Real programmers get confused.

      Remember, OCT31 = DEC25

  3. Don't get me started on this one ... by Grindalf · · Score: 5, Funny

    I've studied this stuff, it's down to STUPID programmers. Hire people that can type properly. This was everybody wins ...

    --
    The purpose of existence is to make money.
  4. Budgets, schedules by br00tus · · Score: 5, Informative

    Most businesses I've seen, a list of things to do is drawn up in the beginning of the year and set as a goal. Achieving those goals goes into consideration for how one did in a year, bonus, next year's budget etc. The list is usually unrealistic due to pressure from above (or other executives whose title may be the same level as the CTO/CIO, but who are for all intents and purposes, at a higher level due to being so-called "profit centers"). The code base being built on is usually old and broken, the equipment it runs on not the best, the team so-so with a few bright people, and a lot of dumb managers. Things not counted in the schedule are long-time experienced employees getting fed up and leaving, equipment breakdowns, bugs and emergencies that have to be dealt with, or business units who change what they want all year long from the original specification. Plus other things - a third party product is bought, and is very difficult to integrate in the existing system, with more time than initially planned for. By October not many things on the year-end checklist are done and the CTO starts having meetings and banging on the table that he needs checks on the lists to show the CEO what his team has done this year. So people stop writing good, long-term code and start writing crap, so they can check off the list for the end of the year. Things slow down by the end of December, that a few things on the list won't get done becomes accepted, people go on Christmas vacation. That's why bugs go in in October/November.

  5. Buggy code is pretty basic stuff... by mark-t · · Score: 5, Funny

    All you need to do is simulate the four wheels, and add a rigid body that can be approximated to a box for the main chasis. If you want to get fancy, you can use a polygonal mesh. Then you can use any old physics engine, and presto... you have a buggy.

    It's writing the code for the horses that's a real bitch. There's AI and stuff, and figuring out how the horse should react emotionally to various situations... THAT'S one hell of a challenge.