[HN Gopher] Driving engineers to an arbitrary date is a value de...
___________________________________________________________________
Driving engineers to an arbitrary date is a value destroying
mistake
Author : signa11
Score : 180 points
Date : 2020-05-07 14:47 UTC (8 hours ago)
(HTM) web link (iism.org)
(TXT) w3m dump (iism.org)
| typl wrote:
| Bob Martin's new book "Clean Agile" covers this topic well. The
| problem isn't dates or deadlines, it's arbitrary dates or
| deadlines that are not backed up by data that indicates whether
| or not they are achievable. Often we create estimates with no
| prior knowledge of the team composition and particularly their
| ability to apply their skills to the problem at hand. The only
| way to make good estimates is to give them work, let them start
| doing it, and observe their progress. You then can manipulate the
| scope of your project to determine what you want done (the
| highest value things) and estimate when you can get those things.
| The alternative levers (add a bunch of people, sacrifice quality)
| end up not working in software projects and become the "value
| destroying mistakes."
| hvs wrote:
| What ever this is, the use of colors, arrows, bad clip-art, and
| everything else just yells, "DON'T LISTEN TO ME."
| throwaway3563 wrote:
| The slide at the bottom has "non-technical executive hocus-
| pocus" written all over it but I thought the rest of the
| content was sound.
| wwarner wrote:
| I think the article lacks nuance. Of course, asking devs to guess
| at how long something will take at the very beginning of a
| project is not going to be very accurate. That doesn't mean that
| sticking to a schedule has no value.
|
| Basically, the project plan has to allow for some scope cutting
| along the way. There will always be a few false assumptions that
| are discovered only after the project is well underway, and the
| only way to manage that is minimize the surface area of any given
| dependency.
|
| The responsibility of delivering a project on time belongs to the
| manager (which for the purposes of this comment can belong to an
| IC if she or he decides to think like a manager). For every
| milestone on the schedule, the manager should know all the risks
| for reaching the milestone and should have a plan for handling
| each eventuality.
|
| This type of planning goes hand in hand with protecting the team
| from distractions, preventing scope creep at all costs, and
| setting the goals of the project before it has even started.
|
| Software created with time constraints is higher quality and is
| more fun to make.
| madeofpalk wrote:
| > While it is true that a narrow set of low value software
| projects are tamable with a Gantt chart, high value software
| projects that fill previously unmet needs do not lend themselves
| to being tamable by predictive scheduling techniques.
|
| I think the author vastly overestimates the value and importance
| of project that most developers work on. I don't think I've ever
| worked on anything that I could consider "high value". I've
| worked in big (and small) companies, working on Big Important
| Projects, but if I'm being realistic I think the overall value
| and actual importance is actually quite low.
|
| Other than that, I think the essay has a fatal misunderstanding -
| it's not about setting deadlines, but it's about estimating what
| it costs to do build software. This is useful because it helps us
| guess when it would be done, how much can be delivered, etc.
| fsloth wrote:
| You need some estimates if you need to sync the efforts of two or
| more teams. For single teams with single deliverable there might
| be a necessity to set a date, or might not.
|
| But if there is no _external reason_ to push for a date then
| setting an arbitrary internal date when it provides no additional
| value is just silly.
| [deleted]
| convolvatron wrote:
| been thinking about this because my current project has
| suffered from management repeatedly setting unreasonable dates.
| which causes flailing to get stuff put in, and then we the date
| finally gets moved out, more stuff to paper over that crappy
| stuff.
|
| but you have to admit that without a date developers will just
| noodle around forever.
|
| I think the only recourse is to constantly be evaluating the
| current slate and the date and keep sliding it out as necessary
| or throw stuff off the train.
|
| really, you should never miss a date. you should have realized
| some time ago that it wasn't going to happen and slid it out
| already.
| Twisol wrote:
| > you have to admit that without a date developers will just
| noodle around forever.
|
| This seems more a statement about extrinsic motivation than
| dates in particular. Dates are the most obvious blunt
| instrument for applying extrinsic motivation, but there are
| others.
|
| Intrinsic motivation is in some ways even better. You can't
| force someone to be intrinsically motivated to achieve
| something... but pushy dates and expectations can decimate
| any motivation that was already there.
| uberdru wrote:
| The lost art of 'scoping'.
| wwarner wrote:
| Contrast with Patrick Collison's essay on the value of speed.
|
| https://patrickcollison.com/fast
| temac wrote:
| This is not an essay, this is a bunch of anecdotes.
|
| So projects that worked reasonably well and developed very
| fast, or even just somehow fast, are presented. Everybody
| agrees that's good and a success and better than if they were
| done slower; but so what?
|
| Some are great major engineering projects, but in the context
| of extreme speed there is a world between a few weeks or even
| months, and more than 5 years, even if you compare the 5 years
| in question to project that are a parody in the other direction
| (yeah, a train project that is planned for 37 years looks
| ridiculous, but again so what? is it really because diva
| engineers want to spend all their careers doing "perfect" stuff
| and reject any deadline they are presented? doubtful)
|
| Also, some are successful, but controversial (JS...); some I
| don't even know what to think about (is growing the population
| of a city by 22% in a year good?); some are just the work of
| geniuses.
|
| And this is a mix of major physical infrastructure/engineering
| projects, projects for mass produced physical goods, and random
| software projects. Then suddenly the discussion focuses on
| physical infrastructure, ignoring all the other kind without
| even stating why.
|
| This is also hard to contrast with the original article,
| because we don't know how many of them were mainly date driven.
| Probably not so much, in the sense that it would be retarded to
| insist on delivering something that cost a shitload of money to
| build at a completely arbitrary date without enough concern
| about the quality.
|
| Too finish: some insane major infrastructure projects have been
| successful in the modern age: what comes to mind is for example
| the LHC, yes it took quite some time but it is probably
| somewhat more difficult to design than a random consumer
| electronic gadget? (is the story of the iPod that much
| spectacular? I found it quite common...)
| dasil003 wrote:
| This post highlights the importance of competent technical
| management. The problem is not arbitrary dates, it's unreasonable
| dates with inappropriate feedback loops and lack of trust
| throughout the management chain. The example given is a strawman
| of a classic cigar-chomping executive whose philosophy comes
| largely from unskilled, fungible-labor economies.
|
| Taking away the date is definitely not the right move. Now you've
| given every PM and sales guy carte blanche to throw whatever
| flavor-of-the-moment idea comes in their head. The team will be
| churning constantly to keep up with the requirements and then
| someone will suggest, "I know, let's do scrum!" so now we can all
| enjoy the stress of unreasonable deadlines on a continuous rather
| than waterfall basis.
|
| To the contrary: a properly-managed date is an incredibly
| valuable constraint which the entire team can use to make
| tradeoffs against. To make it work management needs to trust the
| team, and engineers need to understand the larger business
| picture because they are the ones with the knowledge to find
| creative solutions that _actually work_ and decrease time to
| value without compromising technical quality or long-term
| maintainability.
| MattGaiser wrote:
| > Now you've given every PM and sales guy carte blanche to
| throw whatever flavor-of-the-moment idea comes in their head.
|
| YES! My current project has this issue. There is no deadline
| for my project beyond "urgent" (but so is everything else) and
| as a result, any request from a client gets approved. Client
| wants a button shifted slightly to the right? Approved. Comms
| wants the semi-colons gone? Approved.
|
| For a supposedly urgent project, we are making no real progress
| week after week on functionality simply because urgent has no
| tangible meaning.
| DangitBobby wrote:
| That's not solved by adding a date. That's solved by blocking
| feature requests. I'm in a project with the same problem,
| BTW. It's incredibly demoralizing.
| mjevans wrote:
| Change Request == MONEY, and all prior deadlines extended.
| How much depends on the complexity required to perform the
| change... and figuring that out is a billable item too
| (please submit change requests in bulk to save).
| jerf wrote:
| "In preparing for battle I have always found that plans are
| useless, but planning is indispensable." - Dwight D. Eisenhower
|
| Took me some years to fully internalize this, but I endorse it.
| war1025 wrote:
| Related, when I was in school, I always took meticulous notes
| during class. But I never looked back at them.
|
| I.e. Notes are useless, but note-taking is invaluable.
| renewiltord wrote:
| How funny, I took notes for a class to A/B test this and
| note taking ruined my ability to internalize data. When I
| wasn't taking notes, concepts would fly into my head as I'm
| writing an exam along with the associated memory (where I
| was sitting that day, whether it was bright out, where the
| lecturer was standing wrt board). When I took notes, I had
| all these notes and none of this would happen.
|
| I used pen/paper. I also tried, separately, computer-based
| stuff and that ruined my ability to concentrate.
| war1025 wrote:
| For me the note taking helped with the internalization
| process of linking the information with the memories of
| the professor talking about the lesson.
|
| I think the key is to still allow your mind to wander and
| build the connections. I found I always had the best luck
| if I was a little distracted, but mostly paying
| attention.
|
| Perhaps because the variations in attention helped to
| differentiate which information felt important vs what
| was just background noise.
| renewiltord wrote:
| Interesting. Ah well, the time has passed on that front.
| FigmentEngine wrote:
| agreed. i wanted to build something, and set myself a 90 (end
| of quarter) target. it really focused me on just doing what
| needed doing. my plan did not survive long, but i kept
| updating it to focus on what mattered. in the end i hit my
| abitary date, but i carried on tweaking for another 30 days
| before i was really happy. so reall a 33% overrun.
|
| so having a date matters, just "dont do something stupid to
| hit a date" what i built:
| https://moca.computingarchitectures.com/en/~hello-world/
| routerl wrote:
| I recently found myself in the position you described, to a T.
| And we did end up switching to scrum...
|
| I've left that company after having been unable to fix the
| situation, which was ultimately a political problem; as you
| said, we had an "executive whose philosophy comes largely from
| unskilled, fungible-labor economies". Is this fixable, or is
| "leave" the only right answer?
| AnimalMuppet wrote:
| No, "leave" is not the only answer. "Fire the executive" also
| works.
|
| But to actually make that happen, there has to be someone
| with authority do actually do the firing, and that person
| needs to understand the problem...
| [deleted]
| ownagefool wrote:
| I'd probably generally disagree. Lose the date but sell the
| mission. Engineers that get lost in a world perfect is the
| enemy of good need to be reminded of the mission not stressed
| into cutting even more corners for the date.
| DangitBobby wrote:
| Exactly. People are terrible at estimating things on long
| time scales. If an engineer isn't overly optimistic with
| estimates, management will force them to revise until they
| are. Unrealistic optimism despite heaps of evidence is a
| major human flaw. Adding pretend timelines is a stressful
| exercise in futility. But planning itself is not.
| emeerson wrote:
| Strongly agree with this. Dates serve a critical goalpost in
| technical planning, yet they should be viewed as flexible
| (having a reasonable margin of error) and informed by tight &
| trust-driven feedback loops. I subscribe to Gantt charts as a
| planning tool, not a bible. Use it to empower development teams
| to plan and track execution, but don't use it for 0-margin
| accounting.
|
| One anti-pattern in engineering management is shielding
| engineers entirely from timeline estimates. A CEO with limited
| runway, reporting to the Board, doesn't have such a luxury of
| infinitely elastic time.
|
| Edit:
|
| Note: dates should never be prioritized over value. If you're
| hitting dates and not delivering value then it won't do good
| for anyone. Product value should always be the function to
| optimize for, but rarely is it entirely independent of time.
| Tomte wrote:
| I used to work for a company where important deadlines and
| release dates were often cast in concrete. At the birth date of
| the former CEO (husband of the current CEO) who had tragically
| died many years before.
|
| So if your "natural" release date was a few weeks after that
| birthday, it was definitely on that birthday. You only had a
| chance to escape that if your "natural" release date was months
| apart from the birthday.
|
| But then again, this company never ever hired anyone without a
| positive graphological expert's report.
| ineedasername wrote:
| I dislike articles like this. They take a situation that isn't
| representative of the workplace everywhere, generalize it, and
| come up with a universal "never do X!" headline that grabs
| attention.
|
| There's nothing wrong with deadlines, even arbitrary deadlines.
| Without them it's easy to get lost down a side path of "oh, it
| would be nice if we could do X". They serve to focus attention.
| The thing is not deadlines, but how you work within them. If it's
| arbitrary, Work backwards from the deadline to what can
| reasonably done, and present a detailed account of those
| estimates. If you have a hard-charging "just get it done" boss,
| part of your responsibilities is to manage upwards, education you
| leadership on, so they can have reasonable expectations.
|
| Will this work in every situation? No. But that isn't
| representative of some universal problem with deadlines, it's
| representative of poor management.
|
| here's nothing wrong with setting dates. There's nothing wrong
| with setting arbitrary dates
| MaulingMonkey wrote:
| Even impossible deadlines aren't the end of the world. "We need
| X Y and Z done in N weeks!" "...I'm not sure if we can get even
| one of those completed in N weeks - and that's even before
| accounting for the fact that I'm an optimist among optimists.
| Since it's so obviously impossible, I'm not going to kill
| myself trying - instead, let's talk prioritization, so we can
| deliver as much value as reasonably possible within the
| deadline, if it's really an important one."
|
| What you want to avoid:
|
| 1) Pressuring devs into crunch/burnout/quitting/morale
| loss/checking out. Turnover will eventually cause brain drain
| when your best talent leaves for greener pastures, and makes
| hiring more expensive when your reputation sours.
|
| 2) Pressuring devs into sacrificing long term productivity for
| meaningless short term milestones. It's one thing to prioritize
| a feature or two for an important presentation to investors who
| will be making decisions about your financial future at the
| temporary expense of, say, test coverage. It's another to do so
| routinely that codebase stability suffers, developer velocity
| gets wasted on disturbingly routine debugging sessions, and
| build engineers disable code coverage metrics for being "just
| too gosh darn depressing to even look at."
| at_a_remove wrote:
| Estimates are never good enough, when asked you're supposed to
| tell them two weeks _before_ their guess. I recollect one project
| with a hard deadline. This landed in my lap during a worthless
| business trip while I had a fairly serious cold. I had about five
| weeks, all on my lonesome. It was _critical_. I had no time and
| no energy but tackle it I did.
|
| I had precisely one meeting with the person who issued the
| project, during which he made various Agile noises. This taught
| me something I would later come to expect about those sounds: I
| met with the stakeholders precisely _zero_ times before delivery,
| despite my repeated asks. I worked evenings and I worked weekends
| to deliver something on time that was perhaps a little better
| than expected.
|
| And crickets. For five long months, nothing. I asked tentatively
| and was told I got paid whether or not it was in use.
|
| So this strangled two values for me: Deadlines, certainly. If I
| hear a deadline, I evaluate from where it came. If it is a
| nonsense deadline, I lose respect. False urgency is just a way of
| life with some people. Additionally, the "getting paid whether or
| not something was used" is an excellent way to develop apathy in
| an employee, it destroys the value of engagement.
|
| Sometimes real dates exist, and I'm all for that. Floods can be
| expected. But too often dates are picked out of a hat.
| cjohnson318 wrote:
| Like, sure, if you want me to write Hello World, then I can give
| you a snappy timeline for that. If you want a POC of something
| very few people have ever implemented before, then that's going
| to take about a week. If you want that POC to be ready for
| production, then that's going to take a lot longer than you're
| comfortable with to test and develop.
| mmcnl wrote:
| It annoys me so much that many people think software development
| is misunderstood. You think people in other types of business
| don't have to give estimates based on almost nothing? This
| happens everywhere, anywhere. But somehow software engineers
| think they are special and are being treated super unfairly.
| Giving estimates for software dev is 10x easier than giving
| estimates on the usual vague business problems management is
| facing (the same management that's always responsible for
| everything that is wrong, according to most software developers).
| Yet I don't hear "management" complaining about that. Software
| devs are not royalty.
| kabdib wrote:
| Confession time: In 40+ years of doing software, I've met my
| schedule once. Actually, that's a lie. I missed by a week on a
| 150-day long project, my very first project at my very first real
| company, and that's the closest I ever got with my own estimates.
| And on that project, marketing wanted it pulled into 30 days (and
| to hit that 150 days I was doing all-nighters and basically
| killing myself, so it wasn't a very good schedule to begin with).
| [For the curious, it was a game cartridge].
|
| The real losers of "schedule chicken" are the customers, who
| receive buggy and bad products. The company will suffer long
| product update cycles because of the effort needed to stay ahead
| of the quality debt. Explaining this to a manager who's never
| even read even one of his copies of _The Mythical Man-Month_ can
| be tough.
|
| Things aren't necessarily better when you let a project
| freewheel. "You'll ship someday, just do a good job and get it
| right" doesn't necessarily translate into the urgency to ship a
| product, and I've seen efforts on the scale of tens of millions
| of dollars fail.
|
| Other arbitrary dates include things like shows (well, what is
| the real cost of missing that show versus shipping something
| buggy to bad reviews?) or holidays (hitting Christmas used to be
| a good excuse for schedule pressure in the game industry, much
| less of an excuse now).
|
| [Anecdata: Years ago there was a manager at Microsoft who told
| his team to ship by some arbitrary date, which turned out to be
| when he was planning to go on a long vacation. I'm happy to say
| that Microsoft fired him.]
| commandlinefan wrote:
| > I was doing all-nighters and basically killing myself
|
| I often suspect that the true goal of most time-estimation
| exercises is to guilt you into working unsustainable amounts of
| unpaid overtime.
| xupybd wrote:
| I honestly don't think so. Companies have finite resources
| and need to allocate their use efficiently. That's hard to do
| when you don't know how long it will take / how much it will
| cost.
|
| If you don't think you have the money to meet the estimated
| project time you need to find ways to reduce the time. Sadly
| that leads to problems as described in the article.
|
| The is an impedance miss match between software development
| and real world business reality.
| almostdeadguy wrote:
| If your product development process constantly places you
| into dilemmas where a development effort requires a
| commitment to cost and timeline that could damage the
| company if either is overshot, they either:
|
| A. aren't testing enough / at all or haven't given any
| consideration to what is the smallest change needed to
| deliver value
|
| B. have serious organizational problems around coordination
|
| C. are running a company completely unsustainably
| jerkstate wrote:
| yes, it's called a "forcing function" and management is full
| of similar techniques
| Insanity wrote:
| Why would you though?
|
| I don't see the point in working all-nighters for a company
| unless you have a stake in the company (shares or owner). For
| my own company, sure I'll pull an all-nighter before an
| important meeting, for a company where I am one of hundreds?
| No thanks.
|
| Labour laws tend to be more protective here in the EU though
| so no fear of being fired by refusing rediculous requests.
| latencyloser wrote:
| If you don't do it, there's always a willing colleague who
| will. At least, that's been my experience in FAANG and
| related companies. Since I became...complacent, I guess...
| and started only working 9-5 for the most part, I can't
| keep up with my colleagues who are working seemingly every
| waking minute. It's a great way to get passed up on
| promotions, not get handed the "good" projects, and just
| generally be sidelined from decision making. Ymmv of
| course.
| throwaway713 wrote:
| > If you don't do it, there's always a willing colleague
| who will
|
| Haha, isn't this the truth. I work at one of FAANG as
| well and was curious how one of my colleagues was
| accomplishing _so much_. His output is astonishing. I
| checked his work profile and noticed he had commits,
| notes, and research actions starting at 7:00 AM and going
| until 1:00 AM the next day, every day, including
| weekends. I don 't think the founder of this company ever
| even worked that much. I guess there's just some people
| who never burn out. Meanwhile, my wife gets annoyed about
| dinner when I work past 6 PM...
| the_gipsy wrote:
| Oh he will burn out, eventually.
| frank2 wrote:
| Maybe he uses a script to make commits to give the
| appearance of working all the time.
| heretoo wrote:
| > there's just some people who never burn out
|
| I once read there is only concrete that has either
| already cracked or is about to crack.
| larrik wrote:
| Well, you can look like a rockstar if you do it right.
| taurath wrote:
| Its easier to look like a rockstar by getting a 30 day
| estimate done in 10 days than a 10 day estimate in 10
| days when it took 30 days of work. You'll rarely get
| extra credit for meeting expectations.
| mjfisher wrote:
| > Explaining this to a manager who's never even read even one
| of his copies of The Mythical Man-Month can be tough.
|
| Perhaps he should read both simultaneously and finish in half
| the time...
| wool_gather wrote:
| The manager and their boss should read alternating pages and
| then explain each chapter to the other.
| brightball wrote:
| This hits on exactly why I was drawn to SAFe.
|
| After all the feedback I got from this...
|
| https://news.ycombinator.com/item?id=17154355
|
| Someone pointed me to Reinertsen's Principles of Product
| Development Flow book, which put into numbers and models
| everything I'd been trying to say (and then some).
|
| It worked great with my team, but I was failing hard at
| communicating and involving everyone on the business side so I
| started researching for something that provided the business
| side, wrapped around his methods. Which drew me to Scaled Agile
| Framework.
|
| There's a lot in it, but the core of it is simply on a pace of
| 8-12 week increments, you spend 2 days letting your developers
| provide you with a plan, estimated based on 2/3 of their actual
| available time. They make the plan...not management.
|
| The plan is presented to management, management discusses
| tradeoffs and options, then ultimately management will accept a
| final plan and the developers provide a confidence level in their
| ability to deliver the plan that they have set out.
|
| When new requests come in, they are discussed for the next 8-12
| week increment so the developers can focus on executing the plan
| that everyone agreed on.
|
| There's still room left for small things that come up, there are
| progress check-ins and communications that happen along the way.
| Risks to the plan are identified and discussed so everyone is
| aware of them up front. Variability is assumed (up and down)
| throughout the plan. The only assumed commitment is to the 8-12
| week deliverable. Nothing in between is expected to have a
| guaranteed delivery date.
|
| It leaves little room for surprises and plenty of room for people
| to work in a reasonable manner. I can't speak highly enough of
| how effective it is to addressing this problem.
| andi999 wrote:
| You should multiply the plan of the developers by 3-4 before
| presenting to management. So management can cut to factor of
| 2-3 and you will barely reach it. I never met a developer who
| doesnt underestimate the effort needed by a vast amount.
| (including myself)
| brightball wrote:
| Management doesn't get to cut the plan. They get to ask "what
| if we don't do this, would it be possible to get this
| instead?"
|
| There's no "we said it will take X" and management saying "do
| it in X/3". That's no longer a plan made by developers that
| developers are comfortable standing behind.
|
| Over 10 weeks, you would plan based on 2/3 of time for 8
| weeks, with nothing planned in the final 2. If things are
| running behind, this becomes buffer to finish it out. If
| things are finished on schedule by the 8 week mark then the
| final 2 weeks becomes time for developers to pursue other
| things. Training, prototyping things they've wanted to build,
| whatever.
|
| It's the old Google 20% time concept built into each
| increment.
| bdavisx wrote:
| The problem with safe is the problem with every other "agile"
| methodology wrt the article - too many people expect a
| commitment to all items in the 8-12 week plan, so quality
| starts to get sacrificed somewhere around the 7-8 or earlier of
| the 12 week plan.
| brightball wrote:
| All that is communicated up front. If a deliverable is
| projected near the very end of the plan, it's at risk and may
| not actually be delivered.
|
| But it works wonders for keeping out midstream new work from
| side tracking your team so that you can actually deliver on
| that commitment.
| commandlinefan wrote:
| Lazy thinkers like to measure dates because they're easy to
| measure. I don't think I've ever, in my professional career, seen
| a date get "hit" - by me or by anybody else - and I've also never
| seen it matter.
| Etheryte wrote:
| I think there is a bigger picture takeaway to be made here, but
| I'm not sure if I can phrase it too well. The Douglas Adams "I
| love the whooshing noise [deadlines] make as they go by" quote
| is perhaps a good introduction. I think the general concept
| starts out in education, deliver this by date that or there's
| consequences. And in that moment, the consequences tend to be
| very real, and if you prefer a smoother ride, not something you
| want to deal with. What starts out as a way to teach both
| discipline and whatever it is you're currently learning will
| then go on to accompany you in your professional life.
|
| In reality, in software development all deadlines are pretty
| much arbitrary. Sure, there is profit to be made if you move
| quicker, but there's considerably more profit to be made if you
| move in the right direction instead of just moving quickly. The
| latter tends to often be overlooked in the management style
| outlined in the article.
|
| I think the healthy choice is to estimate, but not stress over
| the situation. Your estimate is not a promise, and make that
| very clear when you do give one. If your estimates are taken to
| be promises, it isn't probably an environment you want to work
| in for long.
| seph-reed wrote:
| Total aesthetic digression: Having the topbar offset inversely
| based off ~1.5x the scroll position is one of the coolest effects
| I've seen for hiding top bars.
|
| I like this a lot more than the sticky style that most things
| use.
| 7532yahoogmail wrote:
| Software dev 20+ years: management is right to ask for estimates.
| It's ok for engineers to write a throwaway design paper to "get
| into" the problem before turning to jira epics and stories. It's
| also right for engineers to reject arbitrary dates, pressure to
| cut corners and so on. But this or the ops story absolutely don't
| get anybody anywhere.
|
| You wanna move beyond anecdotes and nice sounding business
| arguments? Read FIRO by Dr. Schutz prob out of print or "Human
| element" by same. His son Ethan has updated these books.
|
| Look, in normal high functioning groups conflict is normal. What
| confers distinction there is two things:
|
| - no individual on team is ridgid and unchanging
|
| - conflict is resolved with 100pct buy-in ie not cause the boss
| yelled, or you were out gamed, politics, favourites. IOW there is
| trust in the team (together with self awareness, competence etc
| which the book hits on)
|
| When human factors burn down projects down the issues are quite a
| bit more about trust, individual self awareness, defensive
| behaviors, and not resolving the problem in a group way. Trying
| to eliminate conflict with rules of thumbs is a fool's errand.
| Conflict itself is not a sign of badness.
|
| References to organizational modalities (the strong boss, the
| clear vision, and similar sounding approaches) help at the
| margins only and then only randomly.
| taurath wrote:
| I would just say that most conflict that people will deal with
| is unfortunately going to be the bad type. Its not very
| frequent outside of a few highly productive environments that
| there is enough active trust communication and self awareness
| to avoid "territorial" conflicts.
| pmarreck wrote:
| I think this highly depends on the developers and the team. I
| myself care about my work and this sometimes lead to tensions
| with management, but because they trusted me, those tensions
| were productive. When the trust is lacking, those tensions
| become sour.
| colechristensen wrote:
| I don't know about 100% buy-in. Maybe it is just lacking nuance
| but being ok with going forward in a direction you don't agree
| with is important in a team. Disagreement is good, it gets you
| better results in a healthy environment, and it doesn't have to
| end to make a decision.
|
| The signs of a good compromise is everybody leaves unhappy
| about something. Not that products should be built entirely on
| compromise... that also leads to garbage.
|
| It is difficult to pick the pieces apart, but frequent strong-
| armed conflict resolution is definitely a sign of a bad
| environment.
| btilly wrote:
| 100% buy in is right.
|
| See https://en.wikipedia.org/wiki/Disagree_and_commit for a
| list of successful organizations that have adopted a
| principle meaning that and why they did it.
| taurath wrote:
| Only in an environment where failure is an option and
| inaccurate or wrong action is preferable to inaction.
| Disagree and Commit doesn't prevent the Challenger from
| blowing up.
| foobarian wrote:
| There is a big difference between "I disagree with { on
| separate lines" and "this won't work in production".
| WaitWaitWha wrote:
| Disagree and Commit is _not_ about 100% buy-in. It is about
| having the fortitude to disagree, but once a decision is
| made, 100% committing to and supporting that decision,
| _despite_ disagreeing.
| arcticbull wrote:
| As someone going through this right now, here's some things I
| do to make the process easier.
|
| 1. Put together a ~medium detailed listing of what work needs
| to be done, broken down into sub-tasks.
|
| 2. Include estimates for how long each sub-task will take.
|
| 3. Roll that up into a gantt chart with dependencies reflected.
|
| 4. Identify opportunities for parallelization so you can answer
| the question of "will adding more folks make things go faster?"
|
| 5. Identify and be prepared to speak to which portions of the
| schedule represent padding, and explain why it was padded in
| that way. Share your thinking in the trade-off you made and be
| open to adjusting -- and de-risking the schedule in other ways.
|
| 6. Realize this is a bit of a negotiation, not necessarily you
| vs. them but more you and them vs. what you can deliver. In a
| negotiation it's important to not appear intractable. Have
| things you can give away.
|
| 7. At the end of the day the engineers are writing the
| software. If you're not actively dragging your feet, what you
| say does go, so it's a question of where you're spending your
| time, and on what.
|
| 8. Don't burn bridges, y'all have to work together.
| suchire wrote:
| I think another rule of thumb I would add, which other
| commenters have mentioned in passing, is to negotiate scope,
| quality, and likelihood of success, not estimates.
| Negotiating estimates is where people start questioning each
| others' expert judgment, which leads to a breakdown in trust.
| shkkmo wrote:
| The solution in this hypothetical is that the technical manager
| should have pushed back on efforts to squash estimates, and
| instead gotten the feature set reduced down to what would fit
| inside the desired launch window.
| commandlinefan wrote:
| I've seen that tried, I've never seen it actually work. What
| I've always seen happen is, they'll ask if _X_ can be worked
| into the schedule, the devs will say no, it can 't. Then the
| next day, they'll ask if _X_ can be worked into the schedule
| (usually phrased just a _little_ bit differently than before),
| and the devs will say no, it can 't. Then a week later, they'll
| ask if _X_ can be worked into the schedule. Then, when the devs
| say no, it can 't, they accuse the devs of pushing back on
| everything, so the devs finally roll their eyes and agree to
| _X_ (knowing that it 's impossible to deliver because it's not
| even defined, but who cares because nothing ever happens when
| you inevitably miss the dates anyway). Then the next day, they
| ask if _Y_ can be worked into the schedule...
| cfmcdonald wrote:
| It can work. There does need to be mutual trust between
| product leadership and engineering.
|
| e.g. in the case you described, the engineers need to be able
| to communicate without fear that X1 and X2 are basically the
| same engineering work as X, and still can't be accommodated,
| and the other side needs to trust that they are not just
| being lazy.
| petedoyle wrote:
| > "We believe that communicating dates produces the wrong
| incentives. What really matters on a long timescale is 1)
| priorities and 2) velocity." [1]
|
| I saw this written during the 2017 cryptocurrency craze. Has
| stuck with me as one of the most insightful things I've ever
| read. Also a fan of 37 Signals' budgets. [2]
|
| [1] https://medium.com/graphprotocol/introducing-the-
| graph-4a281...
|
| [2] https://signalvnoise.com/posts/3746-drive-development-
| with-b...
| freepor wrote:
| If you are paying people on a schedule you need to have at least
| a rough understanding of what they can produce on a schedule. The
| best illustration of this is client work that is paid "by the
| job" -- you need to understand what you can produce to have any
| idea how to bid.
| john_moscow wrote:
| As a person who runs a small software business, coding most of
| the functionality myself, I actually disagree with the article.
| There is a huge value in setting deadlines because they force you
| to prioritize things. Once you realize that you don't have the
| time to ship features X, Y and Z, you start comparing their
| impact/complexity/risks, pick the most beneficial one, and ship
| it before it's too late.
|
| Without prioritization it's very easy to get stuck in a loop of
| endlessly adding small improvements/testing new ideas, but never
| releasing the final sellable product. There are a few notorious
| examples from the game industry where no time pressure lead to
| either no product, or a hopelessly late-to-market product (e.g.
| Half-Life 3, Duke Nukem Forever). There are more smaller examples
| where entire teams endlessly juggle the code between web
| frameworks, as they come in and out of fashion, and neglect more
| user-impacting features.
|
| That said, most of time pressure should only be applied at the
| decision-making level. Once you have decided to ship feature X
| with framework Y, it's useless to nag on your devs to do it in
| half the time by dropping unit tests, or doing 60-hour work
| weeks. Instead, you should have picked feature Z with 50% the
| complexity and 80% user impact.
| temac wrote:
| > As a person who runs a small software business, coding most
| of the functionality myself
|
| I'm not even sure you disagree with the article, given you are
| in a radically different position; how often do you think, as
| an implementer, that your business ideas are complete bullshit,
| sometimes even just because you don't know all the details you
| are thinking about on the business side?
|
| Project management is about communication. Having that problem
| reduced to communicating mainly with yourself changes a little
| what is effective and what is not.
|
| > That said, most of time pressure should only be applied at
| the decision-making level. Once you have decided to ship
| feature X with framework Y, it's useless to nag on your devs to
| do it in half the time by dropping unit tests, or doing 60-hour
| work weeks. Instead, you should have picked feature Z with 50%
| the complexity and 80% user impact.
|
| So yeah, we could continue to interpret that as you mainly
| agreeing. Implicit cultural incentives are a thing and it is
| illusory to think that "devs" won't be aware of schedules and
| won't drop half of unit tests if there is a risk of looking
| "bad" at short term if they stuck with state-of-the-art
| practices.
|
| Note that the solution is not in the extreme opposite, of
| course. It never is. There is a system of values to be tuned,
| and I'm not sure a lot of projects exist where the date of
| completion does not matter _at all_. Your example of Duke Nukem
| Forever was on point :) But being date driven would mean the
| date is the most important thing: this also is rarely the case.
| silentific wrote:
| "Arbitrary date". Deadlines are still important.
| NullPrefix wrote:
| >Half-Life 3
|
| I'm not sure they even worked on it, have they?
| ShamelessC wrote:
| They worked on Half Life 2: Episode 3 for awhile before
| giving up. There was also a leak of unfinished Half Life 3
| source code in 2014 (I think).
|
| After the release of Half Life Alyx a few months ago, they
| have heavily implied a recommitment to Half Life 3 in
| interviews.
| nbardy wrote:
| Agreed. Maybe at a large organization where you are working on
| system that have more concern about stability and maintenance.
| At a startup setting deadlines and cutting corners is key for
| me to be a good engineer. My goal is get to "something" in the
| hands of a user or customer as fast as possible to determine
| what I actually need to build vs what I think I need to build.
| Cutting corners and getting out features faster allows me to
| validate what I'm building is useful and better direction for
| what I'm building next.
|
| Before my current project is designing an API for logging and
| viewing image segmentation masks, A mask that segments an image
| into n classes. We started with a large design that allowed
| users to configure to masks in different layers. Toggle them on
| and off and do composting. Instead of building this exactly I
| shipped a small fast very that renders images with masks and
| adds some toggles for each class.
|
| Turns out one of our main assumptions was wrong we thought the
| number of classes(n) would be small. It's 1-2 order of
| magnitude larger on average for all of our users. And sorting
| through large amounts of classes is the biggest issue our users
| are clamoring for. Now instead of spending a bunch of time
| building a UI for editing the masks. We first focused on
| handing large counts of classes usefully.
|
| As well, all of the different settings for mask composition and
| layout we dreamed up really don't matter. While there is 100's
| of different ways you can layout and compost the masks. Turns
| out there is 3 default layouts that everyone wants, we don't
| need a UI for tweaking layouts we just need a toggle between
| the three common states.
|
| Instead of spending extra time to get it right. We aggressively
| cut scope and shipped a not particularly useful feature. We got
| two big benefits out of this. We ended up building something
| much smaller in scope than our initial design and we ended up
| building something better and more useful.
| tikhonj wrote:
| Prioritization is the key thing.
|
| I have a simple rule of thumb: a deadline is a "real deadline"
| _if I would reduce scope to hit the deadline_.
|
| A deadline is just a goal if I would _not_ be able (or willing)
| to reduce scope to hit it.
|
| Treating a date as an absolute deadline _without being able to
| adjust scope_ is where productive work gets totally derailed.
| mmcnl wrote:
| Great insight. A deadline where the only thing you can change
| is the hours you put in, is not a deadline, it's
| exploitation.
| troebr wrote:
| There are multiple ways to make a project fit into a
| deadline: - change/reduce the scope => lowers the value of
| the product - cut corners: for ex. skip testing, ignore
| bugs, work faster, skip code reviews, etc. => lower quality
| - work longer hours (lower quality + human cost) - throw
| more resources at the problem: may scale poorly if at all,
| as well as usually results in lower quality and more
| friction, aka human cost
|
| It's all about weighing everything and making the right
| trade-offs. Sometimes short term solutions are the right
| approach, maybe you need a POC more than a polished product
| to get that next round of funding or something.
|
| I've struggled with that in the past, and next time I'm
| presented with this kind of project, I'll clearly explain
| the trade-offs, for example translating lower quality to:
| this may increase the number of bug reports significantly,
| increase the maintenance cost, prevent the addition of
| other features with significant overhauls, this and this
| engineer may start looking for another job, etc.
| Frost1x wrote:
| It's incredibly common and a sign of poor management and
| structures I have no desire of working with.
|
| It's also what most "agile" environments end up turning
| into: a bunch of inflexible arbitrary deadlines designed to
| make developers work more, amongst many other problems.
| xupybd wrote:
| I had this happen. First time I'd used a framework for more than
| a few screens. Totally new way of doing things. Learning RXJS,
| made a mistake in understanding one of the more strange
| requirements. Time blew out. But the delivery date was 3 months.
| Worked crazy hours, product didn't ship the entire thing was seen
| as a failure.
|
| I was burnt out for a good 6 months after that. Even simple tasks
| took all of my will power to do. It was horrible. 3 months of the
| hardest work I've done and considered a failure for it.
___________________________________________________________________
(page generated 2020-05-07 23:00 UTC)