I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Deadlines Revealed: The Truth About How We Make It Across The Line

  • submit to reddit
Even though all software developers have the best of intentions, sometime we have to bend the rules a bit in order to make deadlines. In most cases these hacks don't last too long in the codebase, although Microsoft are just getting around to fixing a 17 year old bug. One of the funniest and most original articles I've read, that relates to this topic is Gamasutra's Dirty Programming Tricks. The article is basically a collection of nine pieces of trickery and hackery that people encountered in their programming career. It would be great to hear of your own experiences in the Java development world.

It's not all hacks though. My favourite trick in there is "The Programming Antihero". In this example the team are working on a project where the memory footprint has to be low. Unknowingly to the team who working tirelessy to save every megabyte they can, a senior developer has purposefully injected a wasteful 2MB to make the problem seem worse. Once everyone has got as close as they can to the target, he deletes the call putting the project back on track.
"...so he explained to me that he had put aside those two megabytes of memory early in the development cycle. He knew from experience that it was always impossible to cut content down to memory budgets, and that many projects had come close to failing because of it. So now, as a regular practice, he always put aside a nice block of memory to free up when it's really needed."

You'll find lots of other examples throughout the article covering some shameful hacks to get around those last minute bugs. In my time I've had to write plenty of "this is a hack", or "here be monsters" comments, to warn other developers about the dirty code that I've had to inject into my applications. I've had to put in Thread.sleep() to get around some problems. I've seen times that adding a System.out.println() allows the code to execute nicely, where removing it has caused things to break.  Don't worry, I've gone back and debugged through these issues carefully and fixed them.

At deadline time, sometimes you just have to do whatever it takes. I'd like to hear your software development confessions here. I'm sure there's no developer out there that hasn't damaged their integrity briefly to get across the line.


Fabrizio Giudici replied on Fri, 2010/02/05 - 8:40am

So now, as a regular practice, he always put aside a nice block of memory to free up when it's really needed.

I think I've possibly tried something similar during the very first times of developing with J2ME, for evident reasons. Indeed, this is sort of a pattern for many kind of problems, such as "let's put a few money in that account that we don't use, so we live as they didn't exist, and use only in case". I see a big problem: unless you completely forget that money (in which case, you're loosing them), you - perhaps unwillingly - still count on that money, in some way.

Unless you're the only one knowing that emergency resource and keep the team unaware of it; but it seems unapplicable in most of today's agile processes, where honesty and sharing are some of the key values.

James Sugrue replied on Fri, 2010/02/05 - 9:52am in response to: Fabrizio Giudici

Good point Fabrizio - with honesty, and pair programming, you'd never get away with that kind of thing :-)

Walter Bogaardt replied on Sat, 2010/02/06 - 2:09pm

Heck how often have we seen XP test driven development go to hell. Developers quit running unit tests and resort to attaching to the vm to debug the problem, system.println, and nothing short of sacrificing a small animal just before going to production.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.