Last night we were treated to Silvan and Stefans whirlwind history of tilllate.com, delivered to a packed webtuesday - thanks to search.ch for hosting and apologies to those that got stuck out in the corridor - a search for bigger meeting spaces is in progress.
The talk - described here translates (loosely) to “tilllate.com: From 0.1 to 30 Servers”;
With 100 million pageviews and 1 million visitors a month, tilllate.com is one of the biggest web platforms in Switzerland. The site currently comprises 60′000 lines of code and 430 database tables, served by a cluster of over 30 servers. Software and infrastructure is the responsibility of a team of 5 developers and engineers. Stefan (System Engineer) and [Silvan] (CTO) present their technical experiences in building tilllate from scratch.
It was both insightful and entertaining, backed with confessions and tales of past disasters. Something about the tilllate story probably rings true for most of the “LAMP generation”.
In redux: tilllate.com began is a “just for fun” project, while the founders were students. Self taught, starting from “View > Source” and graduating to PHP, the first version, released in Y2K was ~40 scripts on a shared host. You know the sort - violation of every software “best practice” such as separation of concerns - SQL embedded in HTML, ripe for injection, XSS and all that. But it worked and the site grew in popularity…
…leading up to today, six years later, where they employ more than 30 full-time staff, are storing ~1.5 terrabytes of user-uploaded images, are busy expanding the tilllate network into the rest of Europe, maintain a codebase that is approaching best practices and seem to be thoroughly enjoying themselves. It’s almost a “rags to riches” story, powered by LAMP and a bright team who took on the problems as they found them.
But a final Catch-22 came up with Silvan’s last slide - “Looking back, what could we have done better?”, under which one point was to the effect of “Employ better development practices, OOP etc.”. To which Lukas Smith (who’s now a citizen of Zürich) replied - “If you had, you probably would have failed - months developing something J2EE-a-like which, when released, falls flat on the users and is too rigid to incorporate their feedback”.
Seen another way, PHP’s shallow “get online” learning curve and “hackability” allowed tilllate’s founders to launch an interactive site at a time in their lives where they had a passion for the site’s subject. Had they instead waited to become Computer Science Majors and gathered a few years of cubicle development in BigCorp, chances are tilllate.com would never have happened.
Anyway - the biggest problem tilllate.com seem to be having these days is finding (decent) PHP developers. I don’t know if the situation is different elsewhere but I’m hearing of quite a few small-to-medium companies in Zürich with the same trouble. Where are the PHP developers?
November 16th, 2006 at 7:13 am
Obviously not in Zurich :) Otherwise the ones that are there are happily employed doing what they are doing.
November 16th, 2006 at 11:59 am
While employing these so-called “best practices” and plenty of OO code certainly means longer development times, it also means less headaches down the road. I don’t take issue with disregarding such practices and throwing together an application quickly, but you should always plan on “fixing” it down the road.
I also don’t agree that employing best practices and OO makes an application “too rigid to incorporate [user] feedback” - at least not if done correctly. I would much rather work on a well structured OO project than on some haphazard jumble of code. In the past I’ve found it much easier to add functionality to the former rather than the latter.
As for the lack of PHP talent in Zürich, if someone has a job for me I would seriously consider moving there. So, who’s hiring?
November 16th, 2006 at 1:38 pm
Writing code is easy, rewriting (or maintaining) is painful.
That does NOT mean that the solution is to write “more maintainable” code. It’s not POSSIBLE to write easily maintained code, no matter what they may have taught you in school.
Your best bet is to write code that’s very modular so that you can completely replace things as necessary. Yes, that’s right — just replace them. Don’t screw around trying to fix old, broken code. You’re a website. You have no “backwards compatibility” issues to worry about. Rebuild it later.
November 16th, 2006 at 7:07 pm
Well here’s one for starters - let me get back on that - think we need to set something up plus I should be careful what I say.
November 16th, 2006 at 11:08 pm
Yep, we are looking for talented developers with strong PHP skills…
I promise: The job does not consist of maintaining our old smelly code… You’re going to develop cool new high-tech features for our portal…
November 17th, 2006 at 7:53 am
My point was that careful planning takes time. And in the beginning you just need to get your idea out there so that people can play around with it. That is the only way to learn what the users really want. If you start up with 6 months of initial planning and development you have lost your momentum. More importantly after those 6 months you will be mightily pissed when the users tell you they want something slightly different. If you hacked up the stuff in a few hours, you are much more willing to adapt quickly, rather than hoping for the users to adapt to you.
November 17th, 2006 at 7:41 pm
I agree to a point. I have a ‘do it right the first time’ mind frame, this is great for working on client projects however my personal ideas get stumped since I spend way too much planning rather than just getting the darn thing out there and see if it works. If it stirs up some interest and you are happy then it will be fun to fix it up (after all is this not the way that MS works). Also if you have a full time job and you work on your personal project between jobs it is very likely that it will end up a forgotten directory on you ‘to do’ files after much planning…and you will never know if it could have worked.
I wonder how much planning went into Google or Yahoo before they started?
November 18th, 2006 at 10:13 am
Totally agree with the sentiment. Rough things in and get it out there. You can (and probably will) refactor countless times, as you learn what is popular, what needs to scale, what doesn’t work very well at all. I’d say the most important planning is in the database and in logging. That’s what will give you the biggest headaches when you make major revisions. Do that right and you can switch code and even languages with relative ease.
December 17th, 2006 at 1:20 am
It’s hard to find good PHP coders because the pay is crap. When every Tom, Dick and Harry can knock up basic spaghetti code*, the market is saturated and less appealing to the skilled hacker.
January 11th, 2007 at 7:36 am
Good practices can speed up the dev process quite a lot. Ruby on Rails encourages a structured approach, where the use of convention, modules etc aids development speed. RoR is the antithesis of J2EE - dismissing OO and best habits is just a lazy response.