mjfisher

The author mentions those at the bottom of the article, but two problems highlighted still remain:

* There's another intermediary concept (kernel density estimation) between the audience and the data

* They're still likely to misrepresent tight groupings and discontinuities, which will be smoothed out

There's a difference between asking someone to invert a binary tree, and asking someone to sum up a list of numbers. The latter finds the people who can't code much more quickly!

That's often not true. Testing more, earlier, tends to surface problems whe they require less work to fix.

Easier context switching, less dealing with extra added complexity between coding the issue and fixing it etc.

I'm surprised no one yet - either in the comments or the article - has talked about the most important and powerful part of Scrum: having a singular sprint goal aligned with a higher level product goal that the entire team is dedicated to.

That it's also the most difficult or commonly ignored part of Scrum might also be relevant.

I kind of do, but the lack of sleep has killed my short term, long term and working memory. The time before is hazy.

> One time I reduced something from a 15 minute execution time to running hundreds of times per second

That's too good a story not to have just a little more detail. Are you willing to share more?

I used to wonder if imaginary numbers were "real" (in the common sense, rather than the mathematical one). This only intensified after I learnt that they're required in quantum mechanics to explain any physical behaviour at all.

Now I consider them to be just as "real" as the integers - which is not at all. Both just human-invented concepts with no fundamental physical basis.

As you point out - useful, though!

I'd agree with Gimp - it's UI makes several departures from other similar software.

But Inkscape's UI seems pretty intuitive?

I take your point about familiarity with GPT4 making this less immediately impressive - but just as an end to end demo it's absolutely mind-blowing how far we've come.

Can you imagine seeing this ten years ago? Moving so far in such a short time frame would have been unbelievable.

This gave me the "I'm actually living in the future" vibes that I always imagined I'd get from flying cars.

There's a difference between input and output metrics to be considered too. Attempting to manage the output metrics directly rather than addressing the underlying causes is almost always the wrong thing to do.

If you assume a starting point that writing is to communicate clearly (as in delivering a thesis or argument) and your writing does not do that, then it's bad writing.

You might not want to assume that. There are other reasons to write ambiguously with excessive and unnecessary ornamentation:

* Everyone else in your field does it, and you want to write in a familiar style

* You hope people confuse the advanced vocabulary in your writing with an advanced argument and it will bolster your credibility

* Pretension: you want to feel clever whilst writing it, or appeal to those who will feel clever whilst reading it

All of those are perfectly valid to my mind - even writing verbosely for the sheer love of the language is fine.

I just don't think this article does any of that well.

"Once you describe something, people tend to believe the description is complete in all cases over time"

Just bad writing.

> The whole process today exists to support a big class of managerial people (including scrum masters, PO's and PM's) whose salary depends on not understanding that the process is completely broken.

I think it's even worse than that - those unnecessary processes only exist to try to help management attempt to manage content they don't understand in the first place.

And I say this as someone who regularly implements said delivery processes for customers.

The other reason the answer to this is "no" is that we don't even really understand how an atom even works its entirety yet. We don't know fundamentally know what makes the potential energy of an atomic nuclear be structured in the way it is.

EDIT: I thought I'd double check that since it's been a while since I studied physics formally; apparently it is possible to model light nuclei[1] (up to four nucleons) from the ground up now!

[1] https://en.m.wikipedia.org/wiki/Ab_initio_methods_(nuclear_p...

[1]

I remember that from a while back, and getting annoyed - it doesn't appear to be something that annoys me at the moment so it might have been fixed, but on reflection I tend to just use the default rich text editor now.

It takes markdownish input but converts it to rich text as you type - so asterisk-space starts a bullet point list, etc.

I actually can't remember if it has a dedicated markdown mode anymore; the rich text editing supports the usual shortcuts that mean I tend to stick with it.

No, Jira loading is relatively OK and on par with other SPAs. It's got a CTRL+SHIFT+P style actions menu for tickets which helps cut down on point and click pain (especially for linking issues etc). Setting up statues and workflows and how they map to a board is relatively straightforward.

There are lots of things where Jira falls short, but the pain points on an under-resourced self hosted instance of ten years ago are nothing like the ones you'll find on Jira cloud today.

The difference is that lowering the estimate for a given amount of work doesn't actually get it done quicker - it just means you have a more unrealistic understanding of the timelines.

You can absolutely work to find other creative solutions to the same problems, or understand what scope is acceptable to cut to meet some goal. That's very different from "I want you to do exactly the same work but just do it faster".

That's a useful tip. I need access to several Microsoft live/AD/teams accounts, and they just don't work well in the same browser session.

I've been using chrome profiles to separate these because the Firefox ones were a little clunky; for some reason it never occurred to me to create shortcuts per profile. Thanks!

I think some of the comments that are writing this off as not very useful are missing a point. Almost all businesses prioritising finite resource should be using some form of CD3/WSJF; but it's very hard to communicate why to stakeholders without diving into some math and graphs that some people have a hard time understanding.

This looks like a really good way of getting people to practice cost-of-delay based prioritisation in a structured, reproducible way that doesn't involve formulas or maths.

Yeesh. I don't envy you there. Did they turn around in the end?

Did the enforcement of state transitions actually make a difference to the underlying work there?

In my experience, if there's a problem with the engineers then all of the process in the world won't fix it.

Kanban is more than just a board. To have effective Kanban your process needs to:

1. Be pull based - someone only picks something new up when they have the capacity to do so. There's no "finish this set of tasks by the end of the sprint" because there are no sprints, just priorities

2. Manage work-in-process, either explicitly or implicitly. This prevents the team working on too many things at once, which leads to any given piece of work taking a long time to get to production

How long do we think it will be before a lot of the recent negative sentiment about Scrum bubbles up to exec-level consciousness?

I've seen (and managed) plenty of Scrum, good and bad. In general I prefer Kanban approaches, but I don't think it's the deciding factor in team performance by itself.

I'm interested to see when we reach the point where it's no longer the default methodology everyone reaches for because "Scrum is how you do agile".

Yeah - start with a monolith as Martin Fowler (the guy who popularized microservices) suggests. Split out services as you understand more about how the business is developing and stabilising.

Sorry, but that blanket statement is just wrong. That is _exactly_ how it's done when I run a scrum team. If it stops being a good fit or working well for any number of reasons, we stop and look at the process.

It works because your stakeholders see that you're actually delivering what you said you would _when_ you would, and that gets you the buy in and authority to run the team in a sane and sustainable manner.

For what it's worth, I prefer Kanban in most cases - but both are just different ways of managing WIP, utilisation and delivery time.

The rational purpose is this: sprints should be a way of trading off lower utilisation for more predictable delivery.

However, your example is unrealistic - you wouldn't split that task into two. If it won't fit comfortably in the sprint it waits for the next one.

It varies hugely by team and process, but where scrum/sprints are a good fit a reasonable first level of sprint loading seems to be a limit at about 70%. E.g. if an engineer has ten days available to work in a sprint, no more than 7 days of estimated work are pushed their way. The other 30% is assumed to be code reviews, meetings, pairing, bugfixing etc.

If that 70% is too high or low, it can be adjusted.

For everything else, there's Kanban.

Nice, thank you! I've read The Egg before, but working my way through the others now as I have the opportunity.

Have you come across The Last Question? Another favourite:

https://users.ece.cmu.edu/~gamvrosi/thelastq.html

Seems a good time to link to the well-loved short sci-fi story "They're Made out of Meat" by Terry Bisson:

https://www.mit.edu/people/dpolicar/writing/prose/text/think...

So is it just a fancy way of saying "every transformation has an axis or origin"?

Absolutely fantastic write up - thank you so much. I will go away and do some further reading!