Hiring developers might not be what you need
Hiring software developers hasn’t been this hard since before the dotcom bust. I talk to companies everyday which are trying (unsuccessfully) to recruit more developers. Often, they don’t need more developers. They need to remove roadblocks instead of hiring more software developers. This enables the team to deliver high-quality software, on-time, on-budget, in a repeatable manner.
Fix the Development Roadblocks
The two most common roadblocks I encounter in software development are:
– Poor requirements
– Code not being fully functional
Poor Requirements
The quality of the requirements is a strong indicator of product management experience. Requirements being “actionable” is a major factor for success of a project. This requires, a complete understanding of the feature to be built, the cost, and the priority.
Too often, requirements are poorly documented or communicated to the development team. This leads to assumptions or communication churn in the team. In the end, there’s a vision mismatch between business expectation, customer need, and development’s desire to deliver.
Code not being fully functional
Code issues result from poor requirements, coding quality, and regressions. Each has it’s own solution and outcome but are all cataloged as defects or blocked progress. I catalog the type of issue when identified. This gives the organization visibility into the types of issues the team encounters and a clear target for roadblock removal. For instance, a poor requirement issue could have the following causes:
- When a defect is cataloged
— Missing requirement
— Missing dependency - When a story is blocked
— Missing asset
— Missing feedback
Code quality issues are caused by a myriad of issues. Ultimately, they are the result of inexperienced staff and poorly-formed technical standards. I refer to this as “guard rails”. The team should understand the boundaries of what tools and techniques the team use. This will result in reduced mixed-metaphors, green builds, and other measurable targets of quality.
Regression defects are devastating to businesses. In my experience, the best way to reduce regression defects is to measure code coverage. Coverage needs to be measurable at the developers work station. Any reduction in code coverage should result in a failed build. The result is code coverage is always increasing. Running all tests, all the time, with very high code coverage is the best way to reduce the introduction of regression defects.
Measure and target roadblocks
We can identify actionable areas for improvement by measuring the team’s throughput and work quality. This allows us to enable the entire organization to product higher quality products in a more repeatable manner. I find that without targeting these bottleneck issues hiring more developers is a waste of money.
