Create the Web instead of colonizing it.
Some weeks ago, when it was still wintry in one half of U.S.A. and anything but in the other half, I encountered the following Tweet:
The old man seemed lost and friendless. “I miss static HTML,” he said.
— Jeffrey Zeldman (@zeldman) March 12, 2015
I’m grateful to call Jeffrey Zeldman a friend, seeing as he’s a terrific guy in addition to being one of the foremost doyens of web design. In that sentiment and with the wish to call attention to his lament, I replied:
@zeldman Story of my last five years, that. When did simplification & removal of dependencies become subversive?
— Ben Henick (@bhenick) March 12, 2015
…And now I get to unpack all of that, as briefly as possible.
The integration of the Web's diverse communities broadens horizons and technology.
Web projects are integration projects, combining skills from a number of disciplines. Lousy interfaces can obscure brilliant code, and ingeniously engineered back-end systems can still fail when they hit resource limits. “Content” lurks in many guises, requiring support not only from writers and illustrators but from video specialists, game designers, and many more. Marketers have built businesses on the Web, and influence conversations from design to analytics. You don’t have to be a programmer to do great work on the Web. The Web stack is vast.
Web development models include far more than code. Creating great websites and applications demands collaboration among content creators, designers, and programmers. As applications grow larger, supporting them requires adding a cast of people who can help them scale to demand. As projects grow, specialization typically lets people focus on specific aspects of those larger disciplines, supporting networking, databases, template systems, graphics details, and much more.
In some ways, that’s a recipe for fragmentation, and some days the edges are sharp. All of these communities have different priorities, which conflict regularly. Battles over resources sharpen the axes, and memories often linger.
At the same time, though, often even in environments where resources are scarce, different perspectives can reinforce each other or create new possibilities. Sometimes, it’s just because the intersection spaces have been left fallow for a long time, but other times, the combinations themselves create new opportunities. Read more…
What to expect at OSCON 2015.
Twenty years ago, open source was a cause. Ten years ago, it was the underdog. Today, it sits upon the Iron Throne ruling all it surveys. Software engineers now use open source frameworks, languages, and tools in almost all projects.
When I was putting together the program for OSCON with the other program chairs, it occurred to me that by covering “just” open source, we weren’t really leaving out all that much of the software landscape. It seems open source has indeed won, but let’s not gloat; let’s make things even better. Open source has made many great changes to software possible, but the spirit of the founding community goes well beyond code. Read more…
The future is maintenance: build for the inevitable.
Technology has had a cult of newness for centuries. We hail innovators, cheer change, and fend off critics who might think new and change are coming too fast. Unfortunately, while that drives the cycle of creation, it also creates biases that damage what we create, reducing the benefits and increasing the costs.
Formerly new things rapidly become ordinary “plumbing,” while maintenance becomes a cost center, something to complain about. “Green fields” and startups look ever more attractive because they offer opportunities to start fresh, with minimal connections to past technology decisions.
The problem, though, is that most of these new things — the ones that succeed enough to stay around — have a long maintenance cycle ahead of them. As Axel Rauschmayer put it:
“People who maintain stuff are the unsung heroes of software development.”
In a different context, Steve Hendricks of Historic Doors pointed out that:
“Low maintenance is the holy grail of our culture. We’ve gone so far that we’re willing to throw things away rather than fix them.”
That gets especially expensive. Heaping praise on the creators of new things while trying to minimize the costs of the maintainers is a recipe for disaster over the long term.
Khoi Vinh on "How They Got There," the cards interaction model, and designers as founders.
I recently sat down with Khoi Vinh, vice president of user experience at Wildcard and co-founder of Kidpost. Previously, Vinh was co-founder and CEO of Mixel (acquired by Etsy, Inc.), design director of The New York Times Online, and co-founder of the design studio Behavior, LLC. Our conversation included a discussion of career paths; the much talked about new interaction model, cards; and advice for design entrepreneurs.
Curiosity serves designers well
Vinh and I discussed the ever-evolving role of designers. He recently self-published How They Got There, a book of interviews with interaction designers who describe their career paths and offer advice and insight. Vinh explained:
“How They Got There is kind of like the book I wish I could have read when I was just starting out in my career. The central thesis is that very few careers are truly planned out, A to B, to C, to Z, and it’s usually a lot of stuff that just happens by circumstance or blind luck, or through someone who knows someone.
“As I became more and more aware of that in my career, I started to find those stories really interesting, really revealing, because they say so much about the character of people who achieve notoriety in their careers; the circumstances that led them to where they are can be fascinating. In a lot of instances, the things that get these people onto these paths are very, very minor events or minor coincidences. … There’s a serendipity, but I think, one thing that comes out when you read these stories is what serves these designers really well is curiosity, a willingness to be available to opportunities, so to speak. They go with the flow. They let one thing turn into another through their ability to acclimate themselves to various situations.
“What’s that old saying from Branch Rickey — “luck is the residue of design”? These careers are somewhat serendipitous, but they are really the result of folks who are very conscientious about making the most of whatever situation they had and working really hard and applying themselves, and looking at the world around them with great curiosity and being really willing to study what it takes to get to the next level.”
How much do you need to know?
I expected that CSSDevConf would be primarily a show about front-end work, focused on work in clients and specifically in browsers. I kept running into conversations, though, about the challenges of moving between the front and back end, the client and the server side. Some were from developers suddenly told that they had to become “full-stack developers” covering the whole spectrum, while others were from front-end engineers suddenly finding a flood of back-end developers tinkering with the client side of their applications. “Full-stack” isn’t always a cheerful story.
In the early days of the Web, “full-stack” was normal. While there were certainly people who focused on running web servers or designing sites as beautiful as the technology would allow, there were lots of webmasters who knew how to design a site, write HTML, manage a server, and maybe write some CGI code for early applications.
Even as the bust set in, specialization remained the trend because Web projects — especially on the server side — had grown far more complicated. They weren’t just a server and a few scripts, but a complete stack, including templates, logic, and usually a database. Whether you preferred the LAMP stack, a Microsoft ASP stack, or perhaps Java servlets and JSP, the server side rapidly became its own complex arena. Intranet development in particular exploded as a way to build server-based applications that could (cheaply) connect data sources to users on multiple platforms. Writing web apps was faster and cheaper than writing desktop apps, with more tolerance for platform variation.