Summary: Developer-turned-information architect Joe Elmendorf muses on the competing mental processes required for each role.
It is not often that I’m the web developer anymore. While I’ve never been a “real” developer (with formal training), I’ve built my fair share of websites before The Understanding Group.
As a front-end developer, I would take a PSD mockup (usually from a print designer) and build a pixel-perfect* website. These weren’t the kind of people interested in hearing that their design was anything but perfect. As long as the site loaded quickly and was accurate, my role as the “guy coding the site” was complete. So I would plug along with my blinders on churning out beautiful and structured HTML and CSS.
But I’m not a developer anymore, at least not professionally, and as an information architect, I have different priorities. My goal is to make things good for people who live on the Internet. Not just accurate and efficient because the person paying me said so. I’ve done a good job of over-writing my internal priorities from “Accurate Because They Said So” to “Good Because of Reasons.”
After working on a few small development projects, I’ve found myself challenged by these conflicting priorities: Good vs Accurate. Good vs Efficient.
Since I was assuming both of these roles, first I created high-level architectural plans. I avoided going into great detail because I was the one receiving the plans, so there was little value in taking the time to create them. Once I’d reached the point where I’d described enough of the system to start building it, I took off my information architect hat and donned the developer hat. I went about implementing the plans and building the technical structures necessary for the platform.
But then, since my instructions were incomplete, a question arose. The kind of thing that the architect should have documented in the instructions. The kind of thing that should be run past the architect and not left up to the developer. But…I am the architect. So, without taking off my developer hat, I pushed through and developed the most direct solution. I should have stepped back and surveyed the situation as an architect.
Which, of course, resulted in GARBAGE.
Developers and anyone in a human factors field think radically differently. The developer thinks about how to best translate a set of instructions to execution by a machine. Those with a focus on human factors work to make the machine serve the human, based on what the human actually wants to do. These tasks—solving a computer problem and solving a human problem—are fundamentally in conflict with one another. Each are furthering themselves by marginalizing the other.
Planning vs Implementing
After having recognized this dichotomy, I set out to be intentional about keeping the planning and implementing stages separate. It was a noble aspiration, but I soon found that separation wasn’t enough. Due to the iterative development cycles required for the project, I was still asked to switch back and forth between the two roles. The developer still needed to be asking the architect questions, and yet he still wasn’t (what an idiot!).
I am not sure why I am unable to switch from developer back to information architect. I suspect it has something to do with not being able to shake the practicalities of a project after being “exposed” to them as a developer. I also suspect that this is not just an issue that I face, but one that is prevalent among many dualists like myself. For now, I am choosing, for those few projects where I am the developer, to surrender control of the information architecture to avoid the temptation of solving a human problem with machine’s solution.