We've all been at the barrel end of that dreaded word we call a deadline. Many of us first encountered it during our school days. "This assignment is due Wednesday". "Your exam is tomorrow". etc. And we hated it. All of us. You rushed to get those last sentences in and try to reach the 3-page goal or it wouldn't be accepted. As an adult, the entire schooling process seems ridiculous to me now. So many arbitrary dates were put in place making it difficult to learn efficiently. Your goal was just to finish, that's it. Maybe it was a solid 'B' paper or maybe you barely skimmed through it with a 'C', it didn't matter as long as it got done.
Jump forward a few decades later and the exact same process still goes on day in and day out. We get to work early and slash those final t's and dot those pesky i's and shoot the outcome down through the shoots and hope for a 'B' but settle for a 'C'. Deadlines aren't by nature a positive thing. It's even got the word "dead" in it, I mean come on. Sometimes they're a necessary evil, but they won't lead to a better product in the end.
If that system is broken and leads to the lowest standards of work, then why do we continue to apply those same rules to our everyday adult work life? Here's the thing. In school, I can see why deadlines were put in place at the expense of the students education. A teacher only has so much time to cover materials, because the semester is only a few months long and because they have to analyze the work of 30 plus people within a few days time. I get it. But in a work environment, we don't have those barriers. If you're making a contact page for a website, "tomorrow by 3 pm" makes no sense. Also, that's a pretty long time for a contact page. My point is there is no right and wrong time for a contact page. I've worked at several companies in my years, and the ones that implemented what were normally tight deadlines had high turn over rates and high error rates. Why? Because every project was finished under duress and was normally done sloppily to reach the due date. Developers weren't given the chance to plan and execute which is how I personally work. It was just non-stop typing until the web page matched a PNG file.
When Deadlines Make Sense
Deadlines make sense when they have a calculable loss if they are not completed on time. I once worked on a project at a previous job that a client was paying good money for and they were going to include a bonus if we could get it done early. Needless to say, that was not my money in any way, but it was my project and I wanted to come out ahead on this one. So I worked tirelessly for 2 weeks straight and clocked in about 180 hours for those two weeks. My life was pretty much this project. Did we reach the deadline? Yes. Did we get the bonus? No. But the deadline was enough. A week after the deadline the company paying for the project wanted to make some relatively large changes. Were they possible? No. Not one bit. The database schema wasn't designed with those changes in mind, and the UI code was so convoluted and verbose that it would of taken a week to just figure out how it worked again. Deadlines require hefty payment for their one benefit. Mainly that of unused code and test code strewn about all over the place and duplicate code all over the place.
Deadlines are a very "officy" term. Managers make charts and timelines and graphs and such and stare at them daily, and change them daily. A manager will put deadlines in place so that they can make more deadlines after that. That's it. If this is due tomorrow, then the day after surely this other item must be due, and so on and so forth. This entire month will be planned out in 1 hour and all will be good. Except that's never ever happened once. There will be daily changes, which make the entire process meaningless. Those reports and timelines are only good for 1a few days at best, but this process is still prevalent in most offices today.
And So Your Code Suffers
Here's a graph of what happens to your code when deadlines are put in place. That last hiccup is the crux of the entire process. Everything looks good and maintainable until you're down to your last few days before the project is due. In a frenzy to try and get everything visually functional, regardless of usability, you will go to pretty crazy lengths. Everything from faking working webpages to showing 100 columns into one single table. As a developer, I panic and do stupid things when nearing a deadline. Many times on purpose followed by me telling myself "you can fix this once it's live". Little do I know that that won't happen. Every developer that I know does it and every developer hates doing it. Mainly because it's code that we ourselves have to work on later on.
When Do You Need It By?
How long will that code take to write is the most hilarious question that I've ever gotten. Usually my answer depends on "When do you need it by?". Not because I'm going to code at a slower speed if you have the time. No, because the way I code it will depend on how much time I have. If you need a module in two days, then the code is going to reflect that. It's going to be quick and grimy and it will get the job done. It will have hardcoded values And maintenance on it will be difficult. If I have as long as it takes to finish, then the code will reflect that as well.
I recently had a project I was working on for an employer and was told there was a set target date, which I was hesitant about due to the depth of the project, but my manager seemed attached to that date for whatever reason. So I said I that it was doable. Because it was. It could of been done in 1 day if need be, it just would of been 90% hardcoded and crashed 18% of the time. I started off well with the project as it looked like I had plenty of time. I was writing good clean code and reusing things as much as I could and all was good. Then came the week before the deadline and all of a sudden that wasn't important anymore. I had 5 days to get this project out the door and I had only finished maybe 40% of it. I'll say this, 60% of the code for the project was written in this last week. Is it reusable? No. Does it make sense? Probably not. Is it running for this scenario only? Yes.
A Good Developer Doesn't Need Deadlines
Here's my main point. A developer who knows what he or she is doing doesn't require anyone to watch over their shoulder as they do what they do. They read the specs, they ask questions, they take notes when they have more questions and they do so in their own time. Many times, that developer spends less time coding than the one who typed non-stop for 2 weeks. Currently on all of my personal websites which I normally take my time on, I can add new modules and modify current ones within minutes. I know exactly where everything is and not once have I said "damn, that's not possible". At work however, that's almost a daily mantra.
Those imaginary users that managers think they have aren't going anywhere. There was zero demand for that new module you were working on yesterday, and the idea that releasing it sooner will yield financial gains is specious. If you find yourself overwhelmed with deadlines then maybe it's time to find a job that has some respect for the work being done. It's both better for you as you wont pick up bad coding habits, and it's better for the future developers that will inherit your work one day and just maybe they'll say "that code was fantastic". One can dream.
Walter Guevara is a software engineer, startup founder and currently teaches programming for a coding bootcamp. He is currently building things that don't yet exist.