Developer as (Fashion) Designer
As a developer I generally do one of three things. The first is build custom software from scratch. The second is build a ‘solution’ from COTS pieces wired together with a little bit of custom code. The third is tell the client what to buy in terms and, if necessary, I install or configure the software. Which approach is better is dependent on a variety of factors, including what the software needs to do, what software already exists, and the degree to which the software is core to the client’s business. Because of some very natural analogies between software and construction, many software developers and theorists liken the industry to a form of engineering or construction, specifically civil engineering.
How does an engineer tackle a complex problem? They break it down into sub-problems. At some point those sub-problems are broken down into sub-sub-problems and so on. Eventually you wind up with pieces that are solved or solvable. To make this all possible you must specify every aspect of the system. I have never seen a client or engineer completely and accurately specify all parts of a software system to the mind-numbing detail required. As software becomes more complicated, now encompassing concepts such as ‘social networking feeds’ and ‘user-contributed content,’ this approach isn’t scaling. In fact, I think we need to step away from the engineering mindset and explore analogies to other professions.
Even though it might sound a little odd at first, it occurred to me the other day that my job is a lot more like the fashion industry. Most software is like mass produced clothing. It’s bought off the rack and isn’t tailored to suit any particular body – just anybody the designer considers a ‘Medium.’ Because it’s mass-produced, the price per item is relatively cheap. Writing a word processor from scratch makes about as much sense as custom-fit t-shirts. A lot of software, in fact the vast majority of software falls into this camp. Everything from Windows and Microsoft Office to Mac OS and your typical Linux distribution are essentially ‘off-the-rack.’
At the next step up we can take something that’s off the rack but requires hemming and cutting to fit, like pants. It isn’t specifically tailored to fit you but it is altered to fit you better. For example, nice pants often require hemming as opposed to off the rack slacks at pre-determined inseams. This is stock software with a customization. For example, you might want Radiant (a CMS) with a custom extension or two.
Then is the completely custom suit. You go in, get measured, and for several hundred (or even thousands) of dollars later you get a suit that fits you perfectly. You choose aspects of the suit like the material, but you don’t make every decision. You could tell the tailor to give you 12" lapels and cuff the sleeves, and the tailor may oblige, but you will look a little ridiculous. You would generally trust the tailor – barring minor alterations. The tailor or designer makes detailed decisions and all you care about is that you get a fashionable and well fitting suit. This is the way most custom software should be built.
However, this is the way custom software is actually built: You specify all the exact requirements of the system. Imagine going into the same tailor and buying a suit by telling the tailor how wide the lapels should be. That they should be even on both sides. That the sleeves NOT be cuffed but the pants MUST be cuffed. That there should be only one breast pocket on the left breast. The suit should be made of wool. Jacket pockets should by symmetric on the left and right side. And so on… That would seem ridiculous and would consume a lot of time and energy, and yet, that’s how a lot of custom software is specified.
Many parties are responsible for this current state of affairs. Partly it stems from the customer’s need for control. How do you know the developer will deliver what you want unless you tell them? Partly it’s the developer covering their own rear. Imagine how hard it would be to buy clothing if you had to have detailed specifications each time you went to the mall. You should start thinking of your developer resources like personal shoppers or stylists. You should be able to give them some parameters and get back a reasonable solution without having to cover every possibly insignificant detail.
In fact, a software developer as stylist probably fits better than software developer as engineer. The practitioner should be able to put together COTS software, customized software and custom software together into a coherent whole, just as a fashion designer or stylist can create an outfit or collection from custom pieces, off the rack pieces, and tailored pieces. As a customer, you shouldn’t have to make every decision about every piece going into the end product. As a customer, though, you should resist the temptation to micro-manage the process. Imagine paying for a stylist and then following them around the mall and requiring your approval for every minor decision.
As a developer, it is vitally important to listen to your client and understand you are building a solution to suit their tastes and needs. You need to put something together that fits your client and in which they feel comfortable. As a client, you need to make sure the developer understand what you want, but you also need to step back and trust the developer’s judgment and experience. In some cases what might looks or feels awkward or new in the new software will quickly feel natural and second-nature. If the relationship is too hands-off, then the developer will just return with what they think is a ‘good fit.’ If the relationship is too hands-on you may wind up cursed with exactly what you asked for, 12" lapels, cuffed sleeves and all.
Thinking back at the first paragraph and the reference to civil engineering is important. Why? Because there are really no ‘off-the-rack’ skyscrapers or bridges. Everything has to be specified at the minutest level. When we make the analogy to civil engineering we already put ourselves in the frame of large, complicated projects that are often unique at some level. Instead, we should break out of those frames and look at other industries. Software development hasn’t been around long enough for us to really get our minds around it the same way we understand tailoring or construction. Until then we will feel the need to frame our discussion of software in terms of some other endeavor we all understand. The trick is not to get too trapped by the analogy and to learn by trying on different a new analogies. So, why not fashion?
Up Next: Apple Is Not Not Enterprise Ready by
Previously: It's the Stack That Matters by