Sherman On Software Latest

Managers with looming deadlines often tell developers to skip writing tests in order to deliver code faster.  This only makes sense if you don’t believe that unit tests pay off in initial development, or you view the impact of bugs as an externality.

I have encountered extremists who don’t believe that unit tests ever provide value; that’s not the case here.  Managers who want to skip writing tests to deliver faster are less extreme.  They are stating that unit tests pay for themselves over time and that they won’t provide a net benefit until after the first release.

This is not as crazy as it sounds.  Tests become more valuable over time as they allow future developers to refactor with confidence.  You can reason backwards and say that if the test is more valuable in the future, it must be less valuable today.  Right now, the test could even conceivably be worth less the cost of writing it.  And when you need to ship, you cut things that don’t add value.

Which brings forth the second part of the argument: bugs are an externality.

If you deliver a bug ridden project on time, have you succeeded?  Sadly, the answer is usually yes.  Managers get evaluated on delivering on time, developers get evaluated on quality. Managers can believe that tests add value to the code, but they don’t add value to the manager.

By their definition deadlines prioritize short term thinking.  Deadlines encourage managers to make short term tradeoffs at the expense of long term value creation.  When managers push to skip tests, the people who suffer most are customers who have to use the software.  The people who suffer least are the managers who traded tests for time.

Internal tech demos exist so that stakeholders can see and comment on the work being delivered.  Hopefully the demo produces smiles, cheers, and high fives.  Often, the stakeholders will ask questions and make objections that take everything off of the rails.  These can be painful moments; they are also extremely valuable.

Disastrous demos give you at least one of two great pieces of information:

You learn that you were building the wrong thing.  

Having bug free, highly performant code doesn’t matter if it is correctly doing something other than what stakeholders want.  The longer it takes to learn that you’re building the wrong thing, the more time and money you’re wasting.

It sucks to hear you spent a week or two building the wrong thing and need to scrap some work.  It sucks much harder when you’ve spent 6 months heading in the wrong direction.

You learn that you can’t speak to the business value

How you demo reflects your understanding of the software.  I’ve seen many demos where the developers have delivered the right thing, but they don’t understand why.  Software development in knowledge work; “I built what I was told” is the wrong answer.  

You need to know why stakeholders want the software, and speak to it in your demo.  When you have the value wrong the stakeholders will tear the demo apart looking for their business value.

Remember, demos are for feedback

Disastrous demos suck.  Disastrous demos are also successes – you learned something critical about the project that you didn’t know.

Don’t let disappointment distract from learning and improving.

Have you ever been asked to fully estimate a full project so that someone else can decide if it is worth pursuing?  Did the request set off alarm bells in your head?  

It should!  Estimating full projects is a sign that the collaborative process has already broken down!  

Estimating full projects is a trap that prevents developers from bringing their most important skills to bear.  Instead of collaboration towards a common goal, estimation pushes toxic all-or-nothing demands:

• The project has a value, but it isn’t being shared with you.  Instead the project owner is asking for an estimate; and it needs to be less than the project’s value.  If your estimate is above the line, you’ll get pressure to revise the estimate down.  Worse, your estimates will often be ignored and timelines will be dictated.  All so that the project will hit numbers you’ve never seen.
• You are a professional software developer and you have to accept their diagnosis about the software solution.  Is this project the best way to pursue the opportunity?  Could you do it faster and cheaper some other way?  Doesn’t matter; estimate this project.  Your expertise and creative inputs have been rejected.
• The project will be a big bang deliverable.  You’re given a scope of work and asked how long it will take.  The asker wants the full project.  You’ll have to fight to iterate, make small releases, de-risk, or even prove the concept.
• The project scope will always miss some requirements; the larger the project, the larger the miss.  The misses will blow out the timeline, and you will get blamed for missing the estimate.

The alternative is a collaborative process!

Instead of pressure for your estimate to come in below an unknown ceiling, you can scope last.

Instead of pressure for you to accept a project, you can work together to shape the project.

Instead of pressure for you to deliver a giant project in one perfect step, you can work together to deliver iteratively.  

You even save all of the time spent creating a project plan, estimating the plan, and deciding whether the plan is worthwhile!

Pushing back will uncomfortable the first few times.  The first time you have a conversation that starts with “I see this opportunity, let’s talk about how we can seize it”, it will all have been worth it.