Archive for the ‘Programming’ Category

The architect’s job after 1.0

I’m feeling energized and optimistic today, not only because it’s Friday, but because I just finished listening to Joe Wirtley’s excellent talk on the role of the architect in software development shops. Having acquired this title recently at my own company, I’ve been thinking about this a lot. It’s one question I get asked often, sometimes sheepishly, by job candidates during interviews for open developer spots. “So, umm, what do you do exactly?” A fair question, particularly because when I came to this company, the first version of the core product was near release, so the foundation was already hardening and many of the technical decisions about how it all hangs together had already been made.

Fortunately, though, the architect’s job doesn’t end when a product goes to release or a web site opens its virtual doors. Sure, as software matures, there are fewer conversations about what modules need to be built out and how they’ll interact and whether Spring or EJB is the right choice to handle cross-cutting concerns like database transactions. But the influences that drive decisions like those don’t disappear after 1.0. So what is my job? I could say that it is to help evolve the system in a cohesive way to meet new business challenges and performance, usability, and security objectives. (Cough.) But honestly, that’s not why I get up in the morning. My real purpose as I see it is to make developers’ lives easier—including my own. If I’m successful at that, the rest takes care of itself.

PitfallNow, by easier, I’m not talking about giving free license to cut corners on design, skimp on documentation, or get lazy in implementation. Just the opposite. It’s about making life easier over the long haul. Keeping an eye out for pitfalls as new features take shape and suggesting paths around them is part of it. Adopting tools that make it easier to push functionality forward is another. But above all, encouraging developers to avoid incurring new technical debt and pay down the old is the best way to ensure vitality of a project and gives everyone a sense of pride in what we’ve created. I don’t worry that it will take Ameer three extra days to make Feature A fit cleanly within our existing framework if it means that Sean will have an easier time adding Features A+1 and A+2 six months down the road after Ameer has moved on. In short, my job is to make sure that the system remains understandable as requirements change and programmers come and go.

When developers lives get easier, the organization and customers are the ultimate beneficiaries. Taking a long-term view of how the code evolves leads to better predictions about the time and effort needed to add new functionality. Paying down technical debt enables developers to spend less time fighting an unruly code base and more time solving a customer’s real problems. It also helps avoid new bugs caused by unintended side-effects of fixing the old ones. Choosing the best tools and investing in change if the project outgrows them reduces friction when five new pages need to be built out in five days. Cutting down the time it takes to run a full build means the difference between a developer who’s able stay focused on task and one whose eyes wander over to Facebook while her hard drive chugs away.

On the face, all this seems obvious. But the value of these investments often gets short shrift in an agilist culture when the benefit to the customer is not immediate or obvious. It’s up to the architect to fight the good fight even in the face of a management team feeling constant pressure to achieve short-term revenue and rapid-fire releases. Sometimes you make your point and sometimes you just need to get over it and ship the damn thing so everyone can get paid. But as the architect, you don’t stop championing the long-term view because after 1.0, that’s your job.

Categories: Programming