The Backlash
37signals has recently endured a bit of a backlash against its design philosophy. The trouble seems to emanate from a frustrating piece in Wired that’s inspired a lot of people to chime in about how badly 37signals is missing the boat on software development, by resisting change to its business and products.
Having seen Jason speak at this year’s SXSW though, I don’t think his ideas about designing web-app software and building a sustainable business could be more right. 37signals’ core design philosophy of saying no to just about everything is perfectly sound — the less there is, the less chance for complexity and frustration. Solid application design stems from limiting scope and focusing on core functionality given business constraints (time & money, baby).
Yet pointing this out irks many in the development community. Jason and 37signals are labeled rat bastards because they won’t add XXX new feature and advise everyone else that they shouldn’t either. It’s got to be more than just envy at their success (thought I can only assume envy plays a part) that drives this animosity within the web community. At it’s core, the anti-37signals push has grown from the disjunct between what motivates designers (constraints) & what motivates developers (features).
Developers Love Themselves Some Features
It’s pretty obvious that for application developers, the creation of new features is a GoodThing; creating a fresh set of challenges to identify and solve is what programmers love doing. Conversations of giddy positivity — gaseous, stammery mouthed madness for “the new” — are the nasty byproducts of feature glee. In short, dev teams become obsessed with Futuretalk and get distracted from solving simple, real problems.
Our current set of MVC frameworks, OO programming idioms, and inter-app messaging languages feed this mentality — our tools are so infinitely “recombinateable” that many programmers think they must have great reasons to exclude a new feature, rather than a bulletproof defense of why it needs to go in. Of course, this is an inversion of solid design thought — any element or feature going into a product must fight for inclusion, not the opposite.
Innovate for Yesterday
In an industry that changes so fast I’ll never remember half the tools I use today, it’s easy to try to “get ahead” by solving the problems of tomorrow, today. However, businesses that remain dedicated to solving today’s problems will be the only ones around to fight tomorrow’s challenges. We can’t outthink the future — in fact, we must focus on problems that users have had for years and dedicate ourselves to fixing those issues. If we innovate for yesterday, we’ll be able to help users be more productive both today and tomorrow.
