Dear Agile, I’m Tired of Pretending (2018) • Hacker News Board

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

#131

Post by ALittleLight » Mon, Jul 01, 2019, 5:15 PM UTC

unreal37 wrote: post #111

ALittleLight wrote: post #96

Earlier quoted context omitted.

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

"A week" is a terrible estimate for complex things that have components that you can't foresee. If you lose "a day" on some problem outside of your control (compiling starts to fail and it turns out someone checked in some code into your branch by mistake), you've basically wasted 20% of your estimate. Never say a week when there's the chance something will require a month because you didn't understand it. You need t…

"Really? X will take 'a month at least'? Why?"

"I don't know why, but I don't feel comfortable guessing less because I don't fully understand X."

"Okay, that's not a good way to estimate. Why don't you spend some time to come up with a plan for X and we can estimate it after that. When can I have the plan?"

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

#132

Post by java-man » Mon, Jul 01, 2019, 5:20 PM UTC

Bjartr wrote: post #103

java-man wrote: post #97

Earlier quoted context omitted.

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.

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 elements under development. List all individual functions / use cases that need distinct functionality (classes, functions) to be developed. List all the test cases. List external APIs, enumerate different ways the said API can be used. Enumerate failures and possible recovery actions.

I'll give you an example: a login dialog for an application. This starts as a two page requirements document, which balloons to around 120 items using this method.

This alone should give a good idea at the start of the project. Keep doing it (enhancing the level or detail), while keeping the ratio of initial estimate vs real value - that will help in estimating the remaining portion of the work.

The problem (the way I see it) is that we don't really have the tools to do this kind of tracking and analysis. Jira and similar systems don't even come close.

Here is an attempt to apply the methodology using Excel:

https://github.com/andy-goryachev/PasswordSafe/blob/master/F...

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

#133

Post by ebiester » Mon, Jul 01, 2019, 5:20 PM UTC

xfitm3 wrote: post #53

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…

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?

You're abdicating your responsibility of developing working software. Your job is to solve problems, using code where appropriate. Your job is to understand the entire system and explain how the corporate system above interacts with the technology you are tasked to develop.

If you can't do that, what is the difference between you and a group of outsourced employees making pennies on the dollar?

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

#134

Post by stcredzero » Mon, Jul 01, 2019, 5:21 PM UTC

But but but, the problem is Waterscrumfall, not Agile as intended in the Manifesto

Here's the thing. Corporations are hierarchical. Human beings are hierarchical. We're also communal, but start putting us into larger and larger group situations where we're facing competition, stress, and we must engage in concerted effort, and we go into hierarchical mode.

Why does everything tend to go back to waterfall? It's because that's how management likes it, for reasons which go down to basic human nature in the kinds of environments technology companies create. Heck, even the financial markets demand fictional planning and forecasts of the unknowable future. Bosses want to be able to make plans.

One thing which Waterscrumfall has achieved, is that the iterations are much faster. That even fits the "next quarter" mindset of the financial markets.

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

#135

Post by Bartweiss » Mon, Jul 01, 2019, 5:22 PM UTC

me_again wrote: post #39

I have a theory that commercially successful software development methodologies are like diets: they have to be almost impossible to follow. This ensures that when you fail to lose weight/achieve bug free software, you blame yourself for not following the rules exactly, rather than the rules for not working.

At the very least, I think it's common to judge methodologies by "how well does it work when it's done right?", when we should be using a three-part test.

1. How much value is there if it goes right?

2. How easy it is to get right?

3. How gracefully will it break down if it's not done perfectly?

Methodologies don't have to shine on 2 or 3. NASA-style clean-room coding is the gold standard of hard-but-effective; you have to suck it up and commit entirely with a great team, but the results are unbeatable. Waterfall was "good, bad, bad", but used by lots of less-exceptional teams with hideous results.

Agile, I think, improved #3, but not #2 so much. It's commonly sold by appealing to how much it can potentially help, but I think the more honest pitch is "it's tough to do right and it'll sting if we get it wrong, but it hurts a lot less than getting waterfall wrong."

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

#136

Post by Sharlin » Mon, Jul 01, 2019, 5:23 PM UTC

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.

Users of a library are still users. You can write a library in an ivory tower, just like you can write applications in an ivory tower, but that kind of software is written for yourself and only incidentally for anyone else. People might still use it if there are no viable alternatives, but don’t expect them to be very happy about it. Especially because scarcity of communication also implies scarcity of documentation.

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

#137

Post by threwawasy1228 » Mon, Jul 01, 2019, 5:25 PM UTC

quadcore wrote: post #72

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?

an area where every interaction is a performance Feel ya. Surprisingly enough, I'd say that I've not had to attend so many boring meetings in my career but certainly I'm just lucky. Also, once I did get a manager who was an "agile guru" and he was annoying. He talked to me like he's the jedi of software development and I'm his padawan. Thankfully, he got fired.

I had a professor at university who acted that way about Agile. He thought he was literally Uncle Bob incarnate. But when you looked at his credentials, he had never once worked in a real production environment, he had only ever taught.

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

#138

Post by LyndsySimon » Mon, Jul 01, 2019, 5:27 PM UTC

F_J_H wrote: post #44

taylodl wrote: post #20

Uncle Bob wrote about this in The Tragedy of Craftsmanship ( https://blog.cleancoder.com/uncle-bob/2018/08/28/Craftsmansh... ). His perspective is Agile lost its way once the Project Managers stepped in. It seems to me the problem with Agile in practice today is there's too much focus on process and not enough focus on, you know, the actual software being delivered. Add to that a host of less-than-desirable ideas tha…

I had not heard of "emergent architecture" until you implied you hated it, and so I thought I would Google it. I have no idea what emergent architecture is in the agile context, but the idea of emergence is fascinating to me, and has been ever since I read "Emergence: The Connected Lives of Ants, Brains, Cities, and Software" by Steven Johnson. We see the idea of emergent design everywhere in nature and society. I'm…

Thank you for that book recommendation - I just bought it and am looking forward to reading it :)

I also had not heard the term "emergent architecture" in relation to software development. I'm intimately familiar with the concept of emergent order, though, and my grokking it was part of my "political awakening" in my 20s. It led me from being a libertarian-leaning conservative to an anarcho-capitalist. To put it another way, I believe that the system create by independent actors acting in their own self-interest naturally create the most efficient system possible within the constraints of the environment within which they operate.

There's a name for this concept when applied to company management, but I can't recall it at the moment :(. I want to say the word has a Greek root, and it reminded me of "autarchy" ("self organized") but that wasn't what it was called.

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

#139

Post by KZeillmann » Mon, Jul 01, 2019, 5:27 PM UTC

Oh look, it's the weekly "Agile is bad" post. I've successfully worked on two teams (including my current job) where we're a truly agile dev team. We value interactions over processes and tools, collaboration over contracts, and responding to change over following a plan.

Agile is not and has never been a cure-all. Scrum doesn't solve any problems. It's supposed to reveal the problems that exist and make them apparent to anyone looking at the scrumboard. If you don't change your team dynamic and just start looking at a JIRA board every day in 30 minute "standup" meetings, you're not agile. You're just cargo culting.

I'm tired of people blaming "agile" -- which is mainly about self-organizing teams and adapting quickly to changing circumstances, for what's really a management failure.

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

#140

Post by Nasrudith » Mon, Jul 01, 2019, 5:27 PM UTC

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…

It is probably good advise for most cases but individually depends on the shop and culture. Like if you really should always wear a three piece suit to interviews regardless of what they request. Some are flatter, others are more hierarchical (ironically practice can fail to line up with org chart structures).

Some are all about the politics, others don't have the luxury of self delusion or actually value the sort of brutal honesty to say "I have looked at the new framework - while trendy it is buggy inefficient crap." The ones who lack the luxury tend to be smaller but small size is no guarantee that they'll just say no to the flavor aid.