What I do
Hint: I’m more than a software developer
It’s also expensive. A small software development team (2 good developers and a project manager) can easily cost $250,000/year.
Finally, it’s risky. Studies have shown that most projects are 6 to 12 months behind schedule and 50 to 100% over budget.
We try to deliver software:
- With high quality
- On budget
- On time
I present topics and give talks to help developers and Agile Managers hit those goals.
This site serves as an information resource for .NET Developers and Agile Managers to get a glimpse into how I work in my capacity as an SDLC auditor. This serves as a starting point for further conversation.
On the .NET Developer side, I focus on two topics:
- Staying on track
- Keeping the quality high
- Working with management
On the Agile Management side:
- Be efficient (or ruthless)
- Measure and adjust
There are also some fun articles on the .NET Micro Framework and embedded hardware programming. It’s a side hobby of mine and I love sharing what I’ve learned.
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
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.
Developer technical regression
I love talking to companies about their software development problems. Most issues revolve around employee retention, recruitment and the quality of work. One aspect of recruitment companies don’t understand is developer’s desire to not regress technically.
There is a vast amount of legacy code out there. To me, legacy code is the code upon which the business has been built. That code has been modified over time to suit the needs of the changing business. Successful companies will have legacy code. However, that legacy code has a long-term price attached to it.
Legacy code repels developers
As software developers move jobs, technology moves on. New companies and software developers want to build with the latest technologies and practices. This leaves a real problem for companies with legacy code. How can they attract cutting-edge developers while having a large legacy codebase? In short, they can’t.
Not moving forward is expensive
They will have to look for developers in an ever-shrinking pool of candidates who know those legacy technologies. As time moves on, these developers will become harder and harder to find as they move to newer and newer technologies because that is what the market demands. In short, developers understand that technical regression hurts their employability. Fewer companies want those skills, and those skills will tend to pay less. Here’s short list of national salaries I could find on Dice and Indeed:
|Language||Average Salary||Number of Jobs|
|VB.NET (no C#)||$87,000||1253|
There are many caveats to this data. It’s not scientific and the numbers aren’t entirely accurate. However, it does show the trend. Older technologies pay less. As developers, it is in our best financial interest to move forward. Newer (or hotter) technologies pay more as they gain traction.
Companies must invest in technology updates
Here’s the hard part. It’s in the companies best interest to move forward as well. Just like a new roof on a house, companies should be saving for a capitol reinvestment into their technology. It will extend the longevity of their platform, lead to less employee turnover, and enable better recruitment.
Good developers won’t regress
Developer technical regression is a serious concern for developers who truly love technology. Most will refuse to work on old systems using old technologies. This is the hallmark of a good developer. These developers value their hard-fought skill and want to work for companies which value them.
Companies should follow
Developers should keep moving their skill sets forward. Companies should move forward as well.
Estimating Projects with Agile
NB: Scroll to the bottom for the short version.
I have a 7 year history of managing projects with Agile. Early, I failed because I didn’t practice Agile seriously. The mistakes I made early on in my Agile career are still being made by numerous companies I work with. So, here I’m giving up the “secret” of why following Agile strictly works. It’s an effort to get there but it is worth it if your business wants to achieve the Agile promise of on-time and on-budget delivery.
Doing Agile right
I know, I’m opinionated. Most organizations practice a weak form of Agile. When looking at those organizations find out if they’re delivering higher quality software, on-time, on-budget with measurable business value. Here are the key artifacts you get when doing Agile right:
– Consistent iteration velocity
– Green builds
– Low defect kill rate (92%)
– Automated builds
– Low code duplication percentage (<2%)
You have a well functioning team if you have all of these. You are delivering consistently. You will be able to successfully estimate delivery of a new project. Any estimate padding is more of a security blanket or contingency fund. I use 20% to cover for staff changes, holidays, family leave, sick days, etc.
Your estimates will need quite a bit of extra padding if you are missing some. You may need to pad as much as 100% if you aren’t doing any of these.
Commonly, I’m asked how I estimate projects, in terms of both time and money. This is easy if you have reliable Agile metrics. Here’s the process I use:
Calculating the delivery time
- Estimate the entire story in points
- Find your weekly point velocity
- Divide #1 by #2 to find your realistic delivery time frame
- Calculate the weekly cost of the development team
- Multiply #4 by #5 to find your realistic development cost
- Multiply both values by 1.2 for a 20% padding
- You’ve rough estimated a project for 160 points
- Your current team is getting 8 points a week
- The project will take about 20 weeks (160/8)
- Padded, this is 24 weeks
- Your entire development team costs $250K year (small team!)
- Your cost per week is $4,807
- The project will cost $96,152 (24 * $4,807)
- Padded, this is $115,382 (1.2 * $96,152)
This is very reliable for me. Many of the details require an experienced Agile manager. Skills required for this analysis:
- Calculating points for the stories
* This requires skill and experience
1. Picking a padding factor
* You won’t have all the stories in the beginning. I find that I have about 80% of them though. A 200 point backlog takes me about one week to build.
1. Knowing the average team velocity
* This requires having consistently measured the team.
The three above metrics are built upon solid Agile practice skills:
- Building and maintaining a backlog
- Actionable requirements
- Completing stories on time
- Focus on quality
- Ruthless meetings
Many organizations and teams claim to be “Agile”. 99% of them are not. Hire an experienced Agile manager if you want to deliver high quality software, on-time, on-budget, in a repeatable and measurable way.