Anatomy of a Software Development Role: Development Lead
There are a number of roles involved in developing software solutions. The development lead (DL) role is the one that glues together the overall architecture created by the solutions architect (SA) and the developers. Figure 1 shows the positioning of the Developer Lead within a project organizational hierarchy. The development lead is the part of the puzzle that bridges the vision of the architecture with the reality of the code. (If you've not been following the series, you should read Cracking the Code: Breaking Down the Software Development Roles.)
What's a Development Lead?
The development lead is the mid-point in the path between being a developer and being the solutions architect. They are still rooted in the reality of the code and the capabilities of the developers they have working on the project. They were once developers themselves and instead of spending all day every day coding their own tasks they now lead and mentor developers as the developers have problems that they don't understand. Click here to see how the SA fits within the full organizational chart.
The development lead is responsible for fleshing out any of the details in the architecture that the Software Architect didn't spell out in detail and for the creation of program specifications from which the developers work. This process refines the SA's vision and makes it more practical. This process is much like the selection of materials for the building of a house. The SA specifies a sturdy exterior to withstand the elements. The DL specifies brick and which type should be used in the facing of the house, someone else actually installs the bricks. For a development project the DL chooses the methodologies and techniques that will be used by the developers to solve specific problems.
Whether the development lead has formal responsibility for the developers on an organizational chart or not, they will be the ones who will direct the day-to-day activities of the developer. In many organizations the development lead isn't burdened with the formal administrative management of employees, they are instead freed to focus their time on helping developers be successful.
Getting Started as a Development Lead
The best way to become a DL is to become a good programmer, one who is constantly evaluating the right ways to create solutions and one who's able to see the patterns at work in the architecture. The title may change from Developer to Development lead or programmer analyst, however, that's not generally the first thing that happens. Generally it's the process of how coding is approached that happens first.
The DL role is one that starts with the mastery of key skills of a developer and adds to that the ability to convert concepts into deliverable solutions. The developer must look beyond the tasks that they're doing and see the ability to create more reusability in the work they're doing. Developers who are trying to move forward into more efficient and thoughtful ways of doing things will be given more responsibility and will move forward into the development lead role. The transition from developer to development lead may happen in as few as three years but more frequently takes six or more years. This is due in part to the broader range of experiences that the DL requires.
What's in their Toolbox?
The toolbox of the development lead is much like the junk drawer of the average household. It contains a wide variety of implements that can be used in a variety of ways. Most of those implements, however, spend months languishing in darkness only to be revealed when the need arises.
The development leader is constantly creating program specifications. Often the most used tool, the one that may never get put back into the junk drawer, is the word processing program. Because of this there's almost always a copy of a word processor running on their workstation. The specific skill that the development lead possesses - which others in the process may not - is in the ability to rapidly create many small documents. Where others in the software development process are focused on creating larger more far reaching documents the development lead creates a multitude of program specifications for developers that are quite focused in their nature.
One of the other unique characteristics of the DL role is their need to leverage other kinds of media in their documents. Program specifications require flowcharts, class diagrams, Entity Relationship Diagrams (ERDs), and a variety of other visual techniques to clearly convey the DL's meaning to the developer. That means they become adept at adding in Visio diagrams, drawing objects, and any other kind of visual device to help the developer see what is expected.
The development lead spends a great deal of time managing the development process. The most commonly used tool to do this is a source code control system. Solutions like Microsoft Visual Source Safe, CVS, Subverson, and other more robust tools allow the tracking of what code has been checked in by whom and what the differences are from previous versions. The reason the development lead spends so much time in the source control system is that it provides a tangible way to assess progress of every developer that the DL is working with. It also provides a way for continuous code reviews to make sure that the developer is both delivering what the specification calls for and is following appropriate coding standards.
In addition to spending time with source code control systems, the developer lead is also a primary person involved in source code walkthroughs. In fact, they are often the lead person in walkthroughs. These code walkthroughs are designed to help the DL understand the code that is in the system so they can ensure its quality but also serve as an opportunity for the DL to help coach, train, and mentor budding developers in ways of thinking about the code more deeply and more thoroughly. Although relegated to a trivial part of the process in many organization the code walkthrough or code review is an important part in both the quality of the system being built and the long-term development of the developers who are working on the project.
As we start to dig deeper into the back of the proverbial junk drawer we run into configuration management. This is the tool or set of tools that good development leads periodically pull out to validate that their development environment matches their testing environments, which in turn match their production environments. These tools are also used to evaluate whether the environment has changed. They start out with a baseline run and then after that each subsequent run is evaluated for changes against the baseline. This tool is most often pulled out during troubleshooting exercises when it's unclear what's changed from a time when the code was working to now, when the code no longer works. Skilled DLs also pull these tools out on a periodic basis to make sure they understand the changes and work to establish a new baseline.
The final tool in the toolbox isn't a tool at all. It's more of a grab bag of techniques and tools that are used to support the troubleshooting and diagnostic purposes. DLs are often called to support troubleshooting efforts in production systems as well as the continuous barrage of support requests from the developers. A good DL always has a set of tools that they can use to isolate the problem. These range from a working knowledge of the tools built into the operating system, to a set of testing tools that have been built for testing various pieces of the infrastructure, to tools purchased for troubleshooting. These tools include profilers, memory checkers, debuggers, and more. The specific set of tools that each DL has is slightly different, however, each will come prepared to start troubleshooting a wide variety of problems.
One of the characteristics of a development lead is their ability to create their own tools when no tools exist to solve their problem. Their toolbox may be much like a junk drawer in that you never know exactly what will be in it. You can, however, almost always guarantee at least a few of the tools will be their own unique creations.