Several years ago, nearing the end of my time at my first “real” job, an “agile consultancy” was brought in to evaluate the firms readiness to use agile techniques. Things were bad at the time. Morale was low, many projects were perceived as failing, and nearly every meeting ended in frustration. So when the agile consultants conducted their interviews and group sessions, these tended to devolve into an airing of grievances.
One of these sessions still sticks in my mind. The consultants asked everyone in the group of about ten people to write one word on an index card describing what the firm could be doing better. We then posted the cards on the wall. I knew exactly what to write, and within a few minutes my card, emblazoned with the world “TOOLS,” stood out in a field of other cards reading “process.”
At the time it was so painfully obvious to me that tools were the primary source of frustration, and I was disheartened to see my colleagues miss the mark so completely. In my mind, process meant more meetings, more garbage, and more waste. We had a tool problem! Most developers were using a shared development server which yielded combinations of code never represented in version control. While we had individual development virtual machines,there was nothing close to a one click deploy, nothing to bootstrap a project out of version control. Those of us actually running the projects on our development machines did it from scratch and administered our own boxes. Many of the developers were new to the LAMP stack, and didn’t have the skillset to accomplish these administrative tasks. Likewise, while some projects had functional and integration tests, there was little buy in and the continuous integration server sat dormant. So after the agile consultants asked me about my tool-related frustrations, the topic was gradually redirected to “process” and I zoned out. Process meant bullshit, and these guys were outsiders charging us an arm and a leg to feed us more of it. And what did it matter? My foot was already halfway out the door, and I went home and sent off a few more resumes.
Unfortunately I was wrong. Tools weren’t the issue. We had plenty of tools, and while most were underutilized, this merely required an investment of time. The problem was community. Our community was dysfunctional, and fixing it would’ve subsumed all problems.
moving on
There are many ways to build quality software in a reasonable amount of time without wanting to scream, but no one solution is a fit for all situations. In my current gig, I’m living in a bit of a utopia. I’ve been a lead on a project for an internal system replacing an older system (it sends email, but that’s not terribly important) for about nine months. I have one extremely well-informed and expert internal client in the marketing department that is the key stakeholder in the project, and because this system is used by many other developers, my colleagues get to try out my APIs and offer feedback. All told, we have the nicest piece of software I’ve ever written. It’s internally successful, delivering results early and being improved incrementally, and a joy to work on. We have tools: the system will bootstrap itself and start running locally with one call to a shell script, the unit tests run all the time, the build server builds the docs (we have docs!), and we’re able to contribute liberally to our shared internal library. And we have just a bit of process, too: releases are often available in a staging environment, we deploy very rapidly, feedback from the internal client is nearly instantaneous, progress is tracked in our ticket system, and we have zero standing meetings (instead preferring to do things with short, ad-hoc, high value interactions at the coffee machine). But even in this same organization I’ve worked on projects that have left me profoundly unhappy, and obviously the approach for my current project won’t always work or scale to other systems. So I’m left trying to identify the things that make development fun and make this project such a success.
This current project reminds me a lot of working in an academic setting. In my pre-“real”-job days, the stakeholders were highly involved, highly informed, and wanted to be working on the same stuff that I wanted to be working on (because we were broke and doing it all for free). But what’s going on now and what was going on then is that we’ve fostered a real sense of community. Sure, we have some constituent elements that are required to build software in a professional setting (tools, process), and we’ve assembled these nuts and bolts in an orderly fashion. But much more importantly, we’ve fostered a sense of mutual respect.
My stakeholder in the marketing department functions as the closest thing to a project manager I have. We plan things out and we repeatedly revise our estimates and expectations. Together he knows that context switching between feature requests slows me down, but I’ve also come to realize that when he asks for something quickly, he’s already thought through the ramifications, and the overhead of the context switch is worthwhile for the business. The key element here is that our relationship is not adversarial. Quite the opposite. I respect his insight into his area of expertise, and he respects mine. I’ve seen so many project manager/developer relationships go south because both parties perceive the other as the adversary. The PM thinks the developer is dragging his or her feet, and the developer is irrationally convinced the that fucking over developers was in the PM’s job description. This makes work suck. This makes software suck. Warring factions can’t collaborate to build something great; warring factions can only destroy.
I’m not sure how mutual levels of respect can be earned or fostered. Of all things, the possibility of this might be the most innate thing in the organization’s human constituents (i.e. we have to presuppose that we’ve hired good people on all sides if this is ever to happen). But, assuming that respect and trust can be built between the nerds and the stake holders over time, there are still some other factors that have to exist to make a happy project. One important thing is continued learning on all sides. Everyone has to be willing to learn new things. Sometimes this means that business types have to learn new vocabulary. The might have to know how a cookie works or what it means for the web to be stateless. And the same holds for developers. We may have to hold our nose at the imprecise language used in marketing meetings and learn some acronyms and business strategies. If an unwillingness to learn exists, the project will fail.
Transparency is also key. Developers need to know how things work. They need to know the background story around the business decisions that went into a project. Likewise, the stakeholders need to see that progress is being made. If we’re building a web app, then the latest stable(ish) release should be available for the business types to tinker with. The transparency helps both sides. Sometimes the analytical nerd brain can raise legitimate business questions. Other times, the stakeholders can stem a failure or misread specification much earlier if they’re interacting with the project on a continual basis.
Finally, fault tolerance and resilience is key to a pleasant project. Both sides, programmers and stakeholders, have to understand that the other will occasionally make mistakes, misread a spec, or be unclear. Again, this can’t be adversarial. For a happy project, we programmers must realize there is no suit and tie cabal maliciously typing away unclear requirements documents. No, just like we forget to add files to version control and fat finger Unix commands, things get misinterpreted and misread. So everyone should be aware that mistakes will happen. Some ideas might have to be delayed, and some 500 pages might be raised. But, if we respond to these quickly, refuse to panic, and fix both types of problems, the project can will continue to be fun and happy. And it will succeed.
sum(it_up)
For me, something like a Project Euler problem is the most satisfying computing exercise. It’s well defined, there is a solution, and I know when I’ve found it. But this is a mirage. Very few computing problems are solved with such simple and clear algorithms. Everything is fuzzy and we rarely go it alone. But if we respect each other along the way, keep and eye on how things are going, and respond to problems as they come we can get closer and closer to a clear solution and enjoy the journey along the way.
Comments !