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 hereto 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.
Where’s the position heading anyway?
The path forward for a DL is directly into the SA role. The skills of the SA are very similar to those of a DL and vary only by experience, breadth, and responsibility. Movement to the SA role is simple but difficult. Because there are relatively few SAs in the world, even fewer than there are DLs, the path up is largely about being in the right place at the right time to make the advancement.
Of course, the willingness to take a larger portion of the development lead work, the willingness to help out and support the SA when they get overwhelmed, and a willingness to take on challenging projects will certainly help.
The bad news about the DL role is being squeezed. SAs are sometimes being forced to take positions as DLs leaving fewer positions available for truly qualified DLs to fill. The movement towards global software development is changing the way that the DLs must think and operate in ways that make it more difficult to do a quality job and to distinguish themselves from regular developers.
The market continues to consume more and more developers bringing hope to the need for the position. The resurgence of interest in the software development lifecycle is once again helping organizations of every size to realize the value that a few key roles can play.
The Good, the Bad, and the Ugly
With any position there are good things, some bad, and a few ugly. The development lead position is no different.
- Good: Position with advancement – The solutions architect role is just a hop, skip, and a jump up the proverbial corporate ladder. The solution architect role only requires a bit more experience and a few more skills. It’s easily within reach of a development lead.
- Good: If a developer likes to code, then the Developer Lead role allows them to be promoted and yet still be able to spend some of their time coding if they want.
- Bad: Monkey in the middle – The position has the potential to get struck between the grand vision of the solution owner and the reality that is available from the developers on the project. Occasionally, that gap is to far for anyone to bridge.
- Bad: Keeping up with new technology, while enjoyable, can be time consuming.
- Ugly: When there is more “hands-on” coding to be done than there are regular developers, then the Developer Lead is usually the first person pulled onto coding.
- Ugly: The DL can be presented with a great vision but do not have the technology (due to cost or politics) or products to implement it effectively.
Conclusion
The DL role is a pivotal one that is both a natural progression from the developer role and a step away from the solution architect role. With their feet grounded in the world of code and their brains thinking about how to make things better they are the critical link between the vision of the SA and the reality of the project. Despite the challenges the DL role is a very rewarding one particularly as you see projects come together and developers get better at their craft.
About the Author
Robert Bogue, MCSE (NT4/W2K), MCSA:Security, A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+ has contributed to more than 100 book projects and numerous other publishing projects. He writes on topics from networking and certification to Microsoft applications and business needs. Robert is a strategic consultant for Crowe Chizek in Indianapolis. Some of Robert’s more recent books are Mobilize Yourself!: The Microsoft Guide to Mobile Technology, Server+ Training Kit, and MCSA Training Guide (70-218): Managing a Windows 2000 Network. He was honored to become a Microsoft MVP for Microsoft Windows Server – Networking. You can reach Robert at Robert.Bogue@CroweChizek.com
