In this post I want to look back on many projects I started, most of which were canceled in an early stage. Anyway, I think the time is right and the decision is clear to (re-)start Cubenet, my pet project since 2005, and assign it the priority it deserves.
I’ve always had my projects, mostly programming projects. If I don’t count all those small one page programs, I may have started about 300 of them, but only finished about 40. And it’s clear that no project is ever really finished, I just got them to a point where it’s close to completion. Most got canceled because I lost interest.
In 2005 I started Cubenet, a software concept for information handling, but right now, there’s nothing to show. You might count this as one of the 260 failed projects, but that’s not correct. I never lost interest, but I never had the time to work on it. Or maybe, I never took the time.
There’s an important invariant concerning time: You never have enough of it, there’s always much more to do than you ever could. So you do the most important things first, and the others afterwards. Cubenet never had the highest priority, so it never got the time it needed. I never had enough trust into this to assign a higher priority to it. So why is that?
First of all, as I said in the introduction, most of my projects „fail“. I used to think of this as a personal weakness, and so I was afraid to put large efforts into something that I would eventually cancel. Of course, this is exactly the wrong way round, but I didn’t recognize. If my projects fail because I’m not committed to them, then I won’t do any better if this leads me to even less commitment.
Second, I used to start projects that I could never finish anyway. When I was 5, I insisted to file a patent for a chewing gum factory that I designed on paper. Age 6, I dug a hole in the ground because I wanted to build a subways station. My town only had buses, and I thought subways were much cooler than buses, so someone would have to start digging. Then, aged 9 or 10, I wanted to build the robot from the famous Johnny 5 movie.
None of this was feasible, but it’s no shame to talk about it, since I was a child. But when does this end? How do I know if I’m still a child with childish plans? When I was 13 or 14, when there were no MP3 players on the market, my father and I build one based on a do it your self kit, and I thought it would be cool to mass produce it, add a modem to it so it could connect to the Internet, and let people download music from a server, letting them pay for the music, and all this without a PC. This turned into a billion dollar marked some years later, but at that point, it seemed like another of my childish fantasies. I still mistrust my own ideas, especially when they are big and ambitious, which describes Cubenet very well.
Third, when I don’t consider my former projects, but just Cubenet on its own, there are so many reasons why it could fail. Failing is related to not getting finished, and the complexity of my concept clearly indicates that it is too big, that I could never finish every part of it on my own. So why even start?
While every project starts small, some aim for the small, and some for the big. Often I get the advise to aim for a small goal, along with some anecdotal stories about projects that tried to reach a small goal and evolved beyond that, to finally become something big. In my case, I’m bound to ignore that advise, because of my central belief about practical computer science: Programming has grown in complexity because the whole area of software development started out small, without the great picture in mind. Now, if you want to build a small thing, you have to deal with a dozen of layers, which evolved over 50 years. This could be done better if it was planned from the beginning. Cubenet is, in its core, an attempt to do it better, by aiming for the big goal and approaching it directly. So the project has a great goal by its very definition, and there are many who think it must therefor fail by definition.
Just doing it
I’ve finally come to my senses. Every project, no matter how big and how many persons it will take to complete, has to be started by someone. And now, that’s me, the crazy kid, grown up, old enough to make decisions, while not really wise enough to implement it all. But if you have a thousand crazy children like I was, digging in the ground, they will eventually build a subway station. Maybe they lack the skills at first, but after some years of work, they will have them. I don’t know the real source, because it’s been cited too often, but programming is a „wicked problem“, one that you only understand while you try to solve it. This is widely agreed upon, but opinions differ on whether this legitimates a restart from scratch, or if it must be tackled by incremental changes and refactoring. I’m not sure about it, but if there is a solution, I’m the one who sets out to find it, hoping someone might join along the way.
A scheduling trade-off
For Cubenet to succeed, I need not only overcome the many obstacles of software development, I also must overcome my intrinsic problem of time scheduling. That is, I must assign a priority to Cubenet, high enough to actually being worked on. With a classical scheduling, only the most important task is worked on, until it is finished, so the next important one may follow. For a long time project like Cubenet, this would be fatal: I would drop out of my university rather quickly, but eventually I would die of starvation because cooking meals has a lower priority. There has to be a compromise, like this one:
I’ll work on Cubenet as much as I can afford, and I think I must accept that other aspects might suffer, like my studies, free time, social life, etc. But if I define a limit on how much those may suffer, this gets manageable. This is the only way it can be done, and it might get easier with synergistic effects. Like integrating Cubenet into my studies. I failed at this at my former university, the Hochschule Harz, because I studied the wrong branch of computer science. Now at the Technische Universität Braunschweig, I’m at the right place, and there may be ways to bring it all together. If I’m forced to succeed, I will somehow succeed.
Linking it to people and obligations
There’s another advise to start a project, and not let it fall aside: Tell everyone about it. Tell about it, until they start asking about the progress, which somehow motivates. This is a common hint for people who want to stop smoking, but it applies elsewhere.
But sometimes motivation is not the problem, but justification: Is it right to spend time on Cubenet right now? Am I supposed to do something else instead? Yes, I am, but as soon as Cubenet is officially related to my studies, or science, or a job, I’m supposed to work on it, one problem solved. On the other hand, linking a pet project to a proper obligation bears the risk of control loss. Nobody will force me to do exactly what I already wanted to do, so if I need some force, it may come along with a shift of focus. I’m already afraid of it, but I have to face it. It’s no deal if Cubenet turns into the wrong direction at first, if I always keep enough control to change it afterwards. Licensing it under a copy left license enforces this, because everybody may develop it in any direction, which includes myself. Every study, research project or contract has an end, and with a copyleft license and version control, projects can evolve or stand still, but they can never fall back.
So now I’ve talked myself into taking this project serious, into writing about it and justifying my decisions. Now the actions must follow. To kick start this project, I’ve installed a Redmine workspace at http://lenaschimmel.de/redmine/ and populated it with a huge mass of old notes, and a git repository for source code control. This is not only a place for old texts to get even older, it will be the central for cooperative working on the project itself.
If you feel like you want to be a part of my monster pet project, head over there and get yourself an account. Or just contact me with whatever you think about it.