During my adventures in programming, I’ve been involved in many projects. Luckily, despite having made some mistakes, they’ve gone quite well. Here are a few of them, with tips on how to avoid making them yourself.
No version control
This is a pretty bad one! I’m glad I learned to use SVN at an early age… :)
Always use version control in your projects. Be it Git, SVN or even CVS, as long as you use something. It’ll help you avoid a thousand problems!
Here’s some of my posts about Git.
No plan
It may feel like just having a general idea (eg. “Hey, let’s make a forum!”) is alright, but it isn’t.
With no plan or roadmap, your project may easily derail into more and more new features, never actually getting anything finished.
Always try to create some kind of a plan that includes the features you want. Make it a Word document, or even better, put it in a tool like Trac or JIRA where you can easily track what you are working on. Not only will this give you a clearer image of what needs to be done, it can be useful to see what you have already accomplished so far.
No schedule
You may have a plan, but do you have a schedule?
Scheduling is as important as having a plan in the first place. Without a schedule, the project may easily keep going endlessly, with very little progress as nobody cares as there are no deadlines.
I have to admit that even now there’s a project I’m working on, without a proper schedule, which has been going on way longer than it should. I plan to fix that, though!
No release strategy
What’s a release strategy? This may not be the correct term, as I just made this up, but I think it’s quite descriptive: It includes how often you want to do releases and the steps involved in making a release.
The most basic requirement is to have a build/deployment script. A single command you, or anyone in your team, can run to completely build and deploy your application. This is important because a minor mistake can cause problems.
How often have you forgot to upload a file to the server when deploying? I bet the number is bigger than zero. Now think how many steps there is even in a simple deployment.. Sending files, setting up the database, maybe installing a default user…
How often you do releases can be important too. For example, in Scrum you develop in sprints and in the end of each sprint is a natural point to make a release with the features chosen for the sprint.
Tools such as Ant can be used to create build and deployment scripts.
Developmestruction
Not having a separate development and production environment is a recipe for disaster, especially if your application is being used in the real world at the same time as development is happening.
I’m a guilty of doing this, but luckily the applications weren’t being used by more than a handful of internal users.
Always perform development on separate machine(s) than the actual production deployment. This ensures the production system should stay relatively intact (unless your deployment screws up or you introduce more bugs).
Additionally, having a staging environment can be a good idea. This should usually be on similar hardware and software as production, as this will allow you to test-drive your code on a realistic setup before pushing it to production.
Not using Test Driven Development
This may not be the most critical problem, but I think it’s important nevertheless.
By having a good test-suite, you can ensure you don’t introduce regressions and that your code works at least as well as your tests were written.
For some reading on testing, check out unit testing essentials and How to make your code testable in this blog.
Post your tips/mistakes in the comments
If you have any tips/mistakes of your own, please share them in the comments. I’m still learning too, so they would be great additions to this list.