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.)?"

Comments

A little late?

[Anonymous Coward]

Why do they warn us in December?

Re:A little late?

[M. Baranczak]

So you have ten months to prepare.

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

Re:A little late?

[Laz10]

Looking back at my invoices, I can see that I usually work more hours those two months than any other months of the year.
I also get depressed from lack of sunlight in the dark Scandinavian autumn days.

On the other hand a total of one (and that was some trivial layout) bug was reported on the code I coded and shipped in that period this year.

Maybe the bugs are only found later?
That also suggests that the bugs found in October and November was introduced by the interns during the summer vacation?

Re:A little late?

[tlhIngan]

Or the group is tackling more complex things in those months.

Easy - it's the holiday season.

Or you have to realize that October is Ship Month(tm). If it's a physical product that goes in stores, it means the product is sitting in the factory waiting for the software to go on them (it takes many months to get stuff manufactured from component ordering and lead times to physical assembly, so it happens during software development). The code has to be shipped by end of October so the factory has November to program and ship the product to the distributors and then to retailers by December to be on the shelf.

And that's if they're fast at doing so - most of the time, the product can't be assembled and shipped because all factories are busy, which means what goes on them is a test firmware that downloads the latest on bootup. (Ever notice how many things do a firmware update when you first turn them on? That's why). In which case the deal is to have it ready by shipment in November.

If your product is software, but has a physical element (like a disc) then your timelines are still short as you have to ship *something* by October to the presses, and then you patch it during October/November while you wait for the discs to come back so you can ship for the holidays. And the goal is to have something

If your product is purely Internet download, then you need to compete with approvals and all that but that means you have all through October and November to squash bugs. But with any fixed ship date, well, squahing one bug can introduce two more.

It's because of the holiday seasons that people are furiously fixing and finishing software. No wonder that there's more bugs - people are doing more "quick fixes" that may not be properly tested in order to ship.

Whoa whoa whoa

[DJ Jones]

You guys have kids?

Re:Whoa whoa whoa

[Anonymous Coward]

Seriously? You haven't forked off a child and dealt with real process management issues or handled dirty log files until you've installed mini_me 0.2. And don't even get me started on working out the upgrade path to teenager 0.8. I'll guess you haven't even upgraded your personal operating system to the point where it's compatible with wife 1.0, heck you probably haven't even found a place to download girlfriend 0.3 let alone figured out the sweet_love module. Revoke my geek cred? Yeah right.

Is there ever a good month?

[Anonymous Coward]

Okay like so many other Slashdot readers, I only read the headline...so what month is a GOOD month in which to write buggy code?

Re:Is there ever a good month?

[anonymov]

Weeks 0-4 of PLACEHOLDER STRING - DO NOT USE are best for writing buggy code.

Useless information - currently

[willaien]

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?

Re:Useless information - currently

[Anonymous Coward]

Real programmers get confused.

Remember, OCT31 = DEC25

Don't get me started on this one ...

[Grindalf]

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

Budgets, schedules

[br00tus]

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.

From experience

[james_van]

Couple of reasons from the office I work at - end of year deadlines means code gets rushed in Oct/Nov in order for testing and review before Christmas. Also, those of us who haven't taken all of our vacation time yet are forced to take time off, disrupting projects. Last minute client changes (to the projects due at the end of the year) add to the pile. And, the stress of the holidays plays a part as well (mostly because we're asocial geeks who are dreading the onslaught of family get-togethers and forced social situations). Usually by December, we've got our projects off for review and testing so there isn't much code being written, and the code that is being written is in response to problems and is a chance to take rushed, bad code and make it a little bit less bad. That's my little piece of anecdotal evidence.

Buggy code is pretty basic stuff...

[mark-t]

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.

bad heading

[roc97007]

Should read "October, November are the *best* days for writing buggy code." They're the worst days, apparently, for writing bug-free code.