Interesting Links for 20-05-2018

[andrewducker]

This is the very opposite of my experience with Scrum/Agile. Comes across as both needy and arrogant, and I'd hate to have to work with the person who wrote it.

(tags: development software agile programming )

Estonia To Become The World’s First Free Public Transport Nation

(tags: transport Estonia )

The theocratic democracies of Iran and the UK

(tags: religion iran uk politics government )

Why do LGBT LDs get so annoyed when people say the Lib Dems "acheived equal marriage"?

(tags: libdem marriage lgbt )

Five whys and the cult of the root cause.

(tags: process philosophy learning )

Tomorrow's cities: The park with four seasons under one roof

(tags: cities thefuture nature environment )

Targeting job ads at the CEO of the company you want to work for

(tags: advertising jobs )

The prime minister is boiling the Brexiteer frogs: the water is getting hotter and none of them has jumped out of the pan

(tags: UK europe )

Evidence that drinking baking soda can promote an anti-inflammatory environment

(tags: inflammation )

Tories take four-point lead over Labour in latest survey

(tags: politics polls Labour Conservatives )

The cold war nuclear bomb warmed by chickens

(tags: history nuclearweapons chicken )

Comments

[skington]

To take a narrow point about scrum: can we at least agree that daily stand-ups are legitimately terrible? The only purpose that I can see is to crack the whip and make sure that everyone has something salient to report every day.

[elf]

That Scrum/Agile article... It’s well known that creative people lose their creativity if asked to explain themselves while they are working.

Depends on the person and the project. Some thrive if they're explaining as they go along; more can work well with frequent breaks to review progress and confirm that they're working in the direction they want. And many, many people will make better works if they stop partway through and run a checklist of their end goals and check whether they're making the progress they expected.

Good engineers want to work in engineer-driven firms where they will be calling shots regarding what gets worked on, without having to justify themselves to “scrum masters” and “product owners” and layers of non-technical management.

AHAHHA HAHAHAH HAHA no.

I mean. Yes. Of course they do. We all want to work in a company where we decide when and how to use our specialty skills. But if you want a job that's "just code until you have achieved Awesome," start your own business or join a nonprofit. For everyone else... someone who is Not The Programmer will be deciding what the important projects are, and what the deadline is for those projects. In a well-run company, the decision people are taking a lot of feedback from the engineers so their plans and timelines are reasonable.

The worst thing about estimates is that they push a company in the direction of doing work that’s estimable. This causes programmers to favor the low-yield, easy stuff that the business doesn’t actually need

This, I can see as a real problem. Insisting on projects that can be easily estimated, and worse, projects broken into pieces where progress can be measured in two weeks, can be the death of a software company; not everything's going to fit on a chart. But a good manager should recognize that, and be able to tag some projects "no est avbl" and explain to upper management that it's being worked on, but there's no specific and useful progress markers that can be shown.

Anything that’s actually worth doing has a non-zero chance of failure and too many unknown unknowns for estimates to be useful.

I think this has fallen into hyperbole. I suspect there are plenty of parts of every large software project that are worth doing AND relatively easy to estimate how much effort will be required for them. I also suspect these are mostly boring and that software engineers hate doing them.

Technical debt falls in this category - "we know how long it'll take to update the entire database to match the new software requirements, and that's X hours of work that will not improve a damn thing but will allow the company to survive into next year."

Under Agile, technical debt piles up and is not addressed because the business people calling the shots will not see a problem until it’s far too late or, at least, too expensive to fix it.

Erm. The problem with that isn't Agile; it's managers who don't understand that "show what can get done in this two week production cycle" doesn't mean "show how much we'll earn in this two week profit cycle."

... and so on. I can see he's got some points, but most of them seem to be "Agile/Scrm is trendy AF right now, and a lot of businesses are grabbing keywords from it and using it to reinforce their current hierarchy, rather than using it as intended to give some structure to a creative process that's hard to justify to shareholders."

Agile etc

[agoodwinsmith]

I can't remember why I wanted to know about it - I think I was still reviewing job postings and a technical writing job listed knowledge of Agile as valuable - but when I read up about it I wasn't impressed. The focus seemed to be on preventing programmers and writers from doing too much. Just enough programming to barely do the job, and even less writing up the documentation for the programming.

I suppose many companies are working on planned-obsolescence software - something that will be discarded long before it breaks, but I thought that I wouldn't care to work for a company which was only interested in barely-adequate work.

Agile seemed to be both buzzy-trendy and designed to protect and glorify people who like to count things. I mean: there's nothing as satisfying as something well counted.

Baking soda.

[agoodwinsmith]

Thank you for this article.

[(Anonymous)]

Five whys and the cult of the root cause.

For example, you turn on your computer and see smoke rising from the cabinet. You brilliantly deduce that the smoke is probably a symptom of a deeper problem. Should you treat the symptom or fix the root cause? Most of us would treat the symptom by shutting off the power, even though we realize this does not address the root cause.

Actually, I think you'll find that 'electricity is flowing through this thing' usually is the root cause of it overheating and smoke pouring out of it. Stopping electricity flowing through it is fixing the root cause; any of the downstream problems can then be fixed at leisure.

For example, people who type produce spelling errors; in many cases the root cause of these errors is that they never learned to spell

But in many, many more cases the root cause is that they learnt to spell perfectly fine, but their fingers happened to hit the keys in the wrong order. I suspect that the ratio of 'never learnt to spell' : 'can spell perfectly well but hit they keys in the wrong order' errors is something like 97: 3.

For example, let’s say that while sailing you get an alarm indicating high water levels in the bilge of your sailboat. Your immediate intervention may be to pump water out of the bilge. After the water is pumped down you may observe a crack in the hull which you can temporarily plug until you return to port. When you return to port you can have the crack in the hull investigated and repaired. The optimum place to intervene has shifted from pumping, to plugging, to hull repair; thus, it is time dependent.

No one doubts that. The advice to look for root causes is because without it, many people would either set a permanent pump running; or would patch the hole and then set sail again without bothering to repair the hull. Those people are now having Gordon Lightfoot write songs about them.

When you have identified the root cause, you might well realise, 'well, that's what we need to do to fix the problem , but we can't until we're back in port. And we won't make it back to port unless we make a temporary patch. And we can;t do that until we've pumped out the water so we can get at it.'

But until you've identified what's gone wrong, you can't even do that.

What a terrible article.

[coth]

That Agile article was interesting. He has clearly identified some of the failure modes available to the method. While also clearly exposing his own worries and lack of experience.

[miramon]

The Scrum/Agile article is one of the worst things I've ever read on the subject. The author not only totally misunderstands Agile, they even totally misunderstand Waterfall, which takes a lot of work. It's as if it was written by someone who believes that their personal experience is universally applicable and that every project in every area has to work the same way.