On Messing Up and Missing Deadlines
On Messing Up and Missing Deadlines
Join the DZone community and get the full member experience.Join For Free
Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.
Last week an interesting question was launched on the Smashing Magazine's Twitter account: "What's the biggest mistake you've done in design/web development or your career so far?". The perfect trigger for some soul searching that ignited a little (yet stubborn) nibble I've been wanting to blog about for some time now, so here goes.
Don't Worry, Be Happy
Everybody makes mistakes, that's only natural. As anyone with a basic level of life experience will tell you, don't get too worked up when it happens to you, just look at it as an opportunity to learn from your mistakes. And front-end being the cesspool that it is, opportunities will be creeping up on you all the time.
I've made mistakes that nobody ever noticed. I've also made mistakes that reared their ugly heads on a level 5 page with a total page view count of 10 that some content editor published without double checking. Then I've made mistakes that cost a lot of money to fix. Even some mistakes that persisted throughout the project and made every new change tougher than it needed to be. I have a million options to choose from really, but singling out one single action didn't feel like it would adequately answer the question
The Big Picture
Looking at all the projects I've worked on over the years, big or small, there's been one nasty constant. A mistake that creeps up on you at least once a project and puts an indelible mark on all future work. And it has everything to do with not sticking to the optimal workflow. Once you start to compromise on workflow, you start to compromise on quality and that's usually the beginning of the end.
A website requires a lot of planning. Strategy, architecture, design, front-end, copy and back-end all cross each other's path. Things are bound to go wrong at some point, deadlines are bound to be missed. We don't like to admit it, certainly not up front, but whatever timing you make, you can be certain you're going to miss at least one deadline.
Deadlines are important. I am one of those people who appreciate the pressure a deadline puts on a project. Missing a deadline is generally not okay and people should do their utmost best to make their deadlines, but putting everything at risk to meet a deadline is quite possible the worst thing you can do. And that's where it often goes wrong. Rather than inform a client that a deadline cannot be met, "solutions" are proposed to try and get a project on track again.
My advice: if those solutions impact the ability to do your job well in any way, fight it as hard as you can. Intermediary deliveries, reduced development time, extra features without extended deadlines, mid-development change requests, parallel development that isn't feasible ... do everything in your might to avoid these situations. If you don't you'll end up cursing them afterwards. Situations like these are sure to result in shortcuts and quick fixes, unfinished work or lack in detail, jeopardizing the project as a whole.
Deadlines are rarely 'hard', even when everyone (including the client) is pretending they are. I've been in so many situations where we were failing to meet a deadline, changed things around to make it work, fucked it up and had the deadline moved when it turned out we weren't going to make it either way. It's usually a lot safer to push the deadline back a little or go for reduced functionality (and fix it post-launch) than to take the gamble.
When making a website, there's little or no option for "turning back" or "refactoring" once the website is live (of course there is in theory, but it never happens). That means that whatever you fuck up during the process remains that way until after 4 years your client decides it's time for an entirely new website. Many of the "solutions" proposed to meet a deadline will turn out to be more costly in the long run and will end up decreasing the quality to often unacceptable levels. You can't always stop it (people are stubborn), but being part of the development team means you have the obligation to fight these decisions and to warn people of the dangers. It's often an uphill battle, but even if you only win a few it will make your job a lot nicer along the way.
Published at DZone with permission of Niels Matthijs , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.