Things move fast in software development today, especially if you're with a company that has any amount agility. While speedy results are important, you should take the extra time necessary to start off on good footing and maintain that footing throughout the development of the system.
The start of a new project can be an exciting time. There's unlimited potential and there's the chance to use new tools and techniques that may not fit into existing projects. There's also the opportunity to keep things clean from the get-go. This can be challenging however, particularly when you're evaluating libraries and patterns you may want to use in the software. Your team will raring to go and everyone may start coding away without a solid plan in place for the overall structure of the system. Add to that the pressure from the client (or management) to see results or to perform rapid prototyping to gather feedback and you may start down a path that's hard to steer away from.
While the initial planning stages can slow things down, they're well worth it in the long run. Every developer without exception regrets something they've done in the past that causes pain well into the future. The earliest planning stages can often have the most serious repercussions, such as the overall structure and organization of the software. Something that may seem minor at the time, like namespace decisions, library separation, or a data schema could end up bothering you and your teammates for years. Personally I'd give a lot to go back on some projects and spend a couple extra days hashing out some decisions rather than plowing ahead to make immediate progress.
Here are three things that can help you start your project on the right foot and keep it that way for the entire development cycle.
1. Version Control
The start of a project is the first chance to keep everything tight. You should take your time and really think on every function that your system will be expected to perform. Once you get the initial project layout determined, you should immediately place the project under version control. Put it into version control as early as you possibly can and get your team connected. This gives you the ability to perform discovery on libraries and techniques with no consequence. You want to test out a library? Load it up and create some functions around it. If it doesn't work out, or even if it does and you can do better, simply revert your solution back to a clean version and proceed.
2. Unit Tests
Unit tests are a great way to promote clean and maintainable code. They can help you find problems early on and make tracing bugs easier later on. They can be helpful in driving out requirements and aiding in the early planning / organization stages as well. Adding in unit tests after a system has already been built is difficult however. It's too easy to miss test cases and you end up writing your tests with bias since you've already implemented the functions. That being the case, the start of the project is the time to get your team dedicated to unit testing.
Code refactoring is the process of changing existing code without changing its function. This is commonly done to reduce complexity, be more concise, improve readability, or eliminate repetition. In my opinion this is the most important task when it comes to keeping a system maintainable and extensible. It's also the most difficult. It's so easy to code your way into a situation that requires refactoring and decide that you'll definitely come back to it later. Except you probably won't. You need to nip these in the bud as they present themselves. Doing so will make all of the difference in the lifetime of your application.
Build for the other guy or girl
When you're building a system, try and think about a stranger coming in a year after the project has been live and needing to enhance some functionality. Will it be obvious where that person should look to find key pieces of the code? What if they need to move the application to a new server environment, did you build the software to have a single area for configuration constants or are they sprinkled around the code? Are they hard coded in classes? Is the latest code always under version control in a manner that lets anyone check out a working solution at any time?
Maybe you don't care about this other person's plight. After all, that's their problem and that's what they are paid to sort out. But here's the thing, you're that other person. If you move on to another project and have to come back to your own code a year later and it's a mess, you're going to be just as lost as the stranger, and probably just as upset.