One core aspect of fast paced environment is that you have to hit your deadlines consistently. It happens a lot in the startup jungle. You can be in a situation where you're building a product or feature already sold with customers waiting. Being too slow can result in cancellations and too many cancellations can kill the company. A failed first launch date, or a failed demo to an investor can have the same consequence. Your company can be one missed deadline away to survive or die, but it's not necessarily the case. It's really important to be conscious of the price of missed checkpoints.
Are you really facing a "dead"line ? If you recognize that the company is short on cash, being a little empathetic will help you expect and deal with the associated displays of wild behaviors that may occur. On the contrary, if you find out that there is no real necessity, you should negotiate a schedule more accurate to you. Anyway, you're paid to do the job in time and difficulty to hit deadlines should be taken into account when filling your pay-check. Out of schedule negotiations, surviving the deadline challenge is a matter of developing faster without losing the quality level required for a working product.
Don't follow a strict specification but more a result:
- "Less is more"
- Write the least amount of code
- Don't code anything in advance
- Write specific code
Minimal code
Obsess about not writing code. Focusing on writing as less code as you can benefit you greatly: probability of bug decreases, unwritten code doesn't have to be explained, small code bases are easier to read, change, refactor and debug. Being aware of the problem code solves and of the final result will help figure out what code matters enough to be written. Technology always evolves. Code is mutable or fully replaceable. Generic code should be handled by frameworks or libraries. If you find yourself starting to write generic code it's a sign you should search for a framework or library to do what your code should be doing. Only write if it doesn't already exist. Patching existing generic code is faster than creating new one. Specific code is fast to write and execute. All written product code should be specific aside from out necessity self developed frameworks and libraries.
Minimal design
To quickly shape what you have to code, split it in small parts using top-down. Start from the result and divide into smaller intermediary results. The danger is to split too much and end up with "broken parts". To avoid it, search for incomplete code parts. When a part doesn't work without code of the same decomposition level, merge it. You should always be able to delete and rewrite any part with limited effort. Don't plan for future developments or features.
Minimal time
Focus on finding what are the 20% programming tasks that give you 80% of the result. Come back coding the 80% remaining to achieve the final result after you've run through all of what you have to do once. That way you will actually know the time left to work on it. Don't spend time learning new technologies and implementations. If you don't know how to do it, don't do it. Set a limit to the time spent on a code part without achieving a result, after what skip to another part. Go for quick wins when you first see them. Still, keep your unexplored options for more peaceful times when you have the ability to build test projects and experiment.
At the end if the product isn't working you didn't meet your deadline. Achieve quality through simplicity. Leverage refactoring. Each time you have to go through an entire code part and change it, refactor it as needed. Deliver a simple system that works. It may naturally evolve toward a complex one over time, but it shouldn't be in your scope.
Are you using a particular approach / strategy when facing tough deadlines ? Share it here!
Originally written for my blog here
Top comments (1)
You meet deadlines by overestimating everything, and cutting fat from feature requests. ;)
At least that's been true for the past 10+ years ive been doing this.