It’s official, the latest version of WPSumo, 1.1.5, is up and ready for download. It’s also the first release after I took on this project, last year. As you may imagine this wasn’t an easy ride. As a matter of fact it was way more time consuming than I initially thought. Here are my thoughts on what are the upsides, the downsides and the overall feeling of reviving an old project.
Last year I was approached by two young entrepreneurs with an idea. It was about a thing that should be used online. An admin interface thing, or something like that. It looked promising and, after a few discussions, we decided this tool would be perfect for a WordPress backend. That’s how WPSumo was born.
We worked together for a few months, as a pretty productive team (me being involved on the marketing side only), until we reached what I call a minimum valuable product. The level at which you can safely take what you’ve built on the market. That was in May, last year. We launched, we had a tremendous good feedback, then things got a bit ugly. We halted development until everybody got clear about his role in this venture. At some point, I decided it’s better to step down from this train. Which is exactly what I did.
I won’t go into more details, because, in the end, all misunderstandings were solved. To make this (potentially long) story short, I ended up with the contact info of two exceptional entrepreneurs, a good relationship with each of them and a huge project to restart (almost) from scratch.
A few months later, these are the lessons I learned from this.
1. If It Has Potential, Jump On It
When one of the founders pitched to me to take over the project, I said “yes” almost without thinking. I knew what the project can do, I knew all the features, I knew the market and also had a relatively foggy idea about the potential maintenance costs (see below, the lesson about fiddling with somebody else’s code). So, instead of letting this slip into somebody else’s hands, I just jumped on it. And I have no regrets whatsoever.
WPSumo has a huge potential. I’m not saying this because I’m one of the founders. But because I’m using it every day on this very blog. Because I know what tremendous potential lies under the hood. But I’m getting a bit ahead of myself with this. For now, I’m just gonna stick with the satisfaction that I’m working on an incredibly cool project, which isn’t even at 5% of its potential.
2. Fiddling With Somebody Else’s Code Is A Dream
A bad dream, that is. A frigging nightmare. There are more than 50.000 lines of code in WPSumo (yes, believe it or not) and you need a little bit of an extra patience just to get a glimpse of what’s going on. Fortunately, the code was really clean. Unfortunately, it wasn’t documented at all. Fortunately, the overall architecture was pretty intuitive. Unfortunately, even if the architecture was intuitive, it was a pretty complex thing.
So, I guess you’re getting my point. The effort of just getting the grasp of what’s happening, from a programmer’s point of view, was just huge. The good side of this is that, like in any other nightmare, once you wake up (i.e. once you understand everything you need to know) the reality kicks in again. But I admit there were times when I got lost in my own forest of frightening WPSumo files.
3. Keep The Channels Open
When you’re continuing somebody else’s work, it’s fundamental to keep your channels open. All the channels, that is. Internal channels, as well as external channels. At times, my entire work on WPSumo was just a delicate balance between training the new designer (internal channel), responding to the sometimes aggressive comments on the forum (external channels) and getting all the info I didn’t know from the previous programmer.
It was more like a juggling performance, the circus type, if you want. I was lucky enough to get support from the initial programmer every time I needed (fortunately, just a couple of times) and also had a pretty patient and open designer. I really can’t imagine what would I have to do if my approach was different. Just trying to figure out by myself some of the things in the code would equal breaking through some security system. I guess. I never tried to break a security system so far.
4. Stick To The Plan
When I took on this project, I made two scenarios: one moderately negative, and one heavily negative. I didn’t have to make a positive scenario, because any other thing outside the two would have been positive. In case you wonder, I didn’t hit any of my scenarios. Which means things worked out pretty well.
From a long experience in managing online projects, I know that any imaginable project you start will take at least twice and a half the initially projected time. And it’s not about people. It’s about outside events which can heavily perturb your schedule. For instance, I had to spend almost a week recovering some hacked wordpress sites on my server. Damn hackers! They have no respect for other people schedules.
5. Small Bites Every Day
This one applies to pretty much any big project. But it gets extremely important when you take over somebody else’s toy because it gives you time to adapt and adjust to the other persons(s) styles and approaches. You simply cannot drink form the hose when you’re jumping into a new train, you first have to get a grip of your environment.
In my case, I had to seriously measure each and every day activity, along with the corresponding progress. I did this by journaling, one of the things that I not only enjoy doing, but I often use it like a tool to enhance my productivity. In hindsight, some of the logs looked pretty odd, like “Whew, I finally understood where, when and why the breadcrumb is called. “
Well, that was it. I’m going back to my 50.000 lines of code now. Enjoy