Yesterday, I posted about doing a hobby project so that you can learn more about various technologies. While I strongly advocate hobby projects, they have some problems too. Let us explore some of the dangers or pitfalls you may encounter. Much of this is based on my personal experience.
The foremost problem is a tendency to use the hobby project as a model to build a real-life application and try to manipulate the latter project’s requirements to fit your project architecture. For example, let us say that you have designed a new workflow framework. When you start a new project, you are deeply tempted to re-use your framework and therefore all the project requirements get filtered through this mentality – you want to see what all can fit into your framework and where you will need to make changes.
This is in opposition to what you should actually do in a project. Understand the requirements and choose the right framework and technology based on the needs. You can build things from scratch, buy third party solutions or re-use existing code, but whatever you do should not be pre-determined. Whenever you do a hobby project, you are always seduced by the future possibilities of the outcome of your experiments.
The second problem is seriously under-estimating the work necessary in real-life applications. In a hobby project, you can literally get away with murder. You can ignore all coding standards. You don’t have to put any error checking. Security, performance, robustness, usability, etc. which are essential concerns in a real application are rarely needed in a hobby project. So estimates based on hobby project models rarely contain the effort and time required for implementing these elementary needs.
Even worse, most people have a tough time understanding how much time they actually spent on a hobby project. It is very unlikely that anyone would actually record the times they spent and since the task is enjoyable, it seems to go by very fast. Also, when the hobby project uses a new language, design or framework (that has recently displaced an older one), the developers tend to exaggerate the ease of use of the new tool and downplay the drawbacks, because they want to continue using the new technology.
Hobby projects should be treated as no more than “code snippets”. They can be considered as sources of islands of re-usable code, ideas and logic. They are outcomes of your internal research and development. Artifacts of your hobby project are just tools in your larger toolbox of techniques and solutions.
When you start a new project, you should totally forget about the hobby projects you did. For that matter, you should stop thinking about the previous projects that you did. Just stop and listen to the customer. Take down his/her requirements and make sure that you understand exactly what he or she wants. Then you decide whether it is feasible to implement those requirements and if so, how.
During the “how”, resist the impulse to automatically reuse or discard something you did before. Find the technical solution that will most closely meet the requirements spelled out by the customer. Sometimes, you get to use your hobby project ideas. Sometimes, you don’t. But since your goal is to serve the customer, that doesn’t really matter.
Ultimately, that is the difference between the hobby project and a real project. The former is for you. The other is for someone else. Understanding the difference will allow you to avoid unnecessary problems when you move from one to the other.
[A legal note: There are many corporate and intellectual property issues surrounding the reuse of ideas and code from one project in another. To keep the discussion simple, I have ignored those issues, but please research them and talk to your manager about the legal compliance needs in your country and at your workplace.]
- Time Off, Vacations and Sabbaticals for Programmers
- The Long Game
- Good Math, Bad Math Explanations
- Project Gutenberg
- 2008 – The Best and Worst Books I Read