The Snowball Project
I enjoy writing technical project specifications with everything planned out. A while after starting to implement a new project, I might realize that I’ve forgotten a couple of things. Fast forward a bit more, the project starts turning into a something that keeps growing in complexity the more you work on it; a snowball project.
Everyone has snowball projects, and most of us hate them. The market research, groundwork and technical spec for the project have been done, the sysadmin is already installing packages to the company server, you’re telling others about your idea. Designers are working to finish those last pixels on the side of that one button that looks a bit “off”. Everything is rolling nicely.
You then start implementing to spec, setting up what is going to be the best setup of the framework of your choice so you can support everything in the spec, organizing files, models and creating the relationships between data entries.
At some point, you might bump into a problem relating to one of the features, which requires the help of another feature, but that feature is somewhere inaccessible from that first feature. You have to reconsider your application’s structure, and also consider whether to drop the feature completely or re-create the system hierarchy. You decide to write a simple workaround for the issue in order to access the required functionality from outside its own, isolated location.
Technical debt, no doubt about it. Quick fixes and workarounds to do things the way your tools aren’t supposed to do things are bad for you. Really.
You disregard the issue and feel happy that the new feature is working, and continue developing the other required things. Fast forward a bit more, you’ve done the same workarounds and fixes somewhere else, and don’t think much of it.
Your colleague suggests a new feature which utilizes existing functionality, and sounds like a rather simple feature to implement. You write some ideas on how to do it, and when you are just about to feel excited about implementing it, you realize that fuck!, all those workarounds and quick fixes change the behaviour of your original system in a way that the suggested feature would require changing multiple different functionality, because they’re all behaving in a slightly (or not so) different way than they were originally planned, but it worked for this project at the time.
Consider this pattern going on for several months, user given suggestions are coming in and you’re doing your best to satisfy everyone because you’re desperate to get the project working and being awesome.
Your project has turned from a small, beautiful snowflake, into a huge snowball rolling down a mountain destroying everything in its way. I can tell you that it’s pretty hard to stop that ball, or even changing its course a bit so it wouldn’t hit a ski’er on the way.
When I think about this more, I think back to reading Getting Real by 37signals, and where they tell you to say No to feature requests from customers. I think that’s good and I think it’s important for features to be iterated over a slightly longer period of time than an office coffee break.
What I try to do nowadays with my projects is that whenever I have an idea for a new feature or change into my project, what I feel is going to improve some part of the product. I write it down and forget about it. This way I can see if the same idea keeps popping up, and the more it pops up, the more it’s likely needed, and more likely be implemented.
Stop implementing everything, and only do the absolute essentials of your product for it to work. Let’s not build an electric self hitting hammer, and forget about electric knives, they’re going to kill you.
I’ve been part of a project for several months now, which was originally planned to be a very nice and simple product that allowed to do just what was necessary, and stayed to it’s vision.
This product wasn’t scoped properly, and everything was thought through and written down during meetings after the project had been started to be worked on. We quickly noticed that the original model didn’t work well enough, and what did we do? We kept building on top of the old product, changing functionality in some parts, adding a few new things here and there, the usual, right? No. Don’t do that.
The original vision and plan of your project was what led to the framework or platform of choice, and it doesn’t necessarily work for your new ideas. It doesn’t.
It breaks my heart to say I’m unable to do something, or that some things just aren’t possible during a project, because of how the system works. I like to believe we can do everything if we think things through carefully, and stick to the plan.
The original point of all this might have been lost somewhere, but in the end, I believe everyone should carefully think about what the main focus and vision of the product is, and stick to those until the very end, whether good or bad.
There are exceptions to every rule, and not every loosely scoped, constantly evolving project is going to turn out bad. It’s very hard to tell until you bump into one of the fore-mentioned problems.
Stick to your vision and goal. I know I’ll try my best.
Enjoy the read? Find me on Twitter.
