Live data from Hacker News

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

iism.org

11–20 of 78 posts

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

#11
post #4

One of the problems I have found is that we don't talk the same language when communicating with the business, we use terms like "Technical Debt", "Test Coverage", even "Minimal Viable Product". In my opinion the universal variable across all these is risk, and it's easy for all to grasp what we mean when we say the word "Risk". There is delivery risk, will be get this out in a timely fashion for the market. There is…

I am not versed enough in car things, but it seems to me this would be something maintenance shops nailed down decades ago. How would they convey that your car is lacking maintenance even if you can still drive it to work ? Perhaps we should go with "needs repair" or something like that ? "Risk" feels like insurance territory (which goes along with "there is always some risk"), and a lot of people beautify the notion…

The risk for a shoddy car is that you end up killing someone or get written up and charged with a violation. The risk for shoddy software (in most cases) is that you have an outage and suffer some financial or reputation damage, but that won't put you out of business.

There's laws against bad cars, there's no laws against bad software.

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

#12
post #6

> Unfinished code that is full of race conditions, performance problems, outright bugs and worst of all, poor to non-existent product/market fit. The last one is so different than the rest. Bugs shouldn't even "ship" internally in that they shouldn't really be making it out of feature branches often for some reasonable value of often. But back to the last one, that's something that should be decided with high confide…

The last one is the hardest to get right in my experience. Sometimes you just won’t know until you start asking people to put their hand in their pocket.

I mean there's been a few successful companies like Slack that started off with something completely different before they pivoted. Sometimes market fit takes some experimentation.

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

#13
This article raises some great points but is still trying to close the stable door after the horse has bolted.

If your business is agile, it begins with the style of engagement between you and the customer. Really agile businesses don't deal with absolutes (such as fixed price contracts), instead they accept change at the core.

Accounting hate that, so most businesses aren't agile.

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

#14
post #3

This reads a lot like a lean/MVP manifesto. I would say that there is always a pressure to deliver working code, but that “unfinished” should always be in terms of project scope and not in terms of either functionality or reliability. “Code” is the wrong terminology here. It’s OK to not have every feature implemented. But it’s not OK to ship half-baked, untested functionality, no matter what the “code” looks like.

Conversely, half-assed is ok if you only need half an ass.

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

#15
post #4

One of the problems I have found is that we don't talk the same language when communicating with the business, we use terms like "Technical Debt", "Test Coverage", even "Minimal Viable Product". In my opinion the universal variable across all these is risk, and it's easy for all to grasp what we mean when we say the word "Risk". There is delivery risk, will be get this out in a timely fashion for the market. There is…

You forgot the most important one: the risk of running out of money.

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

#16
post #4

One of the problems I have found is that we don't talk the same language when communicating with the business, we use terms like "Technical Debt", "Test Coverage", even "Minimal Viable Product". In my opinion the universal variable across all these is risk, and it's easy for all to grasp what we mean when we say the word "Risk". There is delivery risk, will be get this out in a timely fashion for the market. There is…

This is a common theme but I don't believe it's true. It mirrors all of those twee blog posts that come up with Yet Another Metaphor for technical debt as if people with MBAs would then just "get it".

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

Risks can't really be factored into decision-making unless you can measure them. Theyre not risks otherwise theyre just black swans waiting to happen (or not).

Technical debt and code coverage "as risks" cant be factored in either. Instead of trying to cargo cult the way "the business" talks or coming up with yet another metaphor we should be coming up with better ways to measure these things so that they can be plugged into an excel spreadsheet.

This is done incredibly badly right now. Most measurable code metrics which proxy things we care about are downright terrible at proxying them (e.g. test coverage). In place of working metrics most businesses (in my experience at least) rely on guesswork and trust in high level executives.

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

#18
My dad who was a quite successful artist back in the day said something I’ll never forget.

“Son, I’d like to work on that painting forever, because for me it’s never finished. But I have to stop and sell it because I have to feed the 3 of you children”.

His sole source of income was his art, and we grew up not wanting anything, because he was pragmatic enough to understand at some point he had to ship his art to survive - even if to him, it was not completed.

That’s why when I heard Steve Jobs say “real artists ship”… I immediately understood at a visceral level what he meant. And iPhones over the years have had countless bugs.

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

#19

Earlier quoted context omitted.

I am not versed enough in car things, but it seems to me this would be something maintenance shops nailed down decades ago. How would they convey that your car is lacking maintenance even if you can still drive it to work ? Perhaps we should go with "needs repair" or something like that ? "Risk" feels like insurance territory (which goes along with "there is always some risk"), and a lot of people beautify the notion…

The risk for a shoddy car is that you end up killing someone or get written up and charged with a violation. The risk for shoddy software (in most cases) is that you have an outage and suffer some financial or reputation damage, but that won't put you out of business. There's laws against bad cars, there's no laws against bad software.

> There's laws against bad cars, there's no laws against bad software.

There's often privacy/data protection obligations, but they seem to be impossibly difficult to get the courts to pay attention to. If the average business owner would find themselves in legal shit every time an external party got access to their data (i.e. just being the victim of a ransomware attack puts you at risk of losing your home), they would probably pay more attention.

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

#20
post #10
post #4

One of the problems I have found is that we don't talk the same language when communicating with the business, we use terms like "Technical Debt", "Test Coverage", even "Minimal Viable Product". In my opinion the universal variable across all these is risk, and it's easy for all to grasp what we mean when we say the word "Risk". There is delivery risk, will be get this out in a timely fashion for the market. There is…

There is another thread on the front page about every engineer having to try out consulting. This is one of the ways to learn how to use language that business gets the point across.

Didn't quite parse your second paragraph. Missing a few words?
Post reply on HN