Michael Wurzer Caveat: This post might be me whining about how hard my job seems to me at times. I hope not but it might be, so either forgive me up front for that possibility or just stop reading now.
Developing software is hard. Really hard. Even when you’ve got a brilliant team of committed people, getting a project to ship is difficult. Examples abound: Microsoft and Vista; Apple and OS X; and Mitch Kapor’s Chandler Project leap to mind.
If you’re not familiar with Mitch Kapor or Chandler and are even remotely interested in software, you should check out the book Dreaming in Code, by Scott Rosenberg. Mr. Rosenberg spent a couple of years following Mitch Kapor’s largely failed efforts to build a Microsoft Outlook killer. The story is chock-full of every possible mistake a team can make in trying to release new software. And it’s not like these people were rookies. Kapor was one of the founders of Lotus 1-2-3, the revolutionary spreadsheet that helped launch Windows. Joining Kapor in his open source mission were veterans from Apple, Microsoft, and Netscape. These folks brought some serious experience to the table. But they still failed. (Well, actually, the project is on-going but floundering.)If you want all the reasons for why software is hard, order or pick up Dreaming in Code and enjoy the agony. If you want my opinion, though, here it is: Choosing is hard. Basically, that’s it in a nutshell. Designing software is about making choices. Choices about what features to include or not include. Choices about what options to include for those features or not include. Choices about data to store or not store. Choices about the user interface. Choices about the programming language, OS platform, web or distributed, etc.
The choices are nearly endless and you can pretty much rest assured that every choice will have a critic. If you choose the web, there will be those who need off-line access. If you choose AJAX, there will be programmers you hire who want to use Java or .Net. If you choose to include feature X, you’ll have others wondering why you didn’t include feature Y. If you choose both feature X and Y, you’ll have users saying the software is too hard to use.
Fear of such criticisms, however, is rarely the biggest dilemma. Rather, the biggest dilemma is the “wouldn’t it be cool if . . .” inclination of software developers. Every developer wants their software to be cool and what’s cool is making users happy. But users present an infinite number of desires and so making them happy often means cool stuff gets added, and added, and added.
This is why projects often end up late — the eyes are bigger than the stomach, at least at the beginning of the project. In the beginning, the desire is to want to solve as many user challenges as possible, so lots of stuff gets added into the initial design. Compounding this problem, however, is the fact that predicting the amount of time any single programming project will take is fraught with potential error, which gets compounded yet again when you have lots of projects into a single release. When the project inevitably takes longer than you expect, the easiest solution is to start taking away some of the features you wanted in the first instance, which merely perpetuates the cycle into the next release, where you’ll want to add the “really cool” stuff again.
Perhaps an even bigger problem, however, is that, even if you end up succeeding in adding a lot of cool features, they may not be very elegant. Instead, they could be a mess of features that work for themselves but not with each other. Adding features without creating a mess, that’s the heart of great software design. Others focus on keeping the features simple, but that’s only satisfying to users in the short run. If you want to serve your customers for a long time, sooner or later, as your systems mature, more features need to be added. So, again, adding features without creating a mess is the key to elegance.
This is all very relevant to me right now, because we’re in the throes of re-designing the two most used functions in our MLS software right now, search and search results. An MLS system contains hundreds of fields, so creating an elegant search function is not easy. In addition to the many fields, the purposes for searching are varied, too. Users may be wanting to find properties for a client, for a CMA, for statistical purposes, to evaluate their own production, and more. All of these involve finding listings but can or should they all be in one function?
Similarly, with mapping integral to the search and display function, should the search and search results functions be combined into one function? Will this one function work for consumers as well as agents, because that’s necessary, too, for IDX systems, client e-mails and other public facing features. In fact, as the lines between the private and public side of the MLS systems are blurring more every day, the design challenge for MLS systems has become even greater. Now the system needs to serve both the professional agent and the consumer, who has no time or inclination to learn the system enough to go deeper.
Our deadline is November 2007. I’m confident we’re on the path to elegance and I’m really looking forward to the coming weeks as we’re about to start discussing some of our designs with our customers to get early and continuous feedback. I’ll try to keep you posted as we make progress.