This is a second chapter in a series – the first chapter is “Starting the Co-op.”
Following that first successful cycle, we decided to wait through New Year’s, 2007 to open a new cycle. This gave me a nice, solid month to work away at the site, polishing away the last few bugs, and generally getting things locked down for production.
I settled in, the second week in December of ’06, to start patching up these past few bugs. What I quickly found, however, was that this software was nigh-unpatchable. Every time I’d try to add or remove a feature, everything would break. I don’t mean a couple error messages would show up – I mean the page would simply not appear. Locked up. No errors in the log. Dead.
The Oklahoma software, you see, was built over several years, by people who were not professional programmers. They were students and foodies – and they did admirable work. Yet, there was not a consistent design standard or vision, and the result of that was a big ball of “spaghetti code” – code that’s great when the sauce is on it, but is awful if you need to change out specific noodles. (So that metaphor doesn’t work right. Oh well.) Plus, even they still considered the whole package “beta” – and not the “works really well Google-style” beta, either.
On top of that, the OK software had features we didn’t need to support. Their system is state-wide, and involves a whole transportation network. This means that farmers can drop off on one side of the state, volunteers then take apart the deliveries and load them onto trucks destined for other cities, and finally a day later everybody picks up their assembled orders from all over Oklahoma. Cool? Yes. But even then, we knew we weren’t going in that direction. We’re the West Michigan Co-op – not the Lower Peninsula Co-op. Not the All-of-Michigan Co-op.
This turned out to be a huge part of their software – drop-off points, pick-up points, destination preferences, etc. And that code was intertwined in every single file of the site – again, spaghetti code. On top of that, some of the source files were nearly a thousand lines of code individually! Not maintainable, and thus not sustainable.
It took me about a day of futile busywork on this jumble before I finally threw the code in the trash can. Bear in mind – we had already used this software. It kinda worked. And it was “finished.” Here I was, ready to start again, from scratch. What was I doing?
At the time, I had recently stumbled upon a PHP framework called CakePHP. If you’re a web programmer, you may have heard of it, or the framework it’s modeled after, Ruby on Rails. If you’re not a programmer, I’ll just say this: CakePHP is essentially a library of code that you can build websites with. It’s designed to interact with databases similar to the one we had built with the Oklahoma software. It’s also designed for rapid development – meaning you can build an interactive site fast.
I didn’t tell any of the other founders that I had done this – in fact, I left the old code up on the server just in case I couldn’t get it done. Farmers need the site to still be up anyway, just so they could update their product information. But at home, on my local server, I was crunching away, ten hours a day, rebuilding the Co-op software, piece by piece. I worked a solid three weeks on the new software.
It was definitely a stressful time. But at the end of the three weeks, I had 95% of what the Co-op needed already implemented. So I took the plunge, and announced to Jerry, Gail, and Tom that I had killed the old code and started from scratch using this framework as a base. I published the site – which to the naked eye, looked exactly the same. Ordering wasn’t ready to go yet, but you could log in, farmers could maintain their product listings, and best of all, the back-end code was organized and solid. In fact, I even had RSS feeds of new products – something the old code wouldn’t have been able to do, probably ever, without writing a whole RSS library and SQL query from scratch.
By the time we opened for ordering in January of ’07, the last few features had been implemented. There were certainly a few bugs that first cycle with the new code, but over all, the ordering cycle went far smoother. Compared to the previous software, this was definitely less capable overall. Personally, this was a blessing, because it actually did what it was supposed to do – and nothing more. There weren’t any confusing options we weren’t using getting in the way. Best of all, of course, was that I had nice, stable, organized code to build on.
I really don’t believe that I touched the code for the rest of January. It was exactly the same code in February – which was my test to make sure I hadn’t screwed up some strange time-related function. The January and February cycles went pretty well, considering the volume – which was rapidly increasing. I think we broke $1000 that February.
Jerry designed some very nice looking PDF invoices, which we quickly adopted. I’ve found on numerous occasions that it’s practically impossible to get different browsers on different systems to print the same HTML page the same way. Why this is, I have no idea, but that’s how it is. (It can be done, but it takes an incredible about of debugging. Generating a PDF, on the other hand, is trivial by comparison.)
Since then there have been lots and lots of features added to the software – product photos via Flickr, forums, a product search API, and lots of minor changes – but getting these new features has never caused a significant break in the software or restructuring. I’ve also open-sourced the code, to help others like the Purple Porch Co-op in South Bend, Indiana get started. Like Oklahoma, I want to get others building their own local, online marketplaces.
The story will continue in “Structuring the Co-op.”