As a director of engineering for several different product development teams, it is my responsibility to stay up on all of the various development paradigms. There is a trend with many of the current social media sites, like Facebook, to adopt a modified XP approach to development. If you aren’t familiar with the process of Extreme Programming, you can learn more about it here.
I once read that developers at Facebook were not happy with XP because they couldn’t write and deploy features fast enough.
This got me thinking.
Development cycle and methodology for on-premise installed software is not necessarily the same best-fit for something hosted – like a website or Software-as-a-Service (SaaS) application. The ability to “upgrade” all users instantly is an attractive appeal for hosted applications, though if not planned out or executed carefully, can go very wrong. Most companies, like Facebook, put a lot of infrastructure and process (yes, I said process) in place to prevent deployment issues such as lack of availability, performance degradations, adverse behavior, etc.
What these companies are missing, and forgetting, is that changing the application this frequently is not necessarily what is best for the end user. If you analyze the psychology of the end user, what you find typically does not line up with this need to constantly change. A user wants to master the software so that it becomes familiar, predictable – it’s what makes us feel comfortable with our environment (Anyone who has ever spent time mastering Adobe Photoshop knows exactly what I am talking about). Think of how it feels when things change – a new roommate, a new job, moving to a new city – it can be exciting – or feel completely foreign. It takes a period of adjusting. When I go online to pay my bills, I don’t want to constantly have to relearn the application so that I can complete my task – I want to master it, and then do it as efficiently as I can. I hate to say it, but there’s more to life than online bill pay.
As a director of engineering, I know there’s a cost involved in every decision. Does quality suffer? Do we pay for the choices we make today later? So is it better to make small frequent changes or roll out large sets of changes periodically? I see arguments both ways, and am interested in your opinion.
So what fuels this cycle of growth? Is it an over-abundance of capital and an oversized development team? I have talked to developers who work in this setting – and the general sentiment is that there is a sense of empowerment in seeing work applied in a really short-period of time. Who doesn’t want to see their work appreciated? It’s really fun as a developer to be able to say “Hey, I did that!”. Many developers have had experience working in the traditional waterfall approach, and for them, XP is a really exciting departure from that old model. As much as my own development staff will hate to hear me say this – it isn’t about driving the ego. It’s about solving problems for customers (and not creating new ones).
So I leave you with this final thought when it comes to rapid development and deployment: just because we can – should we?