As Dilbert says: "Our boss can't judge the quality of our work, but he knows when it's late".
Is management pressuring you to deliver unfinished code? (2020)
31–40 of 78 posts
Re: Is management pressuring you to deliver unfinished code? (2020)
#32This 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.
> This reads a lot like a lean/MVP manifesto
It also reads like the Agile manifesto from 20 years ago, which caused a huge splash when it was first published - before it was misinterpreted by everybody who might have been able to actually apply it to obtain results as "do exactly what you've always been doing (especially in terms of fixing a delivery date long before you describe what the software is supposed to do), but use terminology like 'sprints' and 'standups' to do it".
Re: Is management pressuring you to deliver unfinished code? (2020)
#33Not to be thrown into semantics but...
Scope vs. Goal
The goal defines the scope.
If the goal does not change, neither the scope.
When the goal includes a date...the scope has no way
to adjust because scope refers, simply put, to a to-do list. A poorly conceived date does not change the scope,
it cuts short the to-do list.
How long does it take to a Nascar Team to win the Indy 500? 500 miles as fast as humanly possible.
Re: Is management pressuring you to deliver unfinished code? (2020)
#34> 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.
Re: Is management pressuring you to deliver unfinished code? (2020)
#35Half finished work they would never do su
Re: Is management pressuring you to deliver unfinished code? (2020)
#36Earlier quoted context omitted.
>Name the local currency you get paid in – dollars, Euros, pesos. That is the shared unit of account. Good luck trying to accurately measure technical debt in dollars.
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 going to come out and get us".
Re: Is management pressuring you to deliver unfinished code? (2020)
#37One 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.
Re: Is management pressuring you to deliver unfinished code? (2020)
#38One 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 agree with you, and I think it's just as frustrating when the decision makers don't document and communicate risk "down the chain", instead packaging up tasks for the implementers and expecting them to have the same sense of priorities, or to rediscover all the nuances of their design decisions during development, etc
Re: Is management pressuring you to deliver unfinished code? (2020)
#39Earlier quoted context omitted.
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 ju…
> 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.
Re: Is management pressuring you to deliver unfinished code? (2020)
#40A rational manager would scope projects with their technical leaders AND senior engineers who will ultimately execute. This scoping must happen before selling the project and also constantly throughout the lifecycle of the project.
Then, the rational manager would also manage expectations with other stakeholders, not committing to things they cannot see the end to.
But most managers are not rational and do the complete opposite. They want to "appear" amazing managers to other stakeholders while simultaneously bringing their "ego" in discussions with team leads and senior engineers.
Nobody is happy with such managers. I think a better org structure would be managers reporting to senior engineers instead of senior engineers reporting to managers.
Senior engineers are responsible for the implementation. Managers merely act as assistants delivering messages everywhere.