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

Dear Agile, I’m Tired of Pretending (2018)

medium.com

Post reply on HN
Print view View original

91–100 of 420 posts

Re: Dear Agile, I’m Tired of Pretending (2018)

#91

Post by TeMPOraL »

CraneWorm wrote: post #66
xfitm3 wrote: post #53

Earlier quoted context omitted.

I was interested in comp sci precisely because I didn't have to talk to people, an area where every interaction is a performance. I want to be alone - what's so wrong with that?

I had a similar sentiment - As a programmer, I did not want to be communicating with a client , I wanted to be left alone in a sense that I only ever had to interact with people that understand how coding works. I think it's doable; say you are the sole developer of a massively used library. The programmers being your only users - they read the API docs, submit an occasional feature request/bug report.

Heh. I have a reverse sentiment. As a programmer, I want to communicate with the actual users who'll be using my product. But without two layers of intermediaries on both our and customer side, who end up turning this whole thing into a game of telephone, ostensibly in the name of all the other important stakeholders.

Re: Dear Agile, I’m Tired of Pretending (2018)

#92

Post by curtis »

LarryDarrell wrote: post #85
curtis wrote: post #67

Any software development methodology or process is going to come up short if it ignores the fundamental nature of software development, which is: We do not know what we're doing until we do. Any process or methodology that tries to extract promises out of the software development organization about things that are still in the we do not know what we're doing phase is going to result in disappointment at best and seri…

That's the truth, except, I can't tell clients that "I'll know how long it will take when I'm halfway done." The best I can do is look at prior work and multiply by the LarryDarrell Constant of 1.5.

I kind of lean towards double the schedule and cut the scope in half and hope that maybe we can deliver a little extra credit work.

It's important to note that padding schedules is not just done in software, it's a common practices in all sorts of engineering. It's not bad that we do this, it's bad that management often doesn't understand that we do this and doesn't understand why. The understanding why part is actually really important, because that means management can be expected to do their part in managing the uncertainty or at the very least they can be expected to be careful about not making the situation worse.

Re: Dear Agile, I’m Tired of Pretending (2018)

#93

Post by cljs-js-eval »

nosianu wrote: post #33

"Thou shalt not be negative" (HN) - well I'm sorry. Just some example text: > both Agile and Waterfall are focused on building. Design is about validating. or > So…what’s the way out? It’s a smart focus on clear outcomes, not output, with roadmapped outcomes replacing planned milestones, with trusted product teams, not project teams, empowered to vet assumptions and discover the minimal path to value. Satire? Enough…

In the spirit of that second paragraph - focusing on outcomes, not specific implementations - here's a rewrite:

Original:

> So…what’s the way out? It’s a smart focus on clear outcomes, not output, with roadmapped outcomes replacing planned milestones, with trusted product teams, not project teams, empowered to vet assumptions and discover the minimal path to value.

Rewritten:

> So… what’s the way out? It’s a focus on clear outcomes, not output. There should be dates for when specific outcomes should happen. Teams should be empowered to find the minimal amount of work needed to achieve the outcomes.

It's a really wordy way to say what any good leadership class would tell you. Focus on what you want more than how you get it, and let your subordinates decide how to get it. Both good product teams and project teams are capable of working that way.

This kinda sums up my problem with endless agile vs. waterfall vs. whatever discussions. The interesting parts aren't really new ideas and the extra buzzwords add nothing.

Re: Dear Agile, I’m Tired of Pretending (2018)

#95

Post by klodolph »

LarryDarrell wrote: post #85
curtis wrote: post #67

Any software development methodology or process is going to come up short if it ignores the fundamental nature of software development, which is: We do not know what we're doing until we do. Any process or methodology that tries to extract promises out of the software development organization about things that are still in the we do not know what we're doing phase is going to result in disappointment at best and seri…

That's the truth, except, I can't tell clients that "I'll know how long it will take when I'm halfway done." The best I can do is look at prior work and multiply by the LarryDarrell Constant of 1.5.

I think one of the top skills for management / senior dev is to be able to translate between software estimate uncertainty and the business reality surrounding the schedule.

For example, if you ask, "How long will this project take?"

You could just say, "I don't know. At least two weeks, but it might take as long as six months." This may be accurate but it's not helpful.

Or you could say something like, "In a half day I could put together a preliminary design, and identify the most uncertain parts of the project. From there we could figure out what is needed to tighten the schedule or adjust the requirements."

And I think that one of the more common problems with managers in larger orgs is that they can't tell the difference between somewhat arbitrary deadlines (we want this for Q3 to look good in our org, but we can break this project into smaller milestones and push it back if necessary) and deadlines that reflect the reality of business (we want this for Q3 because this will have cascading effects on other parts of our business, and if there are problems we need additional resources or an adjusted scope).

Any time there is a deadline, the manager should have a clear understanding of the consequences of missing that deadline, and be able to communicate that to the engineers. The efforts to come up with a schedule and milestones should be collaborative. Too often there are mandates that have unclear consequences for missing them, and when schedules slip you have no idea what you are supposed to prioritize.

Re: Dear Agile, I’m Tired of Pretending (2018)

#96

Post by ALittleLight »

geezerjay wrote: post #14
commandlinefan wrote: post #10

You don’t hear the name Joel Spolsky much any more, but he was pretty influential in software process thinking in the 90’s - not really for being particularly insightful or original, but more because he was one of the first people who thought of writing a blog about software design. One of his early “observations” about software project management was that “you wouldn’t buy a pair of jeans without knowing how much th…

What's stupid in wanting to get an idea of how much a project costs in order to decide if it's a good idea to pursue, let alonr allocate resources?

"How long will X take?"

"I don't know, I've never done X before."

"Yeah, yeah. It doesn't have to be perfect analysis, just a rough idea for scheduling. Not written in stone, ha ha."

"Uh, a week?"

"Okay, great, so if I say 8 days you should have it done by then?"

"Yeah, I hope so."

"Great, thanks."

Day 3: actually doing X requires unforeseen Y and Z which will each take a month.

"We need to add Y and Z to the schedule, which will each take a month."

"There's no room for that in the schedule."

"Then I can't do X"

"We've already costed X and committed to it. We've got to do X. We need to make X happen. When can you get back to me with a path to green for X? And also, let's schedule a post-mortem to figure out why we missed on X."

At the post-mortem, PM doesn't show up: "Uh, turns out we missed on X because I estimated it too quickly and the PM committed to those estimates. I didn't know about Y and Z when estimating, and these are things I could have done to detect them as requirements if I had known to do so."

Email from PM: "Hey, could you give me an estimate for X'? Doesn't have to be perfect, ha ha."

Re: Dear Agile, I’m Tired of Pretending (2018)

#97

Post by java-man »

bougiefever wrote: post #88

I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don't get it. I have suffered great anxiety from being forced to give estimate…

I think there is a way to give an estimate (have been doing it myself for a decade), even for dependencies that are not known from the start.

(I mean, reasonable dependencies. No one can account for unknown unknowns, but the software engineering field is not an art, more of a skill, we do have well established processes to minimize the surprises).

Is this something that HN audience is interested in?

Re: Dear Agile, I’m Tired of Pretending (2018)

#98

Post by Zelphyr »

The biggest problem I’ve found with Agile hasn’t necessarily been Agile itself but the lack of buy-in from company leadership. Even when we’ve had professional Agile trainers come in and tell them that not only must they embrace it for us to be successful, but they themselves must go through the training. They usually waive it off as something they’ll get to eventually. Almost immediately we wind up with a bastardized version of Agile that basically doesn’t work because the leadership doesn’t understand why we “can’t just” do something.

Re: Dear Agile, I’m Tired of Pretending (2018)

#99

Post by icebraining »

lbotos wrote: post #15
commandlinefan wrote: post #10

You don’t hear the name Joel Spolsky much any more, but he was pretty influential in software process thinking in the 90’s - not really for being particularly insightful or original, but more because he was one of the first people who thought of writing a blog about software design. One of his early “observations” about software project management was that “you wouldn’t buy a pair of jeans without knowing how much th…

Your argument here is against "business". In a dream world, where we could build for building's sake, and create "more perfect" things with no considerations for cost, I'd agree with you, but businesses (in the abstract) are a math function: Does it cost us less to make this than we charge for it? If so, we are a profitable business, if not, we are an unprofitable business. Managers are there to manage costs, to prot…

Casinos are quite profitable, yet they have no idea if the next card being drawn will be profitable or cost them thousands of dollars.

Re: Dear Agile, I’m Tired of Pretending (2018)

#100

Post by Bartweiss »

b_tterc_p wrote: post #49
quadcore wrote: post #13

Agile never gave organizations a holistic, viable alternative to Waterfall. Because there’s a difference between theory and practice. Product work is more about practice. When we complain about “AINO” (Agile In Name Only), we’re not being honest with ourselves. I agree with most of the article. Specially the keep-learning part. All Agile did was put software development teams unfairly under a microscope. I believe Ag…

> You have to realise that before Agile, a fair portion of the software development projects that were started would simply bust and never get shipped. The code is a complete monster or the budget is nuked. This still happens, all the time?

I have the subjective sense that the rate of massive, irreparable flops in software has gone down a lot. (Very anecdotally, the latest "permanent failure" on Wikipedia's list of major failed software projects is from 2014. That list is worth a read regardless.)

Projects still get cancelled, budgets and timelines get blown out, features and testing get compromised. But at least in dedicated software companies, it's pretty rare for something to get through 90% (or 150%) of its allotted development time and then be completely discarded as unsalvageable. (For technical reasons; market changes are a different beast.) Projects in technical crisis are either apparent sooner or have usable elements, rather than failing outright at the end of a waterfall.

Of course, there's a lot of room to debate what changed and why. If Agile led projects to fail sooner or less dramatically, that's still important, but less notable than if it changed them into successes. And a lot of technological advances have helped too; things that might have been outright failures as shrinkwrapped software can become late or overrun projects in the era of digital distribution.

https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_...

Post reply on HN