Depending on what type of business you are active in, you either often start new projects from scratch, or not at all. In the first case you are more involved with proto-typing and experimental work whereas in the latter you are working on a product that needs to be supported, upgraded and maintained.
Starting code from scratch has a lot of benifits mostly caused by the freedom that comes with it. You are not bound to any choices made in the past, you are free to choose your own way of working that you are used to and feel comfortable with. There is also no legacy code that you need to understand and may be badly documented.
But what I want to address in this blog post is all the side-setup that is required when setting up a new project, and how important it is. Should it all be done from the start? Or can you delay it until it really becomes important?
The processes I am talking about are those of setting up an continious integration build, automated testing, tracking code coverage, doing code reviews, having decent coding guidelines, having a release management system, and such.
Whether or not you need al of this from the start depends on what kind of application you are writing, how big the team is, and what the expected future of it will be. You can imagine that there is a big difference between a small tool you are writing by yourself with the only purpose to make a certain process a bit more efficient and easier, compared to a new commercial piece of software being developed by a team of 10 people that needs to be maintained for years to come.
If you are working on your own, there are a couple of things you don’t need to make explicit or that you just can’t do. These things include setting up coding conventions, since you are working by yourself, there is no point in doing this. Just write code as you like it. Setting up a code review is impossible as there is nobody else to review your code.
If you are working on a small application, script or prototype that acts as throw-away code, then you may not want to spend too much time on any of this. In the end the goal of all of these processes is to improve the quality of the software and make it easier to maintain. But since the code base is either very limited, does only a few small things or is not meant to be kept anyway, there is little point in spending effort and time to setup it all up, especially if the time you need to create the application is less then the time requires to setup all the processes.
If you are however working on a commercial application with a big team, you should spend in setting up all these processes. The question is whether this is something you should do at the beginning, or whether you can delay it. I have worked together with developers who insisted on getting a first release out before spending any time of it. But in my opinion this is the wrong approach. I have listed my opinion about these topics, and when they must be setup in the list below:
- Coding Conventions: it is impossible to write a single line of code, if not everyone is on the same page regarding coding style. If you do not do this from the beginning you will inevitably end up with a mix and match of styles, making the code very confusing. To fix this later, is nasty as it makes tracking changes in the code harder due to formatting changes.
- Code Reviews: all code that is to be merged into the master branch must be reviewed. This means that you can only start merging code if this process is created. The reason is similar as with the coding conventions, if you do not do this, then people lose track of changes, are unaware of the current state of the code, and the code may not be as clean/readable as it could have been.
- Continuous Integration: this belongs together with automated testing, tracking code coverage and any other check you want to do on code. This should be working from the beginning as well such that it can flag any errors early one. The same as with code reviews, no code should be merged until this process is completely setup. This will prevent you from merging in code that is not sufficiently tested, catch test failures and prevent other bad code from entering your code base.
- Release Management: this is the only thing that can wait until you have to release your software. Doing it automatically can even be delayed longer, but at this time you should already have an idea on how often you want to release, how you will parallel work on a new release and bug fixes, and other procedures.
It is essential to start your project the right way, otherwise you already start with a certain level or technical debt. Starting a new project is a great opportunity to start with a clean sheet, don’t waist it by trying to go as fast as possible because it will turn in a mess. It may even become so bad that at some point your only option is to start from scratch again.