Is management pressuring you to deliver unfinished code? (2020) • Hacker News Board

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

#61

Post by 35fbe7d3d5b9 » Thu, Sep 16, 2021, 6:27 PM UTC

H8crilA wrote: post #53

Here's a question: why do you, as an engineer, care? You're just an employee, it is the upper management's role to make sure your company moves forward, maintains the trust of clients, has reliable enough solutions. If they decide to sacrifice quality for speed that's their problem/decision. Really. You were hired to provide technical solutions within specs, and if specs require fast completion more than quality then…

The fastest way to cap your career growth is to think about yourself as someone whose role is to take a spec and provide a technical solution inside that box.

Upper management values – and pays accordingly – people who go beyond that. Learn some finance, learn to mentor others, learn to talk with a customer and understand what they're really after. You'll gain trust and find that you're being pulled into things far earlier in the development pipeline, which often puts you in a place to build better products.

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

#62

Post by hateful » Thu, Sep 16, 2021, 6:29 PM UTC

H8crilA wrote: post #53

Here's a question: why do you, as an engineer, care? You're just an employee, it is the upper management's role to make sure your company moves forward, maintains the trust of clients, has reliable enough solutions. If they decide to sacrifice quality for speed that's their problem/decision. Really. You were hired to provide technical solutions within specs, and if specs require fast completion more than quality then…

If you're the kind of developer/programmer that cares about their work, then your company probably doesn't know how lucky they are.

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

#63

Post by 35fbe7d3d5b9 » Thu, Sep 16, 2021, 6:30 PM UTC

pdkl95 wrote: post #52

JPKab wrote: post #42

Earlier quoted context omitted.

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…

"How a plan becomes policy" http://web.mnstate.edu/alm/humor/ThePlan.htm This poem is my favorite description of this pattern, because it focuses on the the bad communication that creates the problem. Regardless of the intent of the people involved, gradually filtering out important information at each level as people try to please their superior guarantees a GIGO mess for the that the people at the top. As the poem…

http://www.art.net/~hopkins/Don/unix-haters/tirix/embarrassi...

> I wrote a note in sgi.bad-attitude about the "optimist effect", which I believe is mostly true. In condensed form:

> Optimists tend to be promoted, so the higher up in the organization you are, the more optimistic you tend to be. If one manager says "I can do that in 4 months", and another only promises it in 6 months, the 4 month guy gets the job. When the software is 4 months late, the overall system complexity makes it easy to assign blame elsewhere, so there's no way to judge mis-management when it's time for promotions.

> To look good to their boss, most people tend to put a positive spin on their reports. With many levels of management and increasing optimism all the way up, the information reaching the VPs is very filtered, and always filtered positively.

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

#64

Post by RobRivera » Thu, Sep 16, 2021, 6:32 PM UTC

35fbe7d3d5b9 wrote: post #61

H8crilA wrote: post #53

Here's a question: why do you, as an engineer, care? You're just an employee, it is the upper management's role to make sure your company moves forward, maintains the trust of clients, has reliable enough solutions. If they decide to sacrifice quality for speed that's their problem/decision. Really. You were hired to provide technical solutions within specs, and if specs require fast completion more than quality then…

The fastest way to cap your career growth is to think about yourself as someone whose role is to take a spec and provide a technical solution inside that box. Upper management values – and pays accordingly – people who go beyond that. Learn some finance, learn to mentor others, learn to talk with a customer and understand what they're really after. You'll gain trust and find that you're being pulled into things far e…

ive had issues with management paying me accordingly. lucky me in obsessed with mentoring

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

#65

Post by trhway » Thu, Sep 16, 2021, 6:38 PM UTC

35fbe7d3d5b9 wrote: post #61

H8crilA wrote: post #53

Here's a question: why do you, as an engineer, care? You're just an employee, it is the upper management's role to make sure your company moves forward, maintains the trust of clients, has reliable enough solutions. If they decide to sacrifice quality for speed that's their problem/decision. Really. You were hired to provide technical solutions within specs, and if specs require fast completion more than quality then…

The fastest way to cap your career growth is to think about yourself as someone whose role is to take a spec and provide a technical solution inside that box. Upper management values – and pays accordingly – people who go beyond that. Learn some finance, learn to mentor others, learn to talk with a customer and understand what they're really after. You'll gain trust and find that you're being pulled into things far e…

It's the fastest way to learn to understand your career limits, stop worrying and start to love what is possible to love in that job

>Upper management values – and pays accordingly – people who go beyond that

They love when many do that while they pay accordingly only to the very few in order to entice the others.

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

#66

Post by majormajor » Thu, Sep 16, 2021, 6:42 PM UTC

35fbe7d3d5b9 wrote: post #61

H8crilA wrote: post #53

Here's a question: why do you, as an engineer, care? You're just an employee, it is the upper management's role to make sure your company moves forward, maintains the trust of clients, has reliable enough solutions. If they decide to sacrifice quality for speed that's their problem/decision. Really. You were hired to provide technical solutions within specs, and if specs require fast completion more than quality then…

The fastest way to cap your career growth is to think about yourself as someone whose role is to take a spec and provide a technical solution inside that box. Upper management values – and pays accordingly – people who go beyond that. Learn some finance, learn to mentor others, learn to talk with a customer and understand what they're really after. You'll gain trust and find that you're being pulled into things far e…

Upper management won't value you constantly disagreeing with them on risk/reward tradeoffs like "how finished does the code need to be" or "how many bugs are OK for now." Maybe they say "yes, but if we don't get it done by the deadline, we might lose $LARGE_NUMBER in business because..." After that point, there's a difference between seen as usefully raising a concern and being stubborn and annoying.

Or, possibly upper management is just clueless to the cost of the bugs that are shipping. But you still probably won't get far if you just say "this is too buggy" and can't show them why they're wrong and you're right about it harming the business. Maybe you can persuade them if you go get some data. Maybe not.

Ultimately, if the kind of software they want doesn't line up with the kind of software you want to build, don't expect to get rewarded for constantly complaining about it. You're probably better off finding a place where you align better in terms of what type of software they want to ship.

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

#67

Post by jbuhbjlnjbn » Thu, Sep 16, 2021, 6:46 PM UTC

archeantus wrote: post #58

I loved the build up in this article, but the solution left me wanting more. My org suffers from the disease of Date Driven Development, but just telling my boss to let us work until it is done simply means we will never ship because it will never be done. Literally the list of new feature requests from product is a mile long. So where do you draw the line? And once you draw the line, how can you justify pushing off…

Simple: differentiate between basic feature maturity and additional optional features. You release a working product, then you add working functionality over time. This is what the successful software companies do today anyways.

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

#68

Post by majormajor » Thu, Sep 16, 2021, 6:46 PM UTC

pydry wrote: post #16

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…

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…

I've never really seen tech debt cause an immediate, hugely-costly single event where you could say "see, that was the risk we were taking."

I've seen it frequently slow feature development down, though.

But... I've also seen a lot of rewrites fail to improve feature development speed.

So until we, as a discipline, can quantify and predict development speed w.r.t. shitty vs good code, it's going to be a tough conversation that'll rely on persuasion and gut estimates.

We normally can't even predict how expensive (time-consuming) doing that rewrite that we want to do would be! Let alone the benefit!

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

#69

Post by macevilc » Thu, Sep 16, 2021, 6:52 PM UTC

H8crilA wrote: post #53

Here's a question: why do you, as an engineer, care? You're just an employee, it is the upper management's role to make sure your company moves forward, maintains the trust of clients, has reliable enough solutions. If they decide to sacrifice quality for speed that's their problem/decision. Really. You were hired to provide technical solutions within specs, and if specs require fast completion more than quality then…

This advice is soo very wrong. As a programmer you need to think first. The code you write is gonna affect your life maintaining it. So it does affect you or some other developer maintaining it. By actually caring you make things easier for you and your peers and that helps you grow your career.

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

#70

Post by Jtsummers » Thu, Sep 16, 2021, 6:55 PM UTC

archeantus wrote: post #58

I loved the build up in this article, but the solution left me wanting more. My org suffers from the disease of Date Driven Development, but just telling my boss to let us work until it is done simply means we will never ship because it will never be done. Literally the list of new feature requests from product is a mile long. So where do you draw the line? And once you draw the line, how can you justify pushing off…

Take an incremental approach.

Establish the core needs, what must be shipped as a basic system, and ship it. Then extend over a series of iterations where you incorporate more needs and wants. You won't totally avoid the deadline, but you will mitigate one of the deadline problems: All-or-nothing.

If you establish a deadline 1-3 years from now it is expected the entire system will be finished on that date. Well what if it's not? Establish quarterly releases (or more often, especially if you can work with the team deploying the system like if you're an internal dev shop) and aim for a first release in a few months that hits the essentials. Everything else is an extension, you may still take 1-3 years (or longer) but you'll be releasing and getting value from the system right away.

I've even done this with safety critical real-time systems in my work. We built what was necessary for flight test, but not desirable for operations (missed a few needs, a lot of wants). By the time the plane was rolling off the factory floor for release to airlines, we had all the needs covered and most of the wants. The rest of the wants were covered in the next year or so as well as some newly discovered needs. But if we'd waited to have everything done, the plane wouldn't have been delivered to customers for several more years (because flight testing would have been delayed by about 3 years).