There Are No Small Projects

How often have your heard one of the following phrases:

This is a small project so we will just have to put something together and FAST.

Big projects need to be designed in a totally different manner than small ones.

This is just a campaign product / prototype which is used only once. We can write tests later if the scope of the project is increased.

These phrases and many others like them suggest that big software projects require different approach than small ones. Even though this is partially true, each one of those phrases contains a hidden agenda:

First, they propose that small projects should be put together as fast as possible. Second, they propose that good software development practices such as unit testing, integration testing and code reviews are not as important in a small project than they are in a big one.

I have noticed that this attitude is surprisingly common but that does not make it right. I personally believe that this approach is flawed for the following reasons:

Not all projects start as big ones. In these cases the scope of the project is extended during the project. If you have separate practices for small and big projects, you will end up noticing that you have been following the wrong practices. This can be a critical mistake since you might have to go back to the code you have written earlier and adapt it to match the demands of the big projects This costs both time and money and your customer is often not willing to pay for it. And guess what? The customer is absolutely right. You made the mistake. You will have to pay the prize.

Small projects are important to your customer. It does not really matter whether the project is described to you as a temporary or as a permanent solution. The fact is that you cannot know if something you delivered is going to be a part of something bigger in the future. The only ethical thing to do is to ensure that you finish all projects by following good software development practices. This way it should be easier to extend the software you delivered if needed.

Remember that even if the project does not sound big and important project to you, it might be a huge investment to your customer and it should be treated as such. If you can ship the finished product with your name and contact details, you have most likely given the customer the respect he deserves.

Changing peoples attitude is hard. If your developers have learned that it is acceptable to cut corners in small projects, you are going to have a hard time to change their attitude when you finally get that big project you have been dying to get. The reason why this is hard is that you will have force your developers out of their comfort zones and people tend to resist changes like this. That is why the best thing you can do for your business is to follow good software development practices in every project. It will save both your nerves and your money.

Keeping your expectations high has also got a one additional benefit: It will make the recruitment process much easier for you. As long as you mention your high expectations during job interviews, it will be fairly easy to see who is not a good addition to your team.

I have now given you three reasons why you should treat each project in the same way. Remember that it is perfectly fine to decline projects which seem too small for you. However, if you decide take a project (either big or small), you should always follow the same principles and aim for delivering software which you can be proud of. If you are a real professional, anything less than this is simply unacceptable.

2 comments… add one
  • dan carter Oct 22, 2015 @ 3:14

    related to - Small projects are important to your customer.

    Even though the project is small, it still needs to work. I have never delivered a project, not matter how small that has just worked first time for all use cases. Not testing a small project and waiting until development is complete and it's ready to deliver will still deliver extra development costs. Going back and fixing things after completion is always going to be more expensive than fixing things as you go along. It's a small project, the fix might not take that long in absolute terms, but as a percentage of overall development it will be expensive.

    • Petri Oct 23, 2015 @ 21:58

      I agree.

      Also, often customers test us by using a small project. This way they don't risk a lot if the project fails. However, if the project is considered a success, we might get bigger projects and this is when the problems begin (assuming that we just hacked the small project together).

      The problem is that our customer expect us to maintain the same pace and this is not possible in a big project. We will either have to write the required tests before we commit a feature to the used version control system or fix the bugs later. In any case, we cannot just crunch code as fast as we did during the small project.

      If we don't communicate this to our customer, the odds are that he/she won't be very satisfied with our services. Also, it can be hard to communicate this because we have to admit that we didn't do everything by the book during the small project.

Leave a Reply