Despite spending my weekdays designing web software since pretty much the dawn of the web, I've only ever constructed a whole web site for myself, and I've only done that using my own deliberately self-centered and exploratorily minimal tools. At the moment this site is running on a Perl+XML system that would qualify as "content management" only with the liberal application of asterisks. In its exact current state it is a random combination of me-specific hacks I didn't feel like generalizing, over-generalized partial architectures of things that my own site's small scale doesn't really require, and I guess at least a few sensible compromises between the two. The system is not a product, and I don't really aspire to turn it into one, but I'm a product designer by trade, and so tend to gravitate towards product-designer-ish solutions.
I've also never been a web freelancer, and I've always been pretty sure that freelancing wouldn't suit my personality particularly well. I prefer generalizable problems to the inherently individual, I like the challenge of adapting moral imperatives to evolving contexts and constraints more than constantly starting over at the beginning, and I really like having some control over the kind of work I'm doing.
But that doesn't mean I'm not curious, and in my at-least-temporary unemployment I have the chance to experiment, and a friend of mine who does freelance design has a project for which he needs a developer. And, intriguingly, the structure of the site he needs to build is more or less the same as this one: a few sections of static content and a couple streams of dynamic stuff.
Actually, perhaps even more importantly, the client's site is smaller than mine. Fewer pages, fewer bytes, fewer moving parts, probably even fewer visitors. More revenue, I hope, but none of it directly transacted by the site. So while my system is of vastly unproven scalability, I'm pretty confident in its ability to scale smaller than its one existing deployment.
But "scalability" is actually a vector of variable orientation. I've written an outline of the implementation plan and a full schedule of task-time estimates before we finally stop and think about what we're doing. My system is streamlined in ways that are arguably clever, but in service of my goals and habits and assumptions. I am willing to write my own code to produce exact quirks of behaviour, and conversely would rather have simple behavior under my complete control than complexity that depends on other systems and constraints. I don't have to anticipate where I can adapt. I don't mind editing XML files by hand. I embrace informed incompatibility. I want a work in constant progress. I am a designer of large systems produced by large teams in my work life, and this is my other-extreme small system for the smallest team.
My friend's client, on the other hand, is a chicken breeder. I don't mean this metaphorically, I mean they're a company that breeds chickens. Their web site, when it's done, will have background information, breeding statistics, news and announcements about their breeding of their chickens. I am quite prepared to believe, after looking through the source material for the site, that they are every bit as diligent about chickens as I am about information. And, vice versa, I would care about chicken breeding as long as it took me to build their site, and they would care about web design as long as their site never really required them to.
So while I could build their web site, they could probably cook me a chicken dinner. I deal in information structure first, and the structure of chicken-breeding information is not complicated. They deal in predictability and consistency, and if you can breed chickens you can probably follow a recipe.
But there are people who cook for a living, and people who make web sites like this for a living, and there are excellent reasons to let them. Fiddling with my site when I feel like it is a pleasure. Fiddling with theirs in a sudden crisis would be annoying for me and for them. My system is designed in anticipation of a future in which my software environment may change in a hundred ways, but I will always be me. Theirs should be built in almost exactly the opposite way, assuming that techs and admins and data-enterers and freelancers will change but the software will stay the same. A commercial content-management system is intolerable overhead and point-missing premature closure to me, basic foundation and the first step towards maintainability for them.
So I'm not doing the site. We had fun imagining how we might have, probably me more than my friend, since I'm not billing for my time, and at the end of this he still has to find someone to build him a chicken breeder's site the right way. I got some ideas of new things to play with here on my own site, he got a couple ideas about streamlining their navigation and using tagging to filter news by audience. And I don't know whether this means I'll never be a freelancer, but I have a clearer idea of what oddities a project would have to entail to lend itself to my odd tools.
And I am reminded, most usefully, that the most critical constraints on your solutions are not your capabilities, but the capabilities of the people whose problems you are trying to solve. As a tool collector and maker of tools for making tools, you are allowed to fill your own workshop with lopsided automata and non-Euclidean corners and puzzle-joins and secret panels; but when you're building for people who only ever want to have to own a hammer, you better stick to nails.
I've also never been a web freelancer, and I've always been pretty sure that freelancing wouldn't suit my personality particularly well. I prefer generalizable problems to the inherently individual, I like the challenge of adapting moral imperatives to evolving contexts and constraints more than constantly starting over at the beginning, and I really like having some control over the kind of work I'm doing.
But that doesn't mean I'm not curious, and in my at-least-temporary unemployment I have the chance to experiment, and a friend of mine who does freelance design has a project for which he needs a developer. And, intriguingly, the structure of the site he needs to build is more or less the same as this one: a few sections of static content and a couple streams of dynamic stuff.
Actually, perhaps even more importantly, the client's site is smaller than mine. Fewer pages, fewer bytes, fewer moving parts, probably even fewer visitors. More revenue, I hope, but none of it directly transacted by the site. So while my system is of vastly unproven scalability, I'm pretty confident in its ability to scale smaller than its one existing deployment.
But "scalability" is actually a vector of variable orientation. I've written an outline of the implementation plan and a full schedule of task-time estimates before we finally stop and think about what we're doing. My system is streamlined in ways that are arguably clever, but in service of my goals and habits and assumptions. I am willing to write my own code to produce exact quirks of behaviour, and conversely would rather have simple behavior under my complete control than complexity that depends on other systems and constraints. I don't have to anticipate where I can adapt. I don't mind editing XML files by hand. I embrace informed incompatibility. I want a work in constant progress. I am a designer of large systems produced by large teams in my work life, and this is my other-extreme small system for the smallest team.
My friend's client, on the other hand, is a chicken breeder. I don't mean this metaphorically, I mean they're a company that breeds chickens. Their web site, when it's done, will have background information, breeding statistics, news and announcements about their breeding of their chickens. I am quite prepared to believe, after looking through the source material for the site, that they are every bit as diligent about chickens as I am about information. And, vice versa, I would care about chicken breeding as long as it took me to build their site, and they would care about web design as long as their site never really required them to.
So while I could build their web site, they could probably cook me a chicken dinner. I deal in information structure first, and the structure of chicken-breeding information is not complicated. They deal in predictability and consistency, and if you can breed chickens you can probably follow a recipe.
But there are people who cook for a living, and people who make web sites like this for a living, and there are excellent reasons to let them. Fiddling with my site when I feel like it is a pleasure. Fiddling with theirs in a sudden crisis would be annoying for me and for them. My system is designed in anticipation of a future in which my software environment may change in a hundred ways, but I will always be me. Theirs should be built in almost exactly the opposite way, assuming that techs and admins and data-enterers and freelancers will change but the software will stay the same. A commercial content-management system is intolerable overhead and point-missing premature closure to me, basic foundation and the first step towards maintainability for them.
So I'm not doing the site. We had fun imagining how we might have, probably me more than my friend, since I'm not billing for my time, and at the end of this he still has to find someone to build him a chicken breeder's site the right way. I got some ideas of new things to play with here on my own site, he got a couple ideas about streamlining their navigation and using tagging to filter news by audience. And I don't know whether this means I'll never be a freelancer, but I have a clearer idea of what oddities a project would have to entail to lend itself to my odd tools.
And I am reminded, most usefully, that the most critical constraints on your solutions are not your capabilities, but the capabilities of the people whose problems you are trying to solve. As a tool collector and maker of tools for making tools, you are allowed to fill your own workshop with lopsided automata and non-Euclidean corners and puzzle-joins and secret panels; but when you're building for people who only ever want to have to own a hammer, you better stick to nails.