"White hamster" projects

Since the company I worked in decided to lay me off (together with several other people), now is a good time to review some of my experience and try to learn from it something important...

So, what is a "white hamster" project? Before I answer the question, let me tell you an old joke.

A man enters a pet store, pulling behind him on a leash a huge, dangerously looking polar bear.
- Hey, what's the deal with this bear?! - asks storekeeper.
- Oh, I just want to talk to the guy who sold me a year ago a cute little white hamster...


White hamster project (I invented the term for my own usage - but everyone is welcome to use it) is a project that starts as an innocuous small tool or utility, but soon unexpectedly grows into something large. It happened to me a couple of times: I've got a request to write a small utility. Because it was small and easy, I've got a couple of days to do it - and I did it in a very simple and straightforward way. Then a couple of requests for small additional features arrived - then two or three small enhancements - then a special case popped up... Each time I spent a minimal time on the change, because, after all, it was still a simple tool. Half a year later I was dealing with a monster which had a complex web UI, maze-like control flow, and was a nightmare to work with, because of its design - or, to be more precise, a lack of one.

Of course, the best solution would be to do everything right from the very beginning - but quite often it's hard to justify the necessity of spending much more resources on a very simple program which can be coded in just a couple of hours. For example, one of my "white hamster projects" started with a request for a web form where the user enters five or six values and the tool populates HTML template with the values entered and saves the result as a new file. A task for two or three hours of programming - and who could know that it would turn into such a beast...

It's very important to know how to tell a real white hamster from a polar bear cub. Most times it's impossible to do in the very beginning - but, once the developer receives first requests for new features and enhancements, there are certain signs which can help recognize a potential danger. Here are some of those signs:

• Surprisingly high attention to the project.Sometimes it happens that the management misrepresents (and/or misunderstands) the scope and significance of the project. So, if, what was initially described to you as a simple utility, becomes all of a sudden a topic of a heated discussion, beware!


• Request for a new feature which seems almost unrelated to the existing ones. For example, after doing the template population tool I was asked to make the tool save some details about the template and the data in the database.


• Discovery of "special cases".In my situation, I was told soon after I released the first version of the tool that one specific type of data requires a different template. I've implemented it blindly. At the end of the project I had eight or ten different types of templates which were selected using unbelievably entangled logic. That's the danger of special cases - you may start with just one, but inevitably you will end with a bunch. Usually the special cases are, in fact, pieces of some business logic which was not properly identified at the analysis time.


• Urge to use some "hack"That's pretty basic, but still... If, while implementing a new feature, you feel an urge to use some trick to fit it into the existing application structure, it's a sign that something is wrong.


• Enhancement requires a significant change in the control flow. For example, in web-based applications, this might be a necessity for a new page, or necessity to divide the flow into two separate branches. This is a sign that the complexity of the project grows beyond original expectations, and it's time to re-evaluate the project.

So, what should be done once the potential bear cub is discovered? Of course, the project design should be changed with a high potential complexity in mind. But - and this is even more important - in this situation one should investigate the business reasons for this project. In my experience, almost always "white hamster projects" are, in fact, attempts to automate some business process. Very often these attempts happen without fully understanding what is being done. In my case everyone - the business users, my manager, and me - believed that the users just need a simple tool to help them create HTML snippets. What they actually needed was a system for working with a new type of web ads. At last I understood it - but it was too late; my cute little hamster had already turned into an ugly beast.

Technorati tags: software design