Joel on Software – Set Your Priorities
Custom development is that murky world where a customer tells you what to build, and you say, “are you sure?” and they say yes, and you make an absolutely beautiful spec, and say, “is this what you want?” and they say yes, and you make them sign the spec in indelible ink, nay, blood, and they do, and then you build that thing they signed off on, promptly, precisely and exactly, and they see it and they are horrified and shocked, and you spend the rest of the week reading up on whether your E&O insurance is going to cover the legal fees for the lawsuit you've gotten yourself into or merely the settlement cost. Or, if you're really lucky, the customer will smile wanly and put your code in a drawer and never use it again and never call you back.
As is usually the case with Joel’s articles, the name’s not necessarily indicative of everything you’ll get out of it. While it is true that there’s a prioritization approach detailed in this article, there’s a lot more good stuff about different development models and (at no extra charge) Joel’s strong recommendation that software companies stick with shrink wrapped software rather than consultingware or custom development.
Which led to an interesting thought for me: Isn’t web development little more than custom software development? And, more to the point, how can we bend that model more toward the shrink-wrap model?
One of my clients does lots and lots of real-estate websites. For the most part, he churns out essentially the same site time and time again, but with different window dressing (colors, fonts, the blurb about how great the agent is, etc). He’s got a generic back-end system that ties into MLS listings and allows for searching on each site, and he only has to update the MLS data in one place, once a day.
Did you notice that I said “for the most part”, though? That’s because ultimately, he’s building a new site each and every time, and it’s beginning to hurt. We started moving his sites to a new server (new OS, newer version of the database server, new IP addresses, etc) and the real pain began. Because every site has something unique buried in it. One has the sa password for the database server deep in the code. Another connects to the database using an IP address. Another assumes that it’s running on a particular IP address. And so on. (Important Point: My company DIDN’T build these sites!)
So we’ve been looking at the next generation for him. How do we turn those sites into something more akin to shrinkwrap websites? A lot of it revolves around pulling out the unique bits and wrapping them into configuration files or something like that. Some of it requires that we have some kind of framework to allow end users to tinker with the configuration from a browser (uploading pictures and other files is a big deal on these sites).
Ultimately, we think that we can use something like DotNetNuke to provide the framework, and we can standardize the sites using that model. It gives the users abundant opportunity to muck around, and gives us a way to build a single “shrinkwrapped” solution. Once implemented, the vision is that building a new site is as simple as adding a user and associated site to the database and tweaking some configuration files. Hopefully, it’ll work as expected.