Tech IT Easy

In my short career, I’ve been exposed to maybe four projects, which have experienced development hell, which is a term used in creative projects that never seem to leave development, for either internal reasons (e.g. bad management or work ethic) or external reasons (e.g. lack of resources). One of my “hell projects” was my thesis and I broke out of it. Three were startups, of which two failed.

Ever since then, I’ve been very careful about avoiding these types of situations and try to follow certain informal guidelines to do so. They are mostly based on instinct, not so much on set principles that come out of, for instance, software development and general project management, both disciplines I have tremendous respect for and still have a lot to learn from.

Here they are:

1. Avoid secrecy: I think this is a shared characteristic of all four of my projects. If you lock yourself into a room, literarily or metaphorically, you risk going into a surreal state of development, which is unaligned with how the market develops or how your own funding needs evolve for that matter, which is also market-determined. Outside input will expose you to much more data, force you to keep improving your product, and to be practical in doing so.
2. Build on past experience: I think this can be interpreted as three things:
   • One, avoiding secrecy in the sense that you involve external people and use their experience.
   • Two, working on projects that incrementally improve on projects you worked on before / that already exist, drastically decreases complexity and increases chances of success. Not so, focussing on radical innovation, which also has to pass the hurdle of finding a market.
   • Three, focussing on quick prototyping means that you have testable experiences within a project to base future development on.
3. Be a stubborn bastard: I only take this from my own thesis, which was perhaps the worst experience in my life, if I didn’t remember that there are far worse things. For instance, my first adult job required me to bike over 80 km everyday for more than 4 months, in rain, wind, and across mountains, sometimes at 4 in the morning. But it paid me more than most 18 year olds as well, I saved money on public transport, and learned to finish what I started, no matter how long it takes… most things worthwhile are hard work and mean that you have to cling to that belief even if most people around you don’t.
4. Set measurable milestones and monitor, monitor, monitor: One of the best bosses I’ve ever had, was the age that I am now, told me exactly what he wanted done by the end of the assignment, what he wanted on a day-to-day basis, and talked to me when things went off track. When they didn’t, he left me alone. Another boss of mine told me nothing, set an abstract goal, kept throwing new projects on my back even when the last one was only beginning, and blamed me when everything failed. Needless to say that I try to stick to the first method when managing myself and others.
5. Keep complexity down: I’m currently involved in restarting a business that I was previously engaged in (one of my failures), and which is drastically more simple. While before, we would have had to (re-)invent at least three wheels and restricted our market in the process, we now have to invent one and have a market so huge that it’s scary. I know that point 3 was to be stubborn, but being stubborn + choosing feasible projects = a twice as rewarding experience.

That’s it! As I’m sure this is a problem that plagues everyone once in a while, I’m very curious how you avoid development hell. Let us know in a comment!

Vincent