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

141–150 of 420 posts

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

#141

Post by stronglikedan »

java-man wrote: post #132
Bjartr wrote: post #103

Earlier quoted context omitted.

I'd love to hear what you have to say in the topic.

Sorry, tried to answer and apparently I was "posting too fast". One may start with enumerating the features that needs development (a.k.a. "user stories"). Also enumerate external dependencies, team overhead (more people working together means overhead is greater). For each feature enumerated in step 1, try listing as much detail as possible, also listing open issues and unknowns. For example, list all the UI element…

And then the customer decides that they don't want to move forward with the project because it's too expensive. Oh, and they don't want to pay you for all the time you spent estimating because no one pays for estimates up front anyway.

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

#142

Post by commandlinefan »

unreal37 wrote: post #109
icebraining wrote: post #99

Earlier quoted context omitted.

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

I think every owner of a casino knows there is luck involved in their profits, and that the odds are stacked slightly in their favor. I don't think any owner of a business thinks that there is luck involved in creation of their software systems. They absolutely look at the $10 million per year they are spending on "IT" and look at the $26 million per year in value that spending is unlocking in absolute dollar terms.

> thinks that there is luck

You mean "realizes there is luck". And hence the problem.

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

#143

Post by commandlinefan »

ben509 wrote: post #61
danielbarla wrote: post #17

Earlier quoted context omitted.

Nothing, inherently, except perhaps the fallacy of comparing a pair of jeans to the rather chaotic and unpredictable world of bespoke systems development. One is inherently known (a pair of jeans you've presumably already manufactured), the other is one big unknown, basically.

He compared to jeans because they're an extremely trivial purchase that someone would give little thought to, but still demand to know what they cost. The point is that in all cases you need that information, with a major software project you simply need it far more.

> you need

And that's the core of the problem (which, ironically in the context of the article, agile methodologies were supposed to address): wanting or needing something to be true/exist doesn't make it so.

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

#144

Post by TheGRS »

ok_coo wrote: post #86
kjsbfkjbf wrote: post #58

Earlier quoted context omitted.

There is nothing wrong with that, but careers under capitalism are about _signaling value_. I hope you find a place (or have found a place) where you're appreciated. :)

I'm not sure why you're being downvoted but some of the best career advice I've heard is someone saying you should assume when you go to work that you're working under a communist dictatorship. I.E. Toe the party line, make your boss look good, (pretend to) eat up the company propaganda, assume the leader(s) (C-suite) will do whatever they want, when they want, especially giving themselves bonuses regardless of compa…

I don't know if that's great advice, but its certainly advice that will help get you promotions and salary bumps.

Like anything there's a grey zone here. Understanding the political realities of a business is highly beneficial and will help you move forward with the company and let you know when to pick your battles. But I've watched people who do nothing but this lose the trust of those at their level. And that trust is crucial for agile development. I also personally feel like pushing back on the company when appropriate can indeed provide a lot of value to the organization. "Why are we doing this meeting?" "We need another week for testing" "I'd like to see the roadmap you are planning". Just don't push back all the time.

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

#145

Post by java-man »

stronglikedan wrote: post #141
java-man wrote: post #132

Earlier quoted context omitted.

Sorry, tried to answer and apparently I was "posting too fast". One may start with enumerating the features that needs development (a.k.a. "user stories"). Also enumerate external dependencies, team overhead (more people working together means overhead is greater). For each feature enumerated in step 1, try listing as much detail as possible, also listing open issues and unknowns. For example, list all the UI element…

And then the customer decides that they don't want to move forward with the project because it's too expensive. Oh, and they don't want to pay you for all the time you spent estimating because no one pays for estimates up front anyway.

Yep. 30% upfront.

But actually, once you show the customer what's involved, and give them a realistic estimate, it might reduce the chances of cancellation. The discussion might be steered towards what they really want, or prioritization of deliverables.

A mockup (and multiple iterations thereof) might be necessary as well.

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

#146

Post by lowken10 »

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 just round up. If I get pressed I round up higher.

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

#147

Post by logfromblammo »

The longer I stay in this industry, the more anecdotes I accumulate that suggest that software development is not exclusively software development.

Software development is solutions development; but for a large subclass of problems, custom-built software that automates the tedious, predictable, and repetitive parts of the solution has been and always will be a competitive way to solve them. It's synecdoche, a metonymy for "software development [and other assorted disciplines of problem-solving]".

Software is the hammer in the toolbox. Things that look like nails get hammered. The hammer is so useful to organizations that have many nail-like objects sticking up, that handypersons who only have a hammer in their toolbox can still work continuously, and may never need to do anything else but hammer things. This may become common enough that folks who also keep vice grips, screwdrivers, hand saws, duct tape, and penetrating oil in their toolboxes are forbidden from using those tools. They were hired for the hammer; they should use the hammer. And what's all this nonsense about non-hammer tools, anyway? We've never needed anything but hammers here, and that's the way we like it.

Agile is about advising organizations with strict rules and style guides for nail-hammering to loosen up and let the hammerers determine how to wield their own hammers, and possibly also choose the length and width of the nails.

Despite the amount I actually get paid, working upstream of the problem far enough to eliminate both the nail and the hammer--possibly using a more appropriate tool--is apparently above my pay grade. Agile never fixed that. It never even suggested that a non-hammer world exists. Even the CTO position might as well be chief hammering officer. The 'T' restricts the domain of authority. An organization that is agile instead of just Agile needs to have someone around that can meaningfully restructure the company itself, such that the assumptions already built in to its organizational hierarchy are not inevitably replicated in the processes of all of its subdivisions. That's why Agile never fixed anything. The CEOs still kept telling their CTOs to take charge of all the hammers and pound something out. Those companies founded to be Agile put different assumptions into their organization. When that changes, going through the motions of Agile won't help them any more.

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

#148

Post by [deleted] »

shados wrote: post #126
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…

> Can we stop pretending we can forecast the unknown Within reason. Ive worked in orgs where there is no estimate at all, and that bring a different set of problems (unbound projects and no work getting done because of the complete lack of pressure). Now you're totally right: software engineers rarely do the same thing (or even similar things) twice, so estimating is somewhere between "very hard" and "impossible". "S…

[deleted]

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

#149

Post by DougBTX »

java-man wrote: post #132
Bjartr wrote: post #103

Earlier quoted context omitted.

I'd love to hear what you have to say in the topic.

Sorry, tried to answer and apparently I was "posting too fast". One may start with enumerating the features that needs development (a.k.a. "user stories"). Also enumerate external dependencies, team overhead (more people working together means overhead is greater). For each feature enumerated in step 1, try listing as much detail as possible, also listing open issues and unknowns. For example, list all the UI element…

https://www.microsoftpressstore.com/store/software-requireme...

That book is from this perspective, that you can work out what needs to be done for a project before actually doing it.

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

#150

Post by threwawasy1228 »

lonelappde wrote: post #83
duchenne wrote: post #52

Earlier quoted context omitted.

As a consumer, I can buy an already manufactured pair of jeans or an already programmed Adobe Photoshop for a fixed price. As a producter, the cost of building a jeans factory does not seem to be inherently more predictable than the budget of a software development project.

You think when Tim Cook signs a contract with Foxconn, he says "charge me whatever you want after it's done"?

The recent Foxconn plant in Wisconsin that may or may not be happening is a great example. They committed earlier, and claim now that their initial estimates were incorrect and that a plant in that area will not be profitable for them. They have now stopped the plan entirely and reworked what it is they are going to build completely from scratch. This despite having already committed to building the factory.

Even at scale people can pull out of complex agreements if their estimates turn out to be faulty.

Post reply on HN