Reality check

January 24, 2000
by Zac Belado

You probably work too much. I feel confident in making this statement even though I don't know you because I am aware of the way in which projects in the web and multimedia industries are typically produced and executed. The multimedia industry is unique in that it combines 21st century technology with 19th century work habits and hours. It isn't much of a stretch to say that the entire software industry is built on the premise that only weaklings and the unmotivated need eight hours of sleep a night and that a 50 hour work week is the sign of someone starting to show a commitment to their job.

Not only do our parents not understand the technology we work with but they typically don't understand why we work the hours that we do. And they're right. We work too much, work too many unnecessary overtime hours and don't take enough time to relax and enjoy our lives. Technology may or may not improve productivity but one thing it certainly does is make it easier for bad planning and customer relations decisions to be "fixed" by increasing the workload of the developers who ultimately create the products.

Planning is everything

Developers are at the bottom of a planning feeding chain that often results in them having to make up for missed deadlines by other people in the production schedule. Client sent the video in a week later than they said? Too bad. Legal took too long going over the language for the project? Too bad. And before you think I'm just complaining about the hours that I occasionally have to work think about the effects of the condensed production schedules. Each missed deadline further up the chain means that you, as a developer, have less time to produce the final product and, more importantly, less time to test and debug the product.

Less time to work means a less stable product with more bugs. Which means that the client gets a lower quality product. But no one seems to be too concerned with this. At least not the people who seem to be making up the schedules.

But this fact is almost never acknowledged. For some reason the focus of production schedules isn't giving the customer the best quality product for their money but giving any product to them on the delivery date despite any problems and regardless of the quality of the final product. The industry is fixated with meeting delivery dates and less concerned with quality. In fact if you've been in the industry long enough you know how dramatically this has changed. Software product cycles used to be measured in years. Now it is in months.

And this comes at the expense of the people, you and I, who actually produce the products. Not only do we work insane hours to meet these deadlines but we produce work that we are not satisfied with. Software developers find less creative satisfaction in their work than the average Starbucks barista. Speed has become the benchmark by which the success of a product is gauged. Meet your shipping deadline and you're a hero but miss it by a week because you fixed a potentially debilitating bug and you're probably on the fast track to be replaced.

I'm okay. You're insane

If you've been in the industry long enough (or are just naturally cynical) then you tend to view deliverable schedules as something akin to a Grimm Brother's fairy tale: interesting to read before you go to bed for its entertainment value but not having any bearing to the real world. Tales of talking wolves eating people's grandmothers are only slightly less surreal than plans for the client to actually deliver their content on Monday and for the writing team to have finished editing it by Tuesday at 4 PM with an initial beta delivered to the client on Friday morning.

Part of the reason for this is that there is almost never any penalty or missed deadlines... except for you the developer. Have you ever been in a situation where the client has been penalised for delivering content late? Have you ever seen a project manager tell a client that they can't make last minute modifications to a project because they had missed their cut-off time for changes?

Probably not.

And do you ever think that anything will ever change this situation?

Probably not.

Do project managers ever seem to plan for this eventuality?

Nope.

Project management in the software industry seems to suffer from a level of delusion that would get a person heavily medicated and assigned to a padded room for their own safety. One definition of insanity is expecting different results from the same input. And yet project after project gets planned with the same naive assumption that deliverable dates will be met, changes will not be added at the last minute and that senior VPs will not want to mark the project by making a pointless last minute addition just so they can say they had input into the project and justify their salaries.

The rest of the story

The end result of all of this is that the people at the bottom of the project's chain of deliverables (that's me and you) often have to work insane hours... and often for no extra money. If the software industry is typified by project managers with the planning skills of near-sighted, absentminded chimpanzees it is also run by company owners or managers that would make Ebaneezer Scrooge seem like a Marxist Progressive.

Companies either don't pay overtime or offer it to employees as "time in lieu" that no one ever seems to take because they're either always running against deadlines or they move on to a new company before they can take the time. An industry that views year old employees as "veterans" is not the place to be taking deferred overtime payments. What good are 12 month bonuses if you are only there for 9? What good is time in lieu if you are never not in "crunch time"? Our parents looked at overtime as an occasional source of a potential windfall and we look at overtime not only as an accepted fact of life but also as a burden because we are invariably not adequately compensated for it.

And not only does the worker suffer from it but the entire industry does as well. The software industry suffers from an embarrassing employee turnover rate. What other industry do you know of that treats highly skilled and valuable employees in a manner that is guaranteed to result in burn out or the employee leaving? The software industry complains about this (and often tries to avoid the problem by characterising it as anything other than employee burn out) and is always on the lookout for new talent without looking at the root causes of the problem.

So what can you do?

So where does this leave you, the overworked and stressed out software developer? You could always try to find employment at another firm but odds are that the next place you work at is going to be run in just the same fashion. The best thing to do is to change your working environment. And the only feasible way to do this is by framing your comments and requests in terms of providing better customer satisfaction and increased productivity for the company. Why? Because any company that had any concern for the long term health and welfare of their employees wouldn't regularly make them work 50+ hour weeks with no extra compensation. A pool table and all the Mountain Dew you can drink is no substitute for money in the bank and a proper amount of free time and rest.

The software industry is odd in that it is driven by a manic desire to satisfy clients, even to the point of letting the client make last minute additions and changes that jeopardise the project, but it only does so by trying, for the most part, to give the client what they want quickly and cheaply. And then it drives its developers to work long hours to meet ridiculous deadlines.

The end result is, as I have mentioned, a lower quality product for the client with a potential for more bugs which often means lower overall profits on the project. A week of testing that was dropped from the schedule could result not only in just increased tech support costs but it might also result in bugs or errors that could require you to recreate the entire project. I know of several firms that have spent in excess of $70,000 to fix bugs that could have been caught if there was an adequate testing schedule. And even if you include adequate testing time you still need employees that are well-rested and alert. Relying on the critical judgement of employees that have been working 60+ hours a week and sleeping under their desks is only slightly more efficient than not testing at all.

Quality projects take time. But they also bring the customer back. Speed isn't a competitive advantage when everyone is willing to work as fast and as cheap as your firm.

Experienced staff work better and are more productive than new hires. A company that has to spend time hiring employees every six months loses money in training and in less productive employees.

Relaxed, well-rested employees are more productive and make fewer errors.

If you plan for the worst possible case then you will never miss a deadline because you've already accounted for the extra time.

If you plan for the worst and it doesn't happen you have more time left to polish and test your product. Making for a better product

Next time you're staring at insane deadlines think about what is worst, living with that situation or trying to change it and make a better working environment.

Zac Belado is a programmer, web developer and rehabilitated ex-designer based in Vancouver, British Columbia. He currently works as an Application Developer for a Vancouver software company. His primary focus is web applications built using ColdFusion. He has been involved in multimedia and web-based development, producing work for clients such as Levi Straus, Motorola and Adobe Systems. As well, he has written for the Macromedia Users Journal and been a featured speaker at the Macromedia Users Convention.