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

101–110 of 420 posts

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

#101

Post by Bartweiss »

andyroid wrote: post #59
b_tterc_p wrote: post #49

Earlier quoted context omitted.

> 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?

The difference is that of ivory tower planning and the following phases of development, testing and a “big bang” release (waterfall) vs working with an MVP with the purpose of releasing as soon as possible and then work in iterations based off of actual feedback and demand (agile). If you manage to nuke your budget or create a monster of a code base already at the MVP stage no methodology is going to save you.

I really do believe agile (or at least "not waterfall") has reduced the rate of major software flops. But I'd be fascinated to know how often it turns failures into successes, versus revealing failures earlier in the project cycle. Both are valuable, obviously. It's just interesting that part of Agile's value is in revealing engineer dysfunction or fundamentally bad ideas at the MVP stage instead of the completion stage.

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

#102

Post by ant_li0n »

ALittleLight wrote: post #96
geezerjay wrote: post #14

Earlier quoted context omitted.

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 schedul…

Yes. This happens at my shop all the time and it's absolutely terrible. Each sprint starts out positive and ends with panic attacks.

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

#103

Post by Bjartr »

java-man wrote: post #97
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?

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

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

#104

Post by giobox »

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.

The programmer users are arguably "clients" in this context too. Much the same sorts of issues, different labels.

One need only look at the bug tracker on the average "massively used library" to see that you will be communicating with clients a great deal. Your dream of a small group of perfect programmers filing neat and accurate feature requests or bug reports doesn't match any reality I've ever seen. To expect them all to "understand how coding works" is also likely a pipe-dream - users of all ability levels are out there writing code, filing bug reports for things that aren't bugs, asking questions in forums that aren't meant for those questions, mad at you because the direction the project has taken isn't the one they or the company they work for want/need, etc etc...

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

#105

Post by unreal37 »

kjsbfkjbf wrote: post #58
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?

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. :)

Upvote to this.

As far as your career - salary and promotions and recognition - you can't just sit in a corner and be quiet. People have to recognize that you're good at what you do and it's hard for others to see when you only communicate in code check-ins.

You have to start attending meetings, speaking at meetings, and being useful beyond the code.

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

#106

Post by justinpombrio »

java-man wrote: post #97
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?

> Is this something that HN audience is interested in?

Are you teasing? Yes, we want to know! Though frankly I'm incredulous.

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

#107

Post by cc81 »

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…

You should be able to put it in a range otherwise you probably don't know enough to build it. You don't want to spend 100 millions on something that will save 1 million a year.

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

#108

Post by namaemuta »

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.

You can tell them "A wizard is never late, nor is he early, he arrives precisely when he means to."

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

#109

Post by unreal37 »

icebraining wrote: post #99
lbotos wrote: post #15

Earlier quoted context omitted.

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.

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.

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

#110

Post by Skunkleton »

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.

> multiply by the LarryDarrell Constant of 1.5.

Funny thing. If you do this organizationally, then you eventually end up making larger and larger estimates. IMO it is better for management to understand the inherent risks associated with engineering estimation and build the padding on their end.

Post reply on HN