How Agile Failed at the BBC and the FBI | Gojko Adzic In The Engineering Room Ep. 3

[@robertruzitschka7154]

Gojko is an amazing story teller - his talks are very inspiring as he synthesizes a lot of knowledge from different areas and presents them in an engaging and lively way. A lot too learn! Thanks, Dave, for bringing him in!

[@micheljtremblay4890]

Very interesting refreshing to be able criticizing big projects .. a good point was... We are measuring too often what is easy to measure and not what it's important to measure... I enjoyed listening this conversation, thanks

[@bakedbeings]

The extra work adding chapters is much appreciated 🙏

[@troelsirgens-mller9922]

Enlightening discussion. I wish The Engineering Room was published as a podcast, it would make it possible to listen to it on the go. KZbin videos are not made for bike rides.

[@mr.ssergeev]

Gojko is one of those people who will drive the people in the industry in following decades. Amazing how many different things he knows and how passionate he is, how interesting his books are.

[@63kOhm]

gojko is a force of nature. I know it's a strong word, but i love this guy. great talk. i can't belive we got this one for free.

[@vladvesa8296]

I appreciate a lot the book references. Keep these interviews going.

[@jpokroy]

Very interesting discussion! One minor correction about the BBC. The *DMI* programme was indeed a costly & miserable failure, whereas the later *myBBC* programme was in fact regarded as a success (the current BBC Account services that are in use at massive scale across the BBC's suite of products were created under myBBC). This error, repeated by Gojko in his discussion of this topic, is in the article from The Register that is linked to in the description.

[@paladinsorcerer67]

Summary of the talk: 1) come up with many ideas, so that if you reach a dead-end, you can back out of it and switch to a different idea. 2) developers focus on their "zone of control" or "sphere of influence" because its easier to work with what you know/what you can affect. 3) the change in behavior that you witness in users will indicate to you how to change the software. 4) measure what actually gives you value, rather than what is easy to measure. 5) dont measure intermediate steps, rather measure what will get you to the product end-point. 6) adapt and reassess early in a project to avoid spending $50M on a product that delivers no value. 7) monitor the product from the inside and outside of the app, looking for the unexpected. 8) take advantage of the latest abstractions so that a small team can have a big impact. 9) to address apps that have poor performance, look into the levels of your tech stack and identify where the inefficiency is coming from. 10) if edge cases could happen 1 out of a million times, but your users are interacting with the system 1 million times per day, then the edge case becomes one of the main uses cases to address.

[@quinnjones1221]

Gojko is one of the FEW creators of a software system\framework that would ALWAYS answer any question I had on implementation and issues\concerns AND more importantly he always helped me run up the J-Curve especially with DBFIT. I guess what I am saying is you are SPOT ON with your comments about Mr. Adzic

[@dinoscheidt]

I love the story telling in the mid of the talk. Lovely - thank you two!

[@kikitauer]

So this was a delight indeed! Thank you for this interview. I've been thinking about the abstraction state of development and software creation and I share some of your concerns. On the other hand I am very grateful for it because it means I can call myself a web developer while not even a year ago I was working in entirely different field. Anyway I really enjoy this podcast format with various interesting people and I hope there will be many more episodes 😊

[@jonathanaspeling9535]

Super inspired to read a lot more! It's a common thread shared between all industry leaders I've observed. Ferocious Readers! Books are to the mind what the whetstone is to the sword

[@Oswee]

The first thought which comes into my mind is that developers should learn to capture their knowledge early. One of the great discoveries of mine in this context was Zettelkasten method and the Obsidian software. Links and the backlinks is all you actually need to capture and revisit your knowledge. Eventually we all will end up in consulting and and sharing our experience for the new and faster generation. So... to prepare for that we should collect our little gems. I do really love this series!!!

[@fmkoba]

awesome!!!! I love Gojko’s books and talks

[@stochasmvid]

Awesome! I'm at this very moment playing with Narakeet. You WILL see videos soon! My experience trying to make videos is exactly what his "About" page talks about. This is totally transformative.

[@BryonLape]

I normally don't click videos that have agile capitalized, but I made an exception based on the Martin Fowler and Allen Holub chats.

[@callumw9067]

thanks - very similar conversations we are having in the world of security - too many security solutions focus on nothing that gives business value (or anti-value) because it is too hard to. It also doesn't help that the core security glitterati have never built systems before and are so behind with modern systems thinking.

[@anj000]

Cloud is just someone else's computer. I get the sales pitch, but I really think that it will back fire hard time. We are basically giving all the power to very few companies. It simply can not end well. True power and beauty of the internet is that anyone can join in. Someone can write piece of HTML on their computer and essentially put a site world wide. Just because humans are greedy and want cheep solutions to complex problems (essentially that means cloud), we are giving up this freedom. This process is slow and you won't notice much difference only carrying about day-to-day work, but when we go 100% cloud we could never go back.

[@centerfield6339]

"Stateful serverless" - see Clouflare Durable Objects. Fascinating.

[@edwardharman1153]

I work for a popular website where I learned about A/B testing. My favourite test was when we made the "View Deal" button slightly larger and the data showed that more people clicked it! I felt obliged to mock up a page design where the button was 50% of the page. (Then there were the multiple different colour tests... I think orange was good)

[@ContinuousDelivery]

Did people like the big button? 🤣

[@mirzasisic]

I love Gojko's Bug Mangnet extension, I use it almost every day.

[@alex_2_]

Very interesting and insightful! Thanks!

[@abhai-1996]

18:31 - "very often what people do in our industry is measure something that's proportional to effort rather than measuring the outcome". Slow claps

[@DerylSpielman]

Cloud is so difficult for big business because there is so much process built around whatever already exists it's hard to justify changing anything if it "just works". I believe there isn't enough "observability" on lead/cycle time metrics across business processes, services, and dependencies to understand whether cloud makes an improvement to either time-to-market or speed. You also just can't lift and shift because how you write/architect apps directly impacts cost in the cloud. E.g. a loop making many calls to a messaging system may go past the limit of free requests and programming in the cloud you might change the content of the message so you're not requesting as much. It's a total paradigm shift.

[@RixtronixLAB]

Vote up, nice video clip, thank you for sharing it :)

[@aleksandarpavlovic5052]

High value content, many thanks! Could you please post the link to the referenced Microsoft study ``where they reckoned two thirds of their ideas provide zero or negative value``?

[@ContinuousDelivery]

It's from this paper exp-platform.com/large-scale/

[@chaoslab]

Thank you to you both. Any one else miss 68000?

[@miodragradosavljevic8517]

Svaka cast Gojko ! Nema tvojih knjiga na Srpskom ?

[@gojkoadzic7231]

nema, nazalost nije dovoljno interesantno za domace trziste.

[@dxhelios7902]

The main issue with agile is unpredictable budget - it is "by design". Otherwise it is not agile. May work well for startups and in internal teams. Headache for software production houses.

[@Modzybear]

When it comes to dumb measurements I would often point out that it is easier to measure the temperature of a boiling pot of water with a thermometer than developing a system that calculates an estimate based on the number of bubbles.

[@slr150]

21:19 You're talking about a centrifugal governor.

[@cyberpunkdarren]

Agile is a bloated mess. Endless meetings. Too many roles, charts, terminology. Nothing like what was originally intended.

[@elfnecromancer]

That's not agile. You are probably talking about Scrum or Scaled Agile (SAFe). Scrum is a methodology older than Agile often mistaken for Agile, which it is not. SAFe is a fraud.

[@dawidwielgos1080]

@@elfnecromancer I doubt he is talking about scrum. It has three roles only and 4 meetings that are supposed to take care of all meetings you should have.

[@cyberpunkdarren]

@@elfnecromancer Gotcha. Then yeah. What you said.

[@cyberpunkdarren]

@@oraclesofspin Endless. That's right. Lots of meetings that go on forever. Tell me. Do projects on github use these meetings? No.

[@cyberpunkdarren]

@@oraclesofspin people who develop complex projects on github and in fact the entire workflow of github projects is "meetingless". Now im not saying within a business you cant have meetings AT ALL. But the current agile, scrum, safe landscape is obsessed with meetings. When i say 'endless' i dont mean the duration of the meetings i mean the recurrence of them. That should have been obvious. These meetings are more ceremomial and rarely productive.

[@miletacekovic]

Pozdrav za Gojka od bivseg kolege iz Finsoft-a.

[@rukekakambari4314]

I think Gojko has seen a lot and has more to say but time is a big constraint. I wonder how is like to work with him. I really like people discussing how things works under the hood instead the just it works kinda devs

[@konnaf24]

"get the protocol right" what is a protocol in this context? Examples?

[@John99lm]

is there a tldr version? please! I'm interested in the topic but find this video too long

[@ContinuousDelivery]

No, this is all there is. There is a timeline showing topics in the description.

[@John99lm]

@@ContinuousDelivery thank you! I'll watch the video sometime later

[@tomtomtomtom691]

Gojko Andzić sounds like Slavoj Žižek but without the ticks and going off on tangents.

[@alessandrob.g.4524]

Dude never lets Farley talk lmao

[@dxhelios7902]

Nothing about what was in the title. At least one thing is right: serverless is the cloud, containers is big BS that must die in pure form. Should be wrapped in serverless. Containers suck from maintenance and security perspective, host interaction. Discussion starts with some idols and books. 30 mins passed - still idols and books. Pfff. So what went wrong? @Dave "you don't need to take care about the tech underneath with serverless". Data exfiltration? Enterprise security? Hybrid? You need to take care. Effort is smaller of course. Maintenance simpler. But we need 5 years to make it standard - to minimize effort. Today we try to mirror on-prem in the cloud, we need to transition firmly to be able to mirror cloud in on-prem. Then we can say more or less "you don't need to take care". "Inconsistency is fact of life" - agree. You have to make eventual consistency fact of life as well and adjust to biz reqs. "Where to keep state?" Not a lot of choice: RDBMS and/or Cosmos DB. Lakes are for inactive states. Nothing else was invented yet. Cosmos DB is actually good. Support for eventual consistency is of course an issue that should be solved in both theory and in products.

[@xtrailz]

Gojko - "if you are the BBC and are funded by public subscription you can waste as much money as you want" Yeah, that's what happens when the service is funded by a compulsory licence fee.

[@MohamedSamyAlRabbani]

DDD and Agile take forever to get nothing done and avoid accountability and measurement

[@seamusconnolly9710]

A bad workman always blames his tools. Agile and Scrum as a framework within is a tool.

[@Daniel_Zhu_a6f]

"Stalin didn't want energy, he wanted a big ***g dam" -- that's just stupid. I mean, Stalin was a communist and communism is naturally about optimization and cybernetics. it was basically born from the idea of transaction cost optimization. it just was not phased in those terms at the time.

[@filips7158]

For the record, Adzic is pronounced Adjitch.

[@gojkoadzic7231]

for the record, it's not :)

[@filips7158]

@@gojkoadzic7231 As the famous Chinese proverb says : "Ko izda -- pizda" :)

[@mihailoterzic3598]

@@gojkoadzic7231 Reci mu bree