These words aren't only true for Alice in Wonderland. It seems there's an element of madness in every software development project.
Sales teams over-selling and underestimating development times, project managers getting lost in a project that's running behind schedule, developers complaining and clients expecting demos can make us team leaders feel like we're staring down the rabbit hole.
More often than not the difference between tumbling down to Wonderland or staying afloat comes down to one decision: Will we stop the mad tea party and plan properly, or will we be sucked into the frenzy and just start the project?
As someone who has made the mistake of simply starting a project, I will now dispense the best advice I have: DON’T.
As Alan Lakein so succinctly put it: “Failing to plan, is planning to fail”
Even when you have limited planning time in comparison to development and delivery time, you should still make the time to do planning. Even the most rudimentary notes are better than not having any at all.
Here are a few things I like to look at when my planning time is limited and I need maximum results.
- What mistakes did we make in previous projects?
- How did we fix this?
- Are all the team members aware of how the problem was approached in the past?
- What codes or modules can we salvage from previous projects?
- Code reuse is not just some fancy tactic employed by overzealous programming teachers. It saves time (if code is modularized and planned properly)
- Get a proper code generator
- Do we have samples or best practices documents?
- Very often, even junior developers can do certain tasks when examples are readily available. Even though Google is probably the best teacher in the world, it's impossible to find answers if you don't know what you're looking for.
- Identify difficult coding or modules and pre-assign them to experienced developers
- Very often just assigning the work to random developers saves time in creating the project plan, but wastes time during development. Be aware of upcoming difficult modules, interaction with other modules and the availability of strong developers.
- KNOW YOUR DEVELOPERS
- Knowing your developers will aid in assigning work. Do you need a developer that will generate brilliant code over a longer period or a developer that can complete the code within a time limit?
- Force developers to keep to the specification
- As developers we try to be brilliant (especially when trying to impress clients) at the expense of the deadline. If the client specified a Mini, don’t code a Porsche. Not only will it be more prone to bugs, but you will also have wasted time on extras. Chances are the nice-to-haves will come back with change requests that could take development over the allocated time. Stick to the basics, keep your deadline in mind and don't over-complicate.
- Plan technically
- If you don’t have any overall idea of what you want done on the system, stop. In my experience, if there aren't any technical guidelines, everyone will do as they please.
- Planning helps with code maintenance and stability
- Proper planning will enable a junior developer to maintain code that a senior developer developed. Senior developers are generally busy with new complex work. Without proper planning they are often required to maintain the code as well, leading to development bottlenecks.
- Identify future problems before you get there.
- If you have 10 days to code, take at least two to plan. Ensure what you want to do is what the writer of the specification intended. Changing your planning is easier than changing the code.
- Make notes of decisions taken in meetings.
- Very often a white board session is more than sufficient, as long as you take notes. Don't rely on your memory. It tends to fail.
These are just some of the basics that work for me when I need to achieve results within a limited time. Of course we would all prefer sufficient time to plan projects. However, considering all the variables, sometimes you just have to make things work by force of will. Proper planning will help you do so.
Remember, in this business the only constant is the one you code yourself.
