Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

iism.org

Post reply on HN
Print view View original

41–50 of 78 posts

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

#41

Post by 35fbe7d3d5b9 »

SketchySeaBeast wrote: post #36
35fbe7d3d5b9 wrote: post #30

Earlier quoted context omitted.

Accurately is the hard part, but you don't have to be perfect here – just as accurate as next year's sales forecast is. "I can't outrun a bear, I just have to outrun you " ;)

To take the metaphor, mangle it, and run with it - The problem is that technical debt isn't being chased by a bear, it's walking through the woods in bear country. It only becomes truly quantifiable when the bear charges you. Until then it's a "could be a problem". We probably don't even know the exact details of what sort of bear is going to come maul us, so it's hard to say "if we don't stop this a brown bear is go…

I don't disagree, which is why my original post talked about pricing technical debt retrospectively. You don't know when the bear will charge tomorrow, but past bear charges can be highly instructive if you learn from them.

My prod ETL process is an unloved mess, and we've had enough maulings occur to learn from it:

* I learned the problem – data models drift in the production app and changes aren't reflected / properly tested in the ETL or the analytics environment. And we don't have enough monitoring in place to catch the problem when it happens in the wild.

* I learned the cost of inaction – my analytics environment is responsible for $10mm of CARR, and I know the impact to customers when it goes down. Heck, I know how much customer credit has been given out due to SLA breaches, so there's a quantifiable price today.

* I learned the price to fix it - we've estimated the effort and run cost of the new solution.

Now I've got something that I can work with: customer acquisition says they've got $4m in the near-term pipeline? OK, great, but if we onboard them with a broken system we risk spending $+x in customer credits and risk damaging our reputation. And since it costs $y to fix it, and $x > $y, let's fix it.

I have plenty of other unloved systems that are in bear country but haven't mauled me (yet), but even then you can start thinking about risks. One system is small but critical for multiple products, so my exposure is "hey every single customer is getting service credits" – expensive enough to force the monitoring/refactoring work that it always needed. One of them serves logins for ~7k users but only for one customer so my financial exposure is bounded. We don't worry about bear spray when walking around there ;)

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

#42

Post by JPKab »

Guthur wrote: 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 don't disagree, but at my last company, I was always very explicit about these things in business terms.

The real enemy I ran into was the SVPs desire to please the CEO who wanted to please the board who wanted to please the investment PR racket and make sure we could tell Gartner that X feature is ready by Y date to ensure we were included in their Magic Quadrant. The answer to the bosses had to be "yes it will be released by Y date". Saw that pattern repeated, realized "Agile" was just a word for waterfall, quit for a startup.

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

#43

Post by titzer »

djmips wrote: post #34
titzer wrote: post #26

> The top two sources of failure in software development projects are failing to discover what is actually needed and failure to eliminate chaos in the software before delivering it to the customer. 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 th…

>"That makes it easy to put functional correctness first and performance second, as it should be." That only works when performance isn't a core deliverable. In my area, that have to be co-developed as it is too expensive to build merely functional and make it fast later.

Oh, believe me, performance of a Wasm engine is a core deliverable.

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

#44

Post by barbazoo »

commandlinefan wrote: post #31

As Dilbert says: "Our boss can't judge the quality of our work, but he knows when it's late".

And just like Scott Adams is so wrong about many things he says, Dilbert is wrong here or at least short sighted too. While you notice immediately that something is on time, you'll also notice really quickly that something is of bad quality, unreliable, inconsistent, low performant, etc which translates in whoever the customer is to be very unhappy very quickly. There needs to be a well-informed balance.

I know you were just posting a funny Dilbert quote but I don't respect Scott Adams anymore so I was triggered, please accept my apologies.

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

#45

Post by barbazoo »

eric4smith wrote: post #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 surv…

That's a great lesson your dad taught you there. I wish I had been taught that early on in my career because it applies just as well to an organization.

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

#46

Post by b3morales »

Isamu wrote: post #37
Guthur wrote: 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…

Middle and upper management are mostly concerned about risk, because the environment they are in rewards being “done” more than trying something that could have a bigger payoff. That is, the downside of accepting risk tends to outweigh the upside of achieving a goal at the cost of running over schedule. In that environment.

Very much this; not least because, having organizational power, they can manipulate the situation to evade the downside. As discussed in the classic Gervais Principle essay: https://www.ribbonfarm.com/2011/10/14/the-gervais-principle-...

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

#47

Post by SketchySeaBeast »

thrower123 wrote: post #39
35fbe7d3d5b9 wrote: post #28

Earlier quoted context omitted.

> Technical debt and code coverage "as risks" cant be factored in either. 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 slo…

People get mad when you start counting up how much salary the hours of meetings about why you aren't moving faster chews up. That daily status meeting that pulls in twelve people for an hour to hem and haw about nothing? That costs $600 every day. $30k a year.

Only $600 for a dozen people? That's only about three people based upon the billable rates I'm familiar with.

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

#48

Post by Jtsummers »

djmips wrote: post #34
titzer wrote: post #26

> The top two sources of failure in software development projects are failing to discover what is actually needed and failure to eliminate chaos in the software before delivering it to the customer. 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 th…

>"That makes it easy to put functional correctness first and performance second, as it should be." That only works when performance isn't a core deliverable. In my area, that have to be co-developed as it is too expensive to build merely functional and make it fast later.

As I had to convince a former colleague, fast but wrong is useless. I can make a very high performance program if correctness is irrelevant. Correctness is the requirement (at least from my professional work), and performance is necessarily secondary. That doesn't remove it as a requirement, but if I'm giving wrong results quickly then planes aren't flying (worst case, they're burning up on the ground and everyone is dead). Performance is obviously important because I've mostly worked on real-time systems. But I can take a correct program and make it fast much more easily than taking a fast but incorrect program and make it correct.

I guess if your work has no consequences correctness can be discarded or rendered a secondary criteria for your programs.

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

#49

Post by vegetablepotpie »

barbazoo wrote: post #44
commandlinefan wrote: post #31

As Dilbert says: "Our boss can't judge the quality of our work, but he knows when it's late".

And just like Scott Adams is so wrong about many things he says, Dilbert is wrong here or at least short sighted too. While you notice immediately that something is on time, you'll also notice really quickly that something is of bad quality, unreliable, inconsistent, low performant, etc which translates in whoever the customer is to be very unhappy very quickly. There needs to be a well-informed balance. I know you w…

I can see that you have not been exposed to the magic of bureaucratic indifference.

If you release a really shitty product, and your customer doesn’t have choice (has no competitor, made a large upfront payment, has fallen into vendor lock-in, etc), you don’t have to respond.

You can translate an unhappy customer into a compliant one by putting up barriers to the reporting and documentation of the issue. Make automated resolutions that don’t quite fit the situation, put the issue into a ticketing system that never addresses the issue, give employees roles that either overlap with each other or don’t intersect at all over the customers issue, etc.

These are the situations that Scott Adams parodies with Dilbert.

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

#50

Post by lnanek2 »

barbazoo wrote: post #44
commandlinefan wrote: post #31

As Dilbert says: "Our boss can't judge the quality of our work, but he knows when it's late".

And just like Scott Adams is so wrong about many things he says, Dilbert is wrong here or at least short sighted too. While you notice immediately that something is on time, you'll also notice really quickly that something is of bad quality, unreliable, inconsistent, low performant, etc which translates in whoever the customer is to be very unhappy very quickly. There needs to be a well-informed balance. I know you w…

> While you notice immediately that something is on time, you'll also notice really quickly that something is of bad quality, unreliable, inconsistent, low performant, etc

Not in my experience. Our team has a couple core perf metrics that are alarmed, like page load and missed frames, but it's easy to do really bad things that won't trigger the alarms. Or do them such that the automated tests are using different content for the pages they test than the real users who will see the commits weeks later. E.g. someone commits a change to feature x that locks up the screen, but the test user pool never uses feature X, or never puts content into it and just sees the empty state screen.

Quite common for developers here to write stuff that works for 99% of users, but falls over otherwise as well. Like today I fixed an issue where tapping a button on one screen to go to another really fast, like under 1 second, crashes because of a race condition. Testers aren't going to notice that. It just shows up in the company's overall crash rate which is spread across 4000 developers. Automatic UI tests caught it, but the responsible team had just filed the crash stack trace JIRA into their backlog and left it to sit for months. Similarly, today, we had a production issue because someone wrote some code that only works for certain users who had already accepted a certain terms of service screen.

Shipping a feature is rewarded heavily. Not screwing up the app for edge cases and perf and people who have to implement the next feature after you? Good test coverage? Not at all. If you dare to give an estimate that includes full test coverage, PMs will just take you off the project and pick a developer who doesn't do that.

Post reply on HN