«    »

Capability for Software Developers

I have recently been wrestling with the problem of clarifying the concept of capability levels for software developers. What does it mean to call a developer junior versus intermediate? How can a developer at one level progress to the next? How do you evaluate the capability of a developer? These questions and more formed the parameters of my investigation.

Defining Capability

As I researched and reflected on this topic, I came to realize that the central core of the problem consisted of defining what capability means for software developers. Wiktionary defines capability as "the power or ability to generate an outcome". What is the desired outcome for developers?

The first answer that came to mind for me was "creating high-quality software", but on further reflection I realized this was too limited. Developers work as part of a team on a project to develop a piece of software. (I believe this is generally true if you include teams of one person - the developer working by themselves - and include extremely informal projects such as open source software development efforts with no explicitly-defined objectives, scope, budget, or end date.) It is the team outcome based on the project success criteria that matters. Based on the lean philosophy of optimizing the whole system instead of individual components, we need to consider the developer's contribution to the team / project rather than just their efforts in isolation. So how about defining the desired outcome as contributing to the success of the team and project? The problem now is that this is too general. It applies to every role on the team and does not differentiate how a developer contributes versus a tester, business analyst, or architect. The solution is to merge in my initial answer of "creating software" while considering the team context. Developers who mentor other developers and do code reviews are not directly creating software but are still make significant contributions to the team’s ability to create software.

My definition of capability for software developers therefore is the ability to contribute to the success of the team and project through creating software and helping other developers create software.

Evaluating Capability

This definition serves as a good starting point conceptually, but it is not enough on its own to provide clear guidance on how to evaluate developers. I did not want a long list of detailed criteria to use for an evaluation – just a few simple measures that logically derive from the definition.

The first measure is the ability to work independently to produce software. Independently means with a minimum of extra assistance. It does not mean working separated from the team. For example, I believe that all production code should be reviewed by a second developer. Having code reviewed does not affect the measure of working independently. In contrast, having poor quality code that the reviewer has to spend extra time reviewing and re-reviewing after fixes would reflect negatively on the measure.

One way of evaluating this is to determine how much support the developer needs from other team member in terms of the various team roles. Does the developer understand the business priorities and stay focused on the tasks for the most important functionality, or does the team lead or project manager need to spend extra time monitoring this and providing guidance? Can the developer create a functional design for a set of requirements that also meets all the non-functional requirements, or do they need significant help from the architect? Can they trouble-shoot problems, or do they need help from other developers?

The second measure is the magnitude (size/scope) and degree of complexity or difficulty of the work that can be easily performed independently. How hard or complex a task can the developer tackle without getting bogged down or stuck? Can they only handle small, clearly-defined tasks, or can they work on complex algorithms and large modules of an application with ease? This measure may seem similar to the first – both relate to working independently – but it is distinct. I think of this measure as assessing solely a developer's technical ability, while the first measure is broader. Most developers have two thresholds of complexity/magnitude: the first is the point when they need assistance to complete the work, and the second is the point when the task is completely beyond their capabilities.

The third measure is the level of quality of the developer's work. Quality is more than just a low defect count. Quality includes meeting non-functional requirements such as usability, maintainability, and performance in addition to functional correctness. Quality is also not limited solely to the software produced by the developer. Quality should be assessed for all a developer's work including activities like reviewing code, estimating tasks, and writing documentation. I like to use the term craftsmanship to describe this broad definition of quality. Others might prefer the term 'professionalism'. The reason I use the term 'quality' is because in my experience people hold widely varying definitions of the other terms, while definitions of 'quality' tend to be more similar. So asking people to assess developers in terms of quality has proven more useful than using these other, vaguer terms.

The fourth, and last, measure is the amount of assistance the developer provides to the rest of the team. Do they mentor more junior developers? Do they help diagnose a tricky defect? Do they provide advice on using some library? This measure is really assessing two different aspects: the first is the developer's willingness to help, and the second is the developer's ability to help. This second aspect is closely related to the first and second measures. A developer's overall level of ability with respect to the task determines whether they will need assistance, barely get by on their own, or easily do their work and have the capacity to provide assistance to others.


Capability for software developers is the ability to contribute to the success of the team and project through creating software and helping other developers create software. Use the following four questions to assess a developer’s capability:

  1. How well do they work independently without requiring the assistance of others?
  2. How difficult a task in terms of complexity or scope can they handle easily?
  3. What level of quality is their work at?
  4. How much assistance do they provide to the rest of the team?

If you find this article helpful, please make a donation.

«    »