As a developer, I’m keenly focused on what goes out the door. Who will use my software, and what can they do to break it? How can I ensure the success of the client and their customers’ experiences? These things are pretty universal, regardless of the project. Over the last few years, I’ve come to realize that there are two different kinds of projects. The kind of project has a far greater impact on how I approach the work.
The first kind of project is common in marketing agencies. It involves a defined scope and a handover at the end. It’s a product that we get out the door and we’ll provide some training and some support down the road, but the work leading to launch is the major work for a web developer. After that, the client doesn’t expect to need a whole lot of development. It’s a sprint from start to launch, and there’s an understanding that, at some point, when style or requirements change, another project will be undertaken to replace the first.
The second kind of project is a more complex creature. It’s what I think makes emfluence’s development team stand out, because it in many ways defines the difference between a web developer and a software engineer. I’m talking about big projects – those that involve continual improvement over multiple years, deep impact from multiple disciplines, and an ongoing developer presence. Projects that require investment in relationships. Instead of a sprint, it’s a marathon.
What, from a developer’s point of view, makes big projects a success?
If there’s one thing that matters most in a big project, it’s that it is broken down into small components. This is like writing a series of articles, bound together with an index, instead of one long stream-of-thought novel. To keep each part distinct, it’s absolutely essential that each part clearly identify what is internal versus what relates to other parts. If you’re reading an article, you don’t want to have to cover five other articles to understand it.
Smaller pieces means that the processes of testing, maintenance, and new development are easier. It means that new contributors can be quickly brought up to speed. Code-wise, it’s easier for a developer to understand what he or she needs to work on without having to understand everything from the rest of the project.
Maintaining form involves careful footwork. Cliff notes in the code just don’t cut it. There must be descriptive git commits, readme files, strategic unit tests, and even tooltips in the UI describing how settings interact with each other. It’s necessarily slower than just completing the task at hand, but it’s worth it when the work can be easily built upon or refined later. It’s necessarily slower than just completing the task at hand, but it’s worth it when work can be easily built upon or refined later. It’s what keeps the project getting better while maintaining (or building) momentum.
Clearly, I've got my mind on the codebase. But what about the stakeholders who never look at the code? What about the ongoing process of approaching sub-projects and relating them to the whole? A myriad of aspects, including workflows, UX testing, design, content modeling, infrastructure, and ownership come into play to transform many individuals into stakeholders. Living documentation embodies this side of the project.
Traditional documentation is a reference for anyone coming into a project or re-acquainting themselves with part of it. But living documentation is also a part of the process when creating new things. It helps describe the scope and each contributor plays their part in creating it. Stakeholders buy into the work by helping to describe what it is and what it should be. It is written in many voices, because it represents the parts that combine into a whole – just as a magazine represents the articles of various authors. A developer might suggest a wiki as the medium for this (I have!), but another stakeholder might suggest a solution like Evernote. Ultimately, however, the platform isn’t as important as buy-in from everyone involved.
Living documentation is not a monolithic work, and it’s never complete. There are to-do notes posted all over it, mirroring the questions still to be answered. It documents the state of decisions as much as it documents the contents of those decisions.
The aspects I’ve mentioned here might not be a surprise to experienced developers. It takes the ability to work well in a team and gain a familiarity with other disciplines to become an experienced developer – just as a journalist must be able to interact with many kinds of people in order to write good articles. Emfluence favors these traits in its development team, and we have a long history of both big and small projects.
Personally, I love working on a mix of different-sized projects. There’s a wonderful feeling of satisfaction in getting something really fresh and new out the door. And there’s a great sense of achievement in seeing something grow over an extended period.
Stay tuned for upcoming blog posts in which I talk to other devs about town and get their perspectives on web development!