If you know what I've been working on for the last nine months, you might (correctly) suspect that I've learned a few lessons about developing large-scale (highly scale-able) and complex software. Let me share some thoughts I've got about the subject.
But before I begin, I should point out some aspects that make this a special project. I can't speak for the UI, and while everyone on the engineering team worked on the project in the final months, the development team—especially in the early stages—was small. Ben Hendrickson and I headed up architecture and the software efforts. We were the "core" team for the back-end efforts. So this made some things a lot easier. I'll comment more about this later.
Be Bullish (but Realistic) in the Planning Stages
One thing that helped us tremendously was to be broad and optimistic in the early stages. Doing this gave us a large menu of features and directions for development to choose from as plans firmed up and difficulties arose. I know the adage, "Under-promise, over-deliver." And there's a place for that mentality. When we did start to firm up plans, clearly we were not going to promise everything. But we tried to keep things as fluid as possible for as long as possible. This worked out for almost all of our features, and by the time we were half-way through with our project we had the final feature set nailed down, and prototyped out.
There was one substantial feature that we had to cut just a few weeks before launch. Perhaps we were too bullish, but I believe that this kind of thing is fairly normal for large software projects. I'm looking forward to working on that for the next release. ;)
Have Many Milestones and Early Prototypes
I wish we had had more milestones and stuck to them. The last couple of months were hellish with literally 14-16 hour days, 7 days a week. With my commute, there were many days that I arrived home, got into bed, woke up, and rolled back onto the bus to start it all over again. Despite reading about "hard-core" entrepreneurs who have this as a "lifestyle", I would not recommend it for a successful software engineering team.
We hit our earliest milestones and even had an early version about four months before launch. But the two milestones between that prototype and launch both slipped and no one stepped in to repair the schedule. So the rest of the team (including Ben and me, plus another six software engineers) had to take up the slack at the last minute. Missing these milestones should have told us something about the remainder of the schedule. Frankly, I think we were lucky to launch when we did (good job team!).
Low Communication Overhead = Success
We were lucky to have a small team. For the back-end it was basically just Ben and me. And we do all of the data management and most of the processing in the back-end. So it was easy for Ben and me to stay in sync. Add to that the fact that we work well together and we were able to achieve in a small team, what normally requires a much larger team.
While I've worked in much larger organizations, I've never had the leadership role in those organizations that I do now. So I can't say how much of this advice applies to larger organizations. I guess my feeling is the same that many people have: keep related logic together in small teams, have clear interfaces to other units. This worked well when we integrated with our middle-ware and front-end.
KISS
Anna Patterson describes a simple roadmap for building search engine technology. I'm not saying we followed this plan, but I can say that our (I hope successful) plan is equally simple. Identify the work you need to do. Come up with reasonable solutions. Plan and implement them. Don't get bogged down in hype or fancy technology.
There's certainly more to success than these points. These are just what come to mind when I think about the success of this project. In any case, good luck on your own projects!
No comments:
Post a Comment