3 Responses to “Dot-Com Dev Cycles”  

1. 1 morland May 29th, 2007 at 9:15 am

   I’ve worked at a small (~8 developers, ~35 total) startup that merged with another larger one (ultimately ~120 combined employees total), and then at another small startup that has grown dramatically in the past year (similar numbers to the previous experience). As I’m heading back to school I’ve been on a contemplative streak recently, thinking about the respective organizations and specifically about how our software was built.

   First off, I think we’re lucky that the two ends of the spectrum we’re talking about are 3 and 30-person development teams. I’ve had glimpses into larger-scale projects that have three times the number of engineers and release cycles on the order of six months. The communications, planning, and coordination overhead becomes evident once you pass the five or six-person mark, but at those larger levels it becomes truly asphyxiating.

   That said, I won’t trivialize the disparity between small teams and very small teams - there’s certainly a different dynamic at work. Curiously I’ve found that the small-ish teams (say, 8-15 developers) need far more discipline than the very small teams, even with the additional structure in place, especially if there’s a shared code base. Everybody has to buy in to the process and abide by the methodology or projects will go off-track very quickly.

   At my first job we were Extreme Programming disciples, operating on a three-week release cycle. With three weeks of development and three of QA it meant no feature went from suggestion to actuality in under six weeks. However, there was a huge advantage to this in knowing exactly how much capacity we had and becoming very good at estimating the time required for tasks. We could get a new proposed feature or even entire application, sit down for an hour, and know with a very high degree of confidence that we could deliver it in X weeks. And in the grand scheme of things, a six week cycle is still fairly nimble, at least nimble enough that when combined with the increased planning and stability (our production code was remarkably bug-free) we felt it was the balance that provided the most overall benefit.

   The downside, paradoxically, is that you know too much, or rather become too habitual about thinking everything through. Every change becomes an element in a larger plan, and has to be designed, estimated, assigned, accounted for, and tested. For larger feature additions that level of process is worthwhile, but for much smaller changes the time spent tracking it far outweighs the actual developmental effort. Nobody wants to be doing the equivalent of two days of pushing paper just to get a 30-minute tweak out the door. Furthermore since you are perpetually at capacity there is no incentive to take a risk and start coding something without knowing exactly how much time it will take. Every hour you spend on that new blue sky project is an hour of neglect on your assigned work that the entire company (yourself included) decided is a higher priority. There’s something almost unnatural about startups acting like that - some of the best products stem from partial or complete ignorance about just how monumental the effort is you’re about to undertake. In other words, when you should be focusing on the goal and ignoring the effort, you focus on the effort which distracts you from the goal.

   Of course a very positive flip side to that is you’re not working 100-hour weeks every week because the whole team has its time managed very effectively. But burnout is another topic entirely.

   I’d love to hear more about others’ experiences - my personal theory of the moment is that much shorter cycles (one week?) and rotating experimental duties might work. Shorter cycles mean chunking projects down to the point where the overhead of a small chunk of a large task and that of a complete but small feature are the same (meaning small features are now comparatively less onerous). And by assigning one or two engineers each week to “free time” (truly a better term would have to be coined), there’s hopefully some chance of introducing systemic risk-taking and experimenting - the worst case scenario is that they act like sweepers in soccer, catching loose ends and cleaning up the back-field (infrastructure), ultimately helping to drive development forward. That metaphor breaks easily, don’t stress-test it.

2. 2 Andrew Parker May 29th, 2007 at 9:38 am

   Morland: Eloquent description of the nature of this problem: far better than my own ;)

   I kept saying to myself: exactly! Right on! as I read. So you clearly know the sore points in this issue from experience.

   It’s interesting to note that you worked at Vindigo. Working at USV, I have been lucky enough to talk to Jason Devitt a length on a number of topics. He’s brilliant, especially for all things mobile-related. How’d you like working with him?

   I never worked in the principles of Extreme Programming in a work-setting, but I embraced them for school projects that I knew I would never see again. My only beef with Extreme Programming is that it usually results in code that cannot be reused, so in a work-setting we tried to think forward a little bit more than Extreme Programming generally suggests. That said, we certainly embraced a subset of the Extreme Programming principles in work.

   I love the “sweeper in soccer” strategy you mention. We did it in the larger dev-cycle and it worked for awhile, but then as more high priority features built up in the cycle we sacraficed clean-up in favor of better bandwidth for features. It was probably a mistake in the long run.

3. 3 morland May 29th, 2007 at 11:16 am

   I think what you said about sacrificing clean-up in favor of more bandwidth for feature development gets to the heart of what I mean when I say everybody has to be disciplined. In some ways it’s the most fascinating part of this whole analysis: that you need to design and adhere to a system to protect you from yourself. There are always going to be market demands - whether it’s a startup needing to hit a certain launch date for funding or a big public company trying to make its numbers for earnings season - that push you to compromise the structure you have set up. In the moment, amidst all that pressure to cut corners and sacrifice clean-up, it seems like a very logical and reasonable choice to give in “just this once”, but it really can set a bad precedent with long-standing ramifications.

   It’s a really tough spot: give in and risk eroding the entire system on which you’re predicating success or stand firm and risk having your reputation undermined for being obstinate and unrealistic.

   Now I’m not an ideologue, and I know there will be extenuating circumstances that demand we be flexible, but if you look at some of the most successful expanding tech companies out there (let’s take Google and Facebook), they’re the ones that through luck or willpower managed to best protect themselves against the urge to sacrifice long-term sustainability for short-term gain. I think having engineers at the head has a lot to do with that: they’re the best-armed to fight human nature with hard data.

   Now it could be a chicken and egg question - were they free to stick to the rules because they were successful, or were they successful because they steadfastly stuck to the rules - but there’s a level of correlation there that indicates causality I think.

   You also need to be careful about the level of authority with which you endow the “rules”. There’s a difference between organizing principles and a full-fledged self-perpetuating institution. Go too far and you wind up in a world like The Wire, where each cog is completely dehumanized and everybody is out to satisfy the success criteria of the system itself, instead of the larger problem the system is meant to address (this is when serious internal politics crop up). But that’s thankfully not usually an issue at the startup scale.

Leave a Reply