Is management pressuring you to deliver unfinished code? (2020)

On the other hand, in not a trivial number of cases, you'll be working with people who get all the upside when things go right and the blame the tech side successfully when they don't. Their interests do not align with the interests of the business either but since the business side consists of their bros, they all instinctively align on that.

So, you keep talking about "risk", that gets portrayed to upstairs as "I am doing my best, but so and so here is throwing technical minutiae at me which is slowing us down."

They are used to being graded on the curve where your position gets better if everyone else does worse and taking advantage of that system.

Among the many reasons I never graded on a curve, but you can't do that with upper management in business.

I say this as a person who believes business cost/benefit calculations trump everything else. However, decisions must be made by people who understand the tradeoffs and are accountable.

The first one is called requirements gathering (the method, requirements engineering). I was wondering how far I was going to have to read to find someone mentioning that.

It can be as simple as writing down a list of things the software has to do. It could be one afternoon brainstorming meeting, to start. But we don't even bother. Why? Because this discipline is not engineering, not science, not manufacturing. One my darker days, I think we are just playing in the mud.

I am grateful to work on virtual machines and compilers. They at least have functional requirements--an input specification--and a well-specified target machine. The rest in the middle is a fun design exercise, but there is a crucible at the end of the day. If you can't run the programs without bugs, you have failed. That makes it easy to put functional correctness first and performance second, as it should be. We need to find more ways of translating problems into requirements in order to reduce black art to science to practice.

They can be measured. Lots of companies don't, which is mind-boggling.

When a release goes sideways and has to be rolled back, you figure out why. Ah, you launched a feature that revealed an intersection of edge cases in your testing? That's n developers * m hours * p dollars of blended dev salary down the drain.

When your feature delivery slows to a crawl over time, you dig in – your programmers aren't getting worse over time... are they? No, you find that a ticket that took your average developer x hours to deliver at the beginning of your development now takes 2x or 3x. Make a value stream map and you'll find out that your test suite has become so sluggish that your developers can't iterate quickly, that QA now measures regression time in days not hours, and as a result your developers are taking on less work to compensate. X dev hours * Y blended rate in ongoing waste, plus factor in the value of missed sales because of missed features if you want to really put a point on it.

> It's not really about finding the right metaphor it's about lacking a common, shared unit of account.

Name the local currency you get paid in – dollars, Euros, pesos. That is the shared unit of account. If you don't care about it, start walking up the org chart. You won't have to go far before you realize that's what actually matters, and that engineers who can translate technical risks and inefficiencies in their world to dollar values are highly valued.

"I can't outrun a bear, I just have to outrun you" ;)