10 Effective Tips For a Web Developer to Meet a Tight Deadline
As a developer working in a creative agency, I get to work with a lot of different projects and, as I started off as the only developer, I had to adapt to the projects that came to my desk. This is in fact a belief I have: that such submission to tasks is what actually promotes one’s abilities, and allows us to really find out our strengths.
From a development point of view, the main issues with such projects were:
- It often involved an idea that was totally new to the team in terms of the best way to tackle it, libraries to use, time estimations, design elements, etc.
- Very tight-deadlines, with the time needing to cover analysis, design, development, testing, and integration. Having a tight-deadline means making trade-offs between analysis, design, implementation, and testing. Often in such projects, the analysis will only produce a list of the main general functionalities. This is especially true if it’s a new idea and you don’t have a full picture of the development process and what it will involve.
- The company’s reliance on you and your team to deliver.
- The team feeling unprepared for such pressure.
In one instance, I was given a brief and very simple sketches of what the app should look like. The time allocated to the project was four weeks, however, it was split between two projects (as I had to do some work for another project in parallel). After spending an hour or two on the basic functional requirements analysis, I found that the amount of work needed to be done was enormous, especially because the idea was new to the team. At that stage, I felt that it was not something to escape from; the client had already signed off the idea and we were already a week behind, leaving only two weeks for development and one week for integrating the designs, tweaking and testing.
So, here is what I decided to do in order to effectively meet a tight deadline:
- Submit to the task, feel the responsibility, and rise up to/accept the challenge. Submission to the tasks you have is the first step towards doing any work, otherwise you’ll waste more time trying to find alternatives which are often non-existent.
- Adopt a new methodology for development that will produce prototypes quickly: long sprints won’t work in such cases and new features should be produced and tested on a daily basis. Start with the most important pieces, make it very clear, don’t over complicate functions, don’t over complicate the structure, and don’t waste time thinking about performance. All of these things can be dealt with later on. In short, write small, testable pieces of code and adopt a continuous integration plan.
- Design your code for flexibility (as the sketches, layout, and the application interaction might change upon design arrival). Your code needs to be flexible enough, adopting best practices such as DRY, OOP design patterns, SoC and so on.
- Write clean, clear, self-explanatory code. This was particularly important in my case, because I was the only developer working on the code. Due to the tight-deadline, I didn’t have time for proper documentation, and thus I had to make sure that functions, classes, properties, methods, and even file names followed a naming convention and were self-explanatory.
- Start with the most complex (less documented, involves learning) and then move the other parts as applicable. The best way that I found to actually conquer something is not to wait for the learning process to finish, but to learn as you go. You often do not need to learn everything, and in such projects you don’t even have the time to learn everything, so don’t get sucked into learning stuff that you will not use and keep yourself focused on what you need.
- Simplify processes using flow diagrams to see the application flow, and don’t over complicate your code – even if, by doing so, you’ll have to go against some of the best practices. However, make note of such cases and leave them for the code cleaning stage.
- Clean your code at the end of the day. During such projects, you will often end up with lots of commented code sections, or TODO comments. Before you commit to any changes, make sure that you remove the old commented code and do any simple TODOs in there, because along the project, you’ll add more and more code to that file, and you may end up with contradicting TODOs which may lead to more confusion. Also, this helps with keeping you on track, and helps in keeping you focused in the implementation process.
- Be a good example for your team mates and help them to adapt to the size of the project. Remember this is teamwork in the end, and staying calm and taking things easily will be reflected in the attitudes of your team mates.
- Enjoy the challenge. Learn as much as much as you can from it, and see it as a way to train yourself to adapt.
- Enjoy the sense of achievement at the end of the project.