Deadlines: 9 Tips To Improve Your Dev Team’s Chances

Do you sometimes scratch your head and ask WTF (I said "frick" in my head. Really.) when projects suddenly fall apart? Suppose you're a project manager. Your team is steadily moving along on a project. There is no indication that anything is wrong, and your team says they're on target to hit their deadlines. Then, all of the sudden, things seem to be out of control with the application, and there seems to be no explanation as to why everything is screwy. Everyone begins to panic towards the end. Features that should have been completed a long time ago still aren't working, developers are sweating profusely, and throwing up in the corner periodically. If your development team seems to have a hard time estimating tasks or consistently misses deadlines, then this article is for you.

Organization, consistency, and having realistic expectations are key to predicting more accurate timelines and avoiding unexpected last minute failures.

Read on.

1. Schedule time for maintenance tasks!

If you are managing a team of developers and you have never been a developer yourself, then you should take note of this one. First, here's what I mean by "maintenance task". A maintenance task is anything that doesn't fall under billable production time. This could include any of the items on this list. These things need to happen, and if you don't schedule time for them, then you and your dev team will pay the price by missing deadlines, working OT, and getting divorced. If you're trying to squeeze 95% billable time out of your production team, then you need to adjust your expectations.

2. Cross train!

This is especially important when you have a relatively small team of developers. The developers on your team need to be able to jump from project to project, client side to server side without a hiccup. If you have a developer on your team who isn't flexible and willing to learn different technologies, fire him.

If your small agency has a team of 5 or 6 developers, and only one of them knows anything about client side development, then this is a problem. You can solve it by providing training materials and/or scheduling time for cross-training sessions.

3. Keep your code clean!

If you are a developer, you may well know that working with another developer's messy or unconventional code is not fun. In fact, it can be a real time-suck. Messy code can kill the performance of your application, and adding new features can be a nightmare. There are big advantages in keeping your code organized and clean, and every team should take steps to make sure everyone is working together to write cleaner code. Cleaner code means it will be easier (and cheaper!) to maintain. It also reduces the chances of introducing bugs when adding new features.

4. Build libraries of reusable code!

Developers should always be thinking about how to structure their code in a way that will allow that code to be reused down the road. While this may seem obvious, in practice, it may be hard to implement. There are at least 2 obstacles that prevent this tip from being an effective way to improve efficiency. First, it requires everyone on the development team to work together, plan, and communicate with each other. Goals and roadmaps should be established, and then everyone must follow through, long term, and contribute. Second, if your team works in a sweat shop type environment where there is never enough time, and there are always 5 deadlines looming around the corner, then it may be difficult to convince your operations guy to allocate time for developers to put together a strategy. If you're the guy who does scheduling, don't fall into that trap. You may think your keeping everyone on track by standing over them with a whip, but in reality, a lot of time could be saved if the development team had libraries of code and components they could use.

5. Be consistent! Follow common coding conventions and guidelines.

When you work with a team of guys who use similar coding conventions, it's easy to swap developers between projects without a lot of painful rework. Adobe has put together some guidelines about how you should write your Actionscript code. This document is intended for those who wish to contribute to the development of the Flex framework, but it's a great resource if you want to establish some consistency in how your team writes their code. No more pointless arguments about whether the curly braces should be on the next line, or what the naming conventions should be for packages/classes/constants/etc. If you don't have a neat document like this one, create some simple guidelines for your team to follow. It will pay off in the end.

If your team is using an IDE that supports auto-formatting, then that can also help keep things consistent. FDT is an excellent development environment for Actionscript dev, and it has a nifty auto-formatting feature. You can predefine how you'd like it to format your code, then just hit Control+Shift+F, and bam, everything is nice and neat.

6. Code reviews!

What a waste of time, you say? Everyone should work in complete isolation of each other, you say? Wrong. If your team isn't doing some sort of semi-formal code reviews, then there is a good chance that a large portion of the code that is written is never seen by anyone except the author. This is bad on many levels.

Code reviews are a critical part of the consistent growth of a development team. They offer opportunities for developers to get feedback on their work, and more importantly, they give developers the opportunity to share what they've learned with the team. Developers love to learn, and they love to share what they've learned with others. If you allow time periodically for this time of knowledge transfer, it will do wonders for the morale of the team and, ultimately, the success of the software they develop.

7. Use source control!

Every development team should be taking advantage of source control. There are many good source control systems available. Subversion is an example of a free, open-source version control system. It is widely used by the open source community. While it may take a little time for a team to get up to speed on how to use a source control system, it will be well worth the time invested to learn it.

Some benefits of using Subversion include:

• allows developers to keep a revision history of the changes made to the code, including developer comments about changes
• the revision history includes information about who made the changes and when, so if someone is screwing up the code base, you'll know who to blame
• it provides the ability to roll back to previous releases
• Subversion clients such as TortoiseSVN provide tools to make side by side comparisons of revisions to a file. For example, if two developers make changes to the same file, these changes can easily be merged together
• allows developers in different locations to collaborate and actively work on the same code base

8. Research and Development!

There is a reason that Google consistently churns out innovative products. Sure, they have extra money to dump into R&D, but much of their success comes from their "20-percent time." Google allows their "engineers “20-percent time” so that they’re free to work on what they’re really passionate about. Google Suggest, AdSense for Content and Orkut are among the many products of this perk."

Not only can this be a great creative outlet for your team members, but it will also allow them time to continually build on the skills that they need for production. If your team members are forced into constantly having to train themselves in order to complete the next task, not only will it drain them and the team's morale, it will also be harder to predict how long it will take to finish a given task.

9. Recognize the 90-90 Rule!

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.

The 90-90 rule pokes fun at the fact that some developers tend to oversimplify or underestimate the work that needs to be done. This is a tough one, especially if you have PMs who can't cross-check the estimates with their own development experience. I've worked with some developers who are quick to jump up and throw out some numbers when asked for an estimate. Their estimates are not impossible to achieve, but they fail to realize that unexpected issues ALWAYS arise and cause delays.

Aside from preparing your team via training and R&D, I can think of 3 ways to prevent this from happening:

1. Pad the numbers and pray.
2. Go through a very thorough discovery and planning process so that all of the possible roadblocks can be identified.
3. Instead of having a huge requirements document and details specs of what has to happen by X date that's 3 months away, you could adopt principles of agile software development (I'll detail this in a future post).

Each one of these tips really deserves it's own blog post, but for the sake of my time and yours, I'll leave it here. While there are probably hundreds of things that could be causing delays and missed deadlines, here's the reality of the situation: your team could be more productive, more predictable, more efficient, and simply enjoy coming to work if you follow these guidelines.

If you read through this whole post, and didn't find any of this useful, or you tried them and you're still missing deadlines, you might need more help.