What I do

Hint: I’m more than a software developer

Software delivery is hard. There are many tiny details that need to be considered, technologies to master, and business cases to SDLC Practicelearn. Delivering working software is a huge challenge.

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:

  1. With high quality
  2. On budget
  3. 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.



Latest Post

Remove roadblocks instead of hiring more developers

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.

Developer technical regression

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.

Legacy Code

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
Visual Basic $85,000 296
VB.NET (no C#) $87,000 1253
C# $106,000 7790
Node.JS $117,000 409

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

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

  1. Estimate the entire story in points
  2. Find your weekly point velocity
  3. Divide #1 by #2 to find your realistic delivery time frame
  4. Calculate the weekly cost of the development team
  5. Multiply #4 by #5 to find your realistic development cost
  6. Multiply both values by 1.2 for a 20% padding


  1. You’ve rough estimated a project for 160 points
  2. Your current team is getting 8 points a week
  3. The project will take about 20 weeks (160/8)
  4. Padded, this is 24 weeks

Calculating cost

  1. Your entire development team costs $250K year (small team!)
  2. Your cost per week is $4,807
  3. The project will cost $96,152 (24 * $4,807)
  4. 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:

  1. 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:

  1. Building and maintaining a backlog
  2. Actionable requirements
  3. Completing stories on time
  4. Focus on quality
  5. Ruthless meetings
  6. Dedication
  7. Commitment

Nota Bene:

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.

Older Entries »