Saving a project
Recently, I have been brought in a project to help it go forward. Until then, I had never really realized how lucky I have been to work in the conditions I have. I hadn’t seen anything so terrible in over 5 years. I almost forgot such projects existed.
To summarize the situation:
- Like any good software project, it started from an idea
- A package was purchased as a base to build on
- Months of work had been spent to tweak the package to do what it had to
When I was called in, the project was almost done, it just needed a few fixes to be made and had to be launched the next day. When I saw the project, my basic reaction was not going to happen
. The code base was in a terrible shape. From a moderately clean software package (if you abstract from the fact that the only HTML tags they knew were those to build tables and had absolutely no knowledge of what a PHP notice is), it became a complete mess. Duplicate files with -old, -old-old, -old2, -test, -test2, -tst2. In very few case the base file was even used.
Obviously, there was no version control. None. No version control damages code. Not using version control is professional negligence in the 21st century (it was already severely blamed in the 20th).
Well, setting up version control is not too hard, and once it’s done, clean-up can begin. Effects can be felt in a matter of hours. The code base was really small once you removed all the duplicate code. It’s not such a big deal.
I think the worst part was they had no idea what was on the critical path to launch the site. When I ask what is left to be done, I expect a list of things, not an endless discussion about technical details (which happened not to be on the critical path). At that point, I could fully understand why the project had been going on for months without any significant progress: there was no global direction. No strategy between the great idea and the results. Just blind hacking on code hoping it would one day do what it had to. Worst is, they actually thought calling someone to hack-along would make it go faster.
The project suffered from bad management. That’s all. What can be done?
- Set up version control and issue tracking
- Spend some time to explain to your consultant what your goals are
- Identify your critical path
- Enter the tasks and prioritize them
- Start from the top of the list
- Clean up as you go
Results? The project stopped going backwards, code quality improved and it all became predictable. In less than a week, the projects can go further than they had in months. It’s really sad to see months of work getting lost when it could have been completed in a week. Spending an hour to set-up the environment and a few hours to clarify the vision is a really cheap investment.
The hardest part in getting this working is to kick start it. People hacking all night long hoping to get things done rarely accept that stopping for a few hours will save them months. Once the process started, it really takes a matter of hours for results to show up. However, you generally need a few weeks to get people to realize they are going nowhere.
If you find yourself making copies of files to test things out. If you can’t say in 30 seconds how what your working on fits in getting closer to success. If you thought your project would be done within a week for over a month. Ask for help or kill the project. Keeping it up that way, the project will never finish.
None of this is rocket science. It’s not even close to advanced research. It’s so deep down the foundations software engineering that courses barely mention it.
Software development should be predictable. If it’s not, your strategy is not clear enough for you to work in the first place. For any task you pick-up, it’s necessary to allocate a time budget for it. If you go overboard, it’s time to re-evaluate. If you can’t allocate a time budget, break it down into steps you can grasp. There are hundreds of way to solve each problem. Getting the best solution does not matter. Picking any plan will be better than no plan at all.