Podcasts about antipatterns

Brenden Matthews, a seasoned software engineer, entrepreneur, and author of the Idiomatic Rust and Code Like a Pro in Rust books (both from Manning), speaks with SE Radio host Gavin Henry about Idiomatic Rust. They start with a look at what "idiomatic" means, and then discuss Generics, Traits, common design patterns you'll see in well written Rust code, and anti-patterns to avoid. Matthews suggests some tools that can help you immediately write idiomatic Rust, as well as what building blocks can also help. This episode examines what Generics are and how they compare to other languages, as well as what Traits are, how macros help, what a Fluent Interface is, and why unwrap() is bad. They also discuss what code smells to look out for, Clone, Copy, and a really nice place to go read real-world Idiomatic Rust code. Brought to you by IEEE Computer Society and IEEE Software magazine.

Fredrik talks to Dejan Milicic about software development - understanding, methods, and stories. We start by talking about encapsulation of knowledge and the essential software in organizations. Almost every organization should - it can be argued - be developing software that solves their unique problems, and yet so many outsource so much of their knowledge encapsulation. Oh, and we can never completely encapsulate our knowledge in code either, so all the more reason to keep people who actually know what the code does and why around. Dejan tells us about his way to Ravendb and a developer relations role - and how you can craft your own job, stepping suitably outside of your comfort zone along the way. We also talk about shortening attention spans, daring to dig down a bit and find out about the context of things. Like the second sentence of some oft-repeated quote. Prohibit bad things, but help automate doing good things and avoid doing the bad things completely. Dejan shares some database backstories - why would someone want to build one more database? Specifically, what lead to the creation of Ravendb? And the very strong opinions which have been built into it. Avoiding falling into marketing-driven development. After that, we drift into talking about processes and how we work. Every organization is unique - which strongly speaks against adapting the “best practices” and methodologies of others. Or keeping things completely the same for too long. Innovation is also about doing what other people are not doing. Why is concurrency still hard? The free lunch has been over for twenty years! Functional programming and immutability offer ways forward, why aren’t these concepts spreading even more and faster? We get right back to understanding more context when Dejan discusses how few of us seem to have understood, just for example, the L in SOLID. Dive deeper, read more, and you will find new things and come up with new ideas. Finally, Dejan would like to see software development becoming just a little bit more mathematical. So that things can be established, verified and built on in a different way. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We a re @kodsnack, @tobiashieta, @oferlund and @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Dejan Ravendb Informatics Domain-driven design Event sourcing Data is worthless - said in episode 601 Developer relations Nosql databases Jack of all trades Jimmy - who introduced Fredrik to Dejan at Øredev 2024 Hibernate Relational databases Oren Eini - creator of Ravendb Antipatterns n+1 Couchbase Scrum Agile software development The Toyota approach The Scrum guide Unison programming language - VC funded Dr. Dobb’s journal The free lunch is over Concurrency SOLID Liskov substitution principle Repositories on top Unitofwork are not a good idea - by Rob Conery Elm Titles A mathematician turned software developer Coding, but without deadline Saturated with software development Encapsulation of knowledge A bit surreal Accept people as they are There’s a second line Professional depression Prevented, not diagnosed The pipeline kind of thinking Frustration-driven development (You shouldn’t be) Punished for being successful The largest company of his or her life so far Optimized for maintaining the status quo Wash away all the context Manager of one The proverbial Jira Substantial content Methods of moving forward

Groß denken und ständig verbessern In dieser Folge des Power BI or DIE Podcasts spricht Artur mit Martin Bubenheimer, der kürzlich von der Beratung in eine interne Rolle als Power BI Architekt gewechselt ist. Martin erklärt die Vorteile, beide Perspektiven zu kennen und betont die Wichtigkeit, internes Fachwissen aufzubauen. Sie sprechen über die Einführung einer Community of Practice, die Entwicklung von Schulungsmaterialien und die Balance zwischen zentraler und dezentraler Berichtsentwicklung. Martin hebt die Bedeutung der Performance-Optimierung von Power BI-Modellen hervor und teilt Einblicke in den iterativen Lernprozess für die Entwicklung robuster Datenmodelle. Außerdem geht es um sich ständig weiterentwickelnde Power BI-Tools und die Integration neuer Funktionen zur Steigerung der Effizienz und Effektivität. Als Power BI Architect ist Martin neben der Unterstützung von Nutzern und Entwicklern vor allem für die Power BI Governance zuständig. Betriebsmodell und Prozessdefinitionen, Ausbildung der Mitarbeiter, Lieferantenauswahl und Tooleinführungen, Reviews und Deployments, Technologieberatung für neue Anforderungen, User Adoption und Business Continuity sind seine Kernthemen. In seiner Community of Practice finden sich Schätze, die ihr selbst auf YouTube vergeblich sucht. Martin liebt es, DAX-, Power Query- und Datenmodellierungs-Challenges zu lösen.

Antipatterns können nicht nur auf Codeebene, sondern auch auf der Architekturebene auftreten. Sven, Andreas, Christian und Felix diskutieren in dieser Folge die Fallstricke solcher Antipatterns. Sie beleuchten, wie Dokumentation mit ADRs beim Verstehen und Anpassen von Architekturentscheidungen helfen kann und betonen die Wichtigkeit des Kontexts bei der Bewertung von Patterns und Antipatterns. Außerdem werfen sie einen Blick auf die Microsite architecture-antipatterns.tech und laden Euch ein, die Sammlung mit eigenen Case Studies zu erweitern.

Part of every profession is the jargon practitioners adopt. Having a language links people together and creates a sense of community. It also creates private gardens: a profession set off from those around it. Jargon is a form of secret handshake. Jargon is a two-edged sword, both gathering and excluding people. Be wary! We also have a visit from Susan Parente and her Not A Scrumdamentalist column. We discussed her recent mini-sabbatical. Stepping back has the power to clear your mind.  Slay Work Intake Chaos: Become a Master in 5 Weeks! Based on Tom Cagley and Jeremy WIllet's new book , learn to diagnose and solve work intake anti-patterns to stop drowning in work. Work intake is the biggest challenge facing organizations today. If you don't get work intake right, you won't be in business for very long. A 5-week cohort-based course, meeting weekly for an hour, includes teaching, peer feedback & discussion, feedback from the authors, time for Q&A, templates, and an electronic copy of our book, Mastering Work Intake: From Chaos to Predictable Delivery. Are you ready to commit?  Join our cohort-based workshop. The first cohort is starting on March 1st, 2024. Details at Re-read Saturday News This week we tackle two chapters of . We begin with Chapter 9 - VoP, VoC, and Predictability which sums up Section I, Variability and Predictability. Chapter 10, titled Monte Carlo Simulation, Revisited begins Section II, Advanced Monte Carlo Simulation and Predictability. Buy a copy and get reading – .   Week 1: – Week 2: – Week 3:   –   Week 4: – Week 5: –   Week 6: –   Week 7: –   Week 8: –   Week 9: –   Week 10: -    Next SPaMCAST  The Software Process and Measurement Cast 796 our conversation with Roger Turnau. Roger and I will delve deeply into prioritization using the cost of delay. Every organization and team I have ever worked with has a backlog of work and lots of people screaming that their piece of the backlog is the most important. Cost of delay is an important tool to filter out the noise.  

Laura Tacho, CTO @ DX, joins us to discuss why changing what you measure doesn't necessarily lead to improved productivity (and what to do about it)! How to define and measure productivity in your eng org is one of the hottest topics for eng leaders… We cover best practices for identifying what productivity looks like in your org, what motivates your team to reach those goals, how to harness behavioral psychology, and antipatterns to avoid when you focus on productivity. Plus Laura shares some of her favorite practices to identify your skill gaps, and how define what success looks like for yourself and your teams on your productivity journey.ABOUT LAURA TACHOLaura Tacho is CTO at DX, a developer experience company. She previously led teams at companies like CloudBees, Aula Education, and Nova Credit. She's an expert in building world-class engineering organizations that consistently deliver outstanding results. Laura has coached CTOs and other engineering leaders from startups to the Fortune 500, and also facilitates a popular course on metrics and engineering team performance."That is just a ripe environment for the rapid degradation of trust within an organization and has immeasurable consequences when it comes to degrading the culture of a team. I think the temptation is there, understandably, and I think from good intentions of, ‘I want to try to measure unobtrusively. I want to get this data about my team without them knowing about it or minimally knowing about it so that I'm not bothering them.' That is a trap because we don't need to treat people the same way we treat distributed systems with dashboards and dashboards of telemetry data. People can talk. Just ask them.”- Laura Tacho   This episode is brought to you by incident.ioincident.io is trusted by hundreds of tech-led companies across the globe, including Etsy, monday.com, Skyscanner and more to seamlessly orchestrate incident response from start to finish. Intuitively designed, and with powerful and flexible built-in workflow automation, companies use incident.io to supercharge incident response and up-level the entire organization.Learn more about how you can better identify, learn from, and respond to incidents at incident.ioInterested in joining an ELC Peer Group?ELCs Peer Groups provide a virtual, curated, and ongoing peer learning opportunity to help you navigate the unknown, uncover solutions and accelerate your learning with a small group of trusted peers.Apply to join a peer group HERE: sfelc.com/peerGroupsSHOW NOTES:Why people care so much about measuring productivity in engineering (3:25)Antipatterns to avoid when tightening focus on productivity (5:08)The role of behavioral psychology with engineering productivity (7:04)What the ideal consulting relationship looks like structurally (8:58)Ensure you're incentivizing the behavior you want to achieve (12:20)How to cultivate the skill of influencing without feeling too “salesy” (13:59)Understanding the different facets / types of motivation (17:08)Strategies for developing resiliency in “do more with less” environments (19:14)Behaviors that prevent eng orgs & leaders from achieving their goals (23:55)How to identify areas of personal development & closing the skill gap (27:00)Areas that are the most ripe for setting the right expectations / outcomes (29:40)Best practices for eng leaders to gain clarity & define what success looks like (32:01)Rapid fire questions (35:52)LINKS AND RESOURCESRemarkably Bright Creatures -Shelby Van Pelt's exploration of friendship, reckoning, and hope, tracing a widow's unlikely connection with a giant Pacific octopus.This Podcast Will Kill You - Grad students studying disease ecology, Erin and Erin found themselves disenchanted with the insular world of academia. They wanted a way to share their love of epidemics and weird medical mysteries with the world, not just colleagues.lauratacho.com - Laura's website where you can find more information about her courses, coaching, and management program.This episode wouldn't have been possible without the help of our incredible production team:Patrick Gallagher - Producer & Co-HostJerry Li - Co-HostNoah Olberding - Associate Producer, Audio & Video Editor https://www.linkedin.com/in/noah-olberding/Dan Overheim - Audio Engineer, Dan's also an avid 3D printer - https://www.bnd3d.com/Ellie Coggins Angus - Copywriter, Check out her other work at https://elliecoggins.com/about/

In vielen der vorherigen Podcastfolgen haben wir immer wieder einzelne Verhaltensmuster von Product Owner*innen angesprochen, die wir als Produktwerker eher kritisch sehen. Daher war es an der Zeit, eine Episode zu veröffentlichen, in denen Dominique und Oliver einmal viele relevante Antipattern an einer Stelle zusammenfassen. So bekommst Du als PO die Chance, diese Antipattern mit Deinem Verhalten zu vergleichen und ggf. kritisch zu hinterfragen, ob Du an dem einen Muster arbeiten möchtest. Die beiden klären zuerst ihr Verständnis von Antipattern, unter denen sie Lösungsansätze verstehen, die ungünstig oder schädlich für den Erfolg der eigenen Produktentwicklung oder des eigenen Unternehmens sind. Dabei unterteilen Oliver und Dominique diese PO Antipattern in drei Bereiche: eigenes Verhalten, Zusammenarbeit mit den Developer bzw. Produktentwicklungsteam und Kommunikation mit den Stakeholdern. Wir üblich versuchen die beiden auch ganz konkrete Beispiele aus ihrer eigenen Erfahrung sowie Tipps und Tricks zu nennen, wie ich an mir als Product Owner:in arbeiten kann, um wirksamer in meiner Rolle zu werden. ANDERE PODCASTFOLGEN, AUF DIE VERWIESEN WIRD Nein sagen als Product Owner Dein Freund der Scrum Master Seine Stakeholder kennen und richtig analysieren Epic. Sinnvoll oder nicht?

“The goal is not Agile. The goal is not DevOps. The goal is not Cloud. The goal is value, time to value, safety, happiness, and quality." Jonathan Smart and Simon Rohrer are the co-authors of “Sooner Safer Happier”. In this episode, Jon and Simon shared how we can deliver better outcomes in a more humane way of working, by delivering better value sooner, safer, and happier. They shared several principles, patterns, and anti-patterns described in the book, such as focusing on outcomes, the leadership as team number one, intelligent flow, creating alignment, and having the ability to unlearn and relearn.   Listen out for: Career Journey - [00:03:41] The Age of Digital - [00:06:29] Patterns & Anti-Patterns - [00:11:15] Better Value Sooner Safer Happier (BVSSH) - [00:13:18] Focus on Outcomes - [00:17:06] Empower the How - [00:19:28] Role of Leadership - [00:23:30] Leadership Team is Team #1 - [00:26:41] Intelligent Flow - [00:31:28] Stop Starting, Start Finishing - [00:34:43] Building Alignment - [00:36:48] Limited Velocity to Unlearn and Relearn - [00:40:10] 4 Tech Lead Wisdom - [00:43:41] _____ Jonathan Smart's BioJonathan Smart is co-founder and CEO of Sooner Safer Happier, a thought leader and a coach. He has been an agile and lean practitioner since the early 1990s and the lead author of the award winning and bestselling ‘Sooner Safer Happier: Patterns and Antipatterns for Business Agility'. He is also the founder of the Enterprise Agility Leaders Network, a member of the Programming Committee for the DevOps Enterprise Summit, a member of the Business Agility Institute Advisory Council, a guest speaker at London Business School, and speaks at numerous conferences a year. Simon Rohrer's BioSimon Rohrer has been a hands on practitioner across both software engineering and enterprise architecture for over twenty-six years, and has had a passion for agile software development since picking up the eXtreme Programming white book in 1999. He's passionate about an eclectic and pragmatic approach to modern ways of working, incorporating lean, agile, systems thinking, DevOps and other principles and practices at the right pace and in a human context in enterprises, typically with a legacy of existing technology and a drive to do things better. Follow Jonathan and Simon: Jonathan Smart's LinkedIn – linkedin.com/in/jonathansmart Simon Rohrer's LinkedIn – linkedin.com/in/simonrohrer Website – soonersaferhappier.com Slack – soonersaferhappier.com/community _____ Our Sponsors Are you looking for a new cool swag? Tech Lead Journal now offers you some swags that you can purchase online. These swags are printed on-demand based on your preference, and will be delivered safely to you all over the world where shipping is available. Check out all the cool swags available by visiting techleadjournal.dev/shop. And don't forget to brag yourself once you receive any of those swags. Like this episode? Show notes & transcript: techleadjournal.dev/episodes/144 Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Buy me a coffee or become a patron.

In dieser Episode geht es um die Bedeutung von effektiver Teamarbeit und Führung. Mein Gast Jens Möhrenschlager argumentiert gegen die Idee, jede Entscheidung ins Team zu übertragen und betont die Wichtigkeit von emotionaler Intelligenz und effektiver Kommunikation innerhalb von Teams. Es wird auch über Antipattern wie das Team-Reporting und die Bedeutung von Indikatoren für die Sozialisierung des Teams diskutiert. Jens teilt Erfahrungen seines eigenen Teams während der Corona-Krise und erzählt von einem inspirierenden Beispiel für lebendigen Austausch seiner Teammitgliedern innerhalb einer Diskussion. Für Jens ist es wichtig, dass Führungskräfte einen Rahmen setzen und dem Team dabei helfen sich mit den Stärken und Schwächen der Teammitglieder auseinanderzusetzen. Dadurch verbessert sich die Entscheidungsfindung und Zusammenarbeit im Team.

Agilisierung und Versicherung? Warum Spotify kopieren eine oder auch keine Lösung ist? Agilisierung ist ein Begriff aus der Unternehmens- und Projektmanagementwelt und beschreibt einen Ansatz, der sich durch Flexibilität, Anpassungsfähigkeit und schnelle Reaktionsfähigkeit auf Veränderungen auszeichnet.Wir stellen Ralf Oestereich,  CIO/CDO der SDK  zur Rede ...Sind wir nicht schon alle agil in der Branche? So scheint es zumindest, wenn man die Branchenvertreter:innen auf dem ein oder anderen Event hört.Mal Hand aufs Herz, ist Agilität nicht auch häufig übergestülpt und eigentlich mehr Wasserfall als agil?Was sind die Eckpfeiler von Agilität? Beeing agile vs. doing agile - zwischen Werten, Prinzipien, Praktiken und Methoden...Was sind eigentlich Antipattern bei der Agilisierung?Und was sind die Lösungen?Wenn ihr erfahren wollt, vor welchen Herausforderungen die Branche steht, was die Learnings eines erfolgreichen und etablierten Versicherungsunternehmens sind und welche Rolle der Vorstand hier spielt, dann hört unbedingt rein.Unser Gast: Ralf Oestereich >> Co-Autor des Buches "IT-Operations in der Transformation: Zukunftsweisende IT-Betriebsmodelle zwischen „Hey Joe“ und „NoOps""Co-Host: Julius KretzCo-Host: Alexander BernertCo-Host: Sebastian LangrehrFolge uns auf unserer LinkedIn Unternehmensseite für weitere spannende Updates.Unsere Website: https://www.insurancemondaypodcast.de/Du möchtest Gast beim Insurance Monday Podcast sein? Schreibe uns unter info@insurancemonday.de und wir melden uns umgehend bei Dir.Vielen Dank, dass Du unseren Podcast hörst!

To get the show notes as well as get notified of new episodes, visit:  https://www.scalingpostgres.com/episodes/258-logical-replication-database-antipatterns-max_wal_size-delete-vs-truncate/ In this episode of Scaling Postgres, we discuss use cases for logical replication, database anti-patterns, how to set max_wal_size and the difference between delete and truncate.

Programming is terrible, At least according to the author of this week's article: "Repeat yourself, do more than one thing, and rewrite everything," on the Programming is Terrible blog. We talk about our experience with some of the pros and cons of some of these, and then delve into Dyson Spheres, oyster wool, and how Adele disrupted the vinyl industry. In the show we mention: Lessons from Six Software Rewrites Steel Thread programming The Timeline of the Far Future⁠ Music by Hina and Kevin MacLeod

An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.On this episode, we take a look at 13 Backlog Anti-patterns!0:00 Topic Intro0:28 1. Prioritization by Proxy4:36 Tangent on "By Proxy"5:49 2. The Oversized Product Backlog11:16 3. Outdated Issues13:58 4. Everything is Detailed and Estimated16:42 5. INVEST?20:14 6. Missing Acceptance Criteria22:02 7. 100% In Advance26:35 8. No More Than a Title30:41 9. Storage for Ideas34:28 10. Part-Time PO35:48 11. Copy & Paste PO37:17 12. Dominant PO (Spoiler Alert, We Skip It)38:43 13. The "I Know It All" PO41:52 Go-Back: 12. Dominant PO45:29 Wrap-Up----------------------Watch it on YouTubeANDSubscribe to the Arguing Agile Podcast on YouTubeOr listen on: Apple Podcasts:https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596Google Podcasts:https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5idXp6c3Byb3V0LmNvbS8xNzgxMzE5LnJzcwSpotify:https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3Amazon Music:https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-PodcastStitcher:https://www.stitcher.com/show/agile-podcast-2----------------------AA102 - Backlog Antipatterns #agile #productmanagement #podcast

Doc on LinkedIN: https://www.linkedin.com/in/docondev/ Doc on Twitter: @DocOnDev https://twitter.com/DocOnDev Link to by the book ESCAPE VELOCITY: https://www.amazon.com/Escape-Velocity-Better-Metrics-Agile-ebook/dp/B07RWRWKN6?ref_=ast_sto_dp A video of Doc summarizing some of the learns of ESCAPE VELOCITY: Escape Velocity - Better Metrics for Agile Teams | Doc Nortonwww.youtube.com › watch

In this last episode of 2022, Tom, Eyvonne, and Russ sit around and talk about some interesting things going on in the world of network engineering. We start with a short discussion about SONiC, which we intend to build at least one full episode about sometime in 2023. We also discuss state and antipatterns, and finally the idea of acquiring another company to build network resilience.

This interview was recorded for GOTO Unscripted at GOTO Aarhus.gotopia.techRead the full transcription of this interview hereLuxshan Ratnaravi - Co-Author of Comic Agilé and Agile Coach at BankdataMikkel Noe-Nygaard - Co-Author of Comic Agilé and UX Design Specialist at VestasMalte Foegen - Chief Operating Officer at wibasDESCRIPTIONIn many cases, agile practices have been introduced in organizations starting bottom-up. There is, however, a new trend where management is trying to be the driver of agility. Join the discussion with Malte Foegen, COO at wibas, Luxshan Ratnaravi, agile coach at Bankdata and Mikkel Noe-Nygaard, UX design specialist at Vestas, to understand what changes have to be implemented in an enterprise for such a top-down approach. And more importantly, can it be successful?RECOMMENDED BOOKSAino Vonge Corry • Retrospectives AntipatternsGamma, Helm, Johnson & Booch • Design Patterns (Gang of Four)Subramaniam & Hunt • Practices of an Agile DeveloperDerby, Larsen & Schwaber • Agile RetrospectivesJeff Sutherland • Scrum: The Art of Doing Twice the Work in Half the TimeLee, Wickens, Liu & Boyle • Designing for PeopleStone, Chaparro, Keebler, Chaparro & McConnell • Introduction to Human FactorsTwitterLinkedInFacebookLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted almost daily

Jon Smart, author of the book Sooner Safer Happier: Patterns and Antipatterns for Business Agility, discusses patterns and anti-patterns for the success of enterprise software projects. Host Brijesh Ammanath speaks with him about the various common...

We talked about: Irina's background Irina as a mentor Designing curriculum and program management at AI Guild Other things Irina taught at AI Guild Why Irina likes teaching Students' reluctance to learn cloud Irina as a manager Cohort analysis in a nutshell How Irina started teaching formally Irina's diversity project in the works How DataTalks.Club can attract more female students to the Zoomcamps How to get technical feedback at work Antipatterns and overrated/overhyped topics in data analytics Advice for young women who want to get into data science/engineering Finding Irina online Fundamentals for data analysts Suggestions for DataTalks.club collaborations Conclusions Links: LinkedIn Account: https://www.linkedin.com/in/irinabrudaru/ ML Zoomcamp: https://github.com/alexeygrigorev/mlbookcamp-code/tree/master/course-zoomcamp Join DataTalks.Club: https://datatalks.club/slack.html Our events: https://datatalks.club/events.html

Jon is a business agility practitioner, thought leader, and coach. Jon is the lead author of the award winning and bestselling 'Sooner Safer Happier: Patterns and Antipatterns for Business Agility' (IT Revolution Press, Nov 2020) and co-founder of Sooner Safer Happier Ltd, helping large organizations deliver better value sooner, safer, and happier through the application of better ways of working, including agile and lean principles and practices. Topics Jon's book and his background OKRs and focusing on Outcomes Anti patterns and patterns for business agility Achieve big through small Building the right thing Creating a learning eco-system Jon's LinkedIn - https://www.linkedin.com/in/jonathansmart/ Buy the book - Sooner, Safer, Happier

Is low code an automation anti-pattern? Do the majority of organizations recognize the value of AI-augmented DevOps? And what are the top application security trends for 2022? Find out the answers to these and all other and full pipeline DevOps automation testing, performance testing, SRE, and security testing in 10 minutes or less. This episode of the TestGuild News show is for the week of August 8th. So grab your favorite cup of coffee or tea, and let's do this. Time News Title Rocket Link 0:24 Create a FREE Applitools Account https://rcl.ink/xroZw 0:48 API Testing Resources https://testguild.me/hmhoop 1:06 ERP Report https://links.testguild.com/nuLrD 1:55 LOW-CODE ANTI-PATTERN? https://testguild.me/td4ebv 2:46 LambdaTest https://testguild.me/labndaaug7 3:52 Modern Cross Browser Testing with Selenium in Java https://links.testguild.com/8rpgN 5:15 Appium Wait Plugin  https://testguild.me/appiumwait 5:58 Early Hints speed up page loads  https://testguild.me/hhe5mi 6:51 AI-DevOps Survey  https://testguild.me/ergrhb 8:09  Top Application Security Trends for 2022? https://testguild.me/knywoo 9:06 Free Developer Tool  Open Source Security & SBOM Creation https://testguild.me/vy8agd  

“An engineering manager should make sure that the team has a good balance of delivering things that the business needs with enough capacity to do it sustainably over time." Patrick Kua is a seasoned technology leader with a passion to accelerate the growth and success of tech organisations and technical leaders. In this episode, we discussed Pat's latest course, Engineering Manager Essentials, which covers all the building blocks required to be an effective Engineering Manager (EM). We first discussed what an EM role is, how it differs from a tech lead role, and the common manager vs IC career track. Pat shared his view on why being an EM is not a promotion and what are some of the success criteria to be a good EM. Towards the end, Pat shared some anti-patterns that EM should avoid to become successful. Listen out for: Pat's Latest - [00:07:30] Engineering Manager Essentials - [00:09:25] The Role of Engineering Manager - [00:11:21] Difference With Tech Lead - [00:14:19] Manager and IC Paths - [00:16:28] EM Is Not a Promotion - [00:21:02] EM Success Criteria - [00:28:08] Multiplier Instead of Maker - [00:30:48] Course Structure - [00:33:21] Interviewing EM - [00:37:20] Antipattern 1: Continuing as a Maker - [00:39:58] Antipattern 2: Assuming Everyone Knows What You Do - [00:43:01] Antipattern 3: Optimizing Parts Instead of The Whole - [00:48:34] 3 Tech Lead Wisdom - [00:51:30] _____ Patrick Kua's Bio Patrick Kua is a seasoned technology leader with 20+ years of experience having done a wide variety of roles including being a developer, tech lead, consultant, CTO and more. His current mission is accelerating the growth of technical leaders through coaching, mentoring and training. Follow Patrick: Website – https://patkua.com/ Twitter – @patkua LinkedIn – https://www.linkedin.com/in/patkua/ EM Essentials Course – https://www.patkua.com/em-essentials/ Tech Lead Academy – https://techlead.academy/ Level Up Newsletter – https://levelup.patkua.com/ Our Sponsors DevTernity 2022 (devternity.com) is the top international software development conference with an emphasis on coding, architecture, and tech leadership skills. The lineup is truly stellar and features many legends of software development like Robert "Uncle Bob" Martin, Kent Beck, Scott Hanselman, Venkat Subramaniam, Kevlin Henney, and many others! The conference takes place online, and we have the 10% discount code for you: AWSM_TLJ. Skills Matter is the global community and events platform for software professionals. It is an easier way for technologists to grow their careers by connecting you and your peers with the best-in-class tech industry experts and communities. You get on-demand access to their latest content, thought leadership insights as well as the exciting schedule of tech events running across all time zones. Head on over to skillsmatter.com to become part of the tech community that matters most to you - it's free to join and easy to keep up with the latest tech trends. Like this episode? Subscribe on your favorite podcast app and submit your feedback. Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Pledge your support by becoming a patron. For more info about the episode (including quotes and transcript), visit techleadjournal.dev/episodes/94.

In episode 31 of The Gradient Podcast, Daniel Bashir speaks to Preetum Nakkiran.Preetum is a Research Scientist at Apple, a Visiting Researcher at UCSD, and part of the NSF/Simons Collaboration on the Theoretical Foundations of Deep Learning. He completed his PhD at Harvard, where he co-founded the ML Foundations Group. Preetum's research focuses on building conceptual tools for understanding learning systems.Subscribe to The Gradient Podcast:  Apple Podcasts  | Spotify | Pocket Casts | RSSFollow The Gradient on TwitterSections:(00:00) Intro(01:25) Getting into AI through Theoretical Computer Science (TCS)(09:08) Lack of Motivation in TCS and Learning What Research Is(12:12) Foundational vs Problem-Solving Research, Antipatterns in TCS(16:30) Theory and Empirics in Deep Learning(18:30) What is an Empirical Theory of Deep Learning(28:21) Deep Double Descent(40:00) Inductive Biases in SGD, epoch-wise double descent(45:25) Inductive Biases Stick Around(47:12) Deep Bootstrap(59:40) Distributional Generalization - Paper Rejections(1:02:30) Classical Generalization and Distributional Generalization(1:16:46) Future Work: Studying Structure in Data(1:20:51) The Tweets^TM(1:37:00) OutroEpisode Links:Preetum's HomepagePreetum's PhD Thesis Get full access to The Gradient at thegradientpub.substack.com/subscribe

Ziel-Definitionen und Mitarbeiter-Metriken: Sinnvoll oder totaler Blödsinn?Das Thema ist heiß umstritten. Viele lieben Ziele im Job. Andere sind eher auf dem Trichter von “Wer misst, misst Mist.”. In dieser Episode sprechen Wolfgang und Andy über individuelle Ziele, Team-Ziele und über die Frage, ob sich das Team in die richtige Richtung bewegt. Unter anderem mit Fragen wie, ob es immer mathematisch messbare Ziele sein müssen, wie man mit subjektiven Zielen umgeht, ob man Lines of Code messen sollte, was die Velocity aus dem Scrum Framework mit OKRs zu tun haben und noch vieles mehr.Bonus: Wieso Österreicher Podcasts anschauen können und was das Fortuna Düsseldorf und das Sams mit der ganzen Sache zu tun hat.Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKioskLinksReddit-Disukssion: https://www.reddit.com/r/de_EDV/comments/uhnn4c/wie_werdet_ihr_als_mitarbeiter_und_euer_team/Sentry: https://sentry.io/OKR Beispiele für Software Teams: https://www.koan.co/okr-examples/engineeringOfficeVibe: https://officevibe.com/DevOps-Kultur: Organisationskultur von Westrum: https://cloud.google.com/architecture/devops/devops-culture-westrum-organizational-cultureCircleCi Engineering Kompetenz-Matrix: https://docs.google.com/spreadsheets/d/131XZCEb8LoXqy79WWrhCX4sBnGhCM1nAIz4feFZJsEo/edit#gid=0DORA Metriken: https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performanceSprungmarken(00:00:00) Intro(00:01:37) Helft uns mit eurem Netzwerk durch eine Podcast-Empfehlung(00:02:02) Wie kam das Thema dieser Podcast-Folge zustande? Team Metriken, Einzel-Metriken und Performance-Metriken von Mitarbeitern(00:06:06) Drei Kategorien: Individuelle Ziele, Team-Ziele und "Bewegt sich das Team in die richtige Richtung?"(00:06:36) Individuelle Ziele: Warum ist das Thema relevant? Warum sollte man sich über Ziele unterhalten?(00:13:50) Objective Key Results (OKR) als mögliche Ziele(00:18:09) Die Kritik von Objective und Key Results als individuelle Ziele(00:21:19) Transparenz von Zielen im Team und in der Firma(00:23:44) Planung und Ziele ist unnütz und Overhead(00:25:05) Antipatterns und Ziele die man vermeiden sollte(00:26:31) Was ist die Velocity innerhalb vom Kontext Scrum? Und wie sollte diese Metrik bewertet werden?(00:31:27) Die Nutzung von Code- und Software Repository Mining-Metriken als Basis zur Zielsetzung(00:37:12) Team-Metrik "Happyness" und wie man es messen kann(00:42:22) Das Westrum-Modell, OfficeVibe und Google Forms(00:45:43) 360* Feedback: Was ist es und die Kritik am System(00:52:26) Vergleichbarkeit von Software Engineers und Levels(00:57:45) Jobtitel und individuelle Ziele und höhere Erwartungen(00:59:00) "Bewegt sich das Team in die richtige Richtung?", DORA-Metriken und Well-Rounded Software Engineer(01:03:30) Zieldefinitionen sind nicht einfach und Kontext ist King(01:07:46) OutroHostsWolfgang Gassler (https://twitter.com/schafele)Andy Grunwald (https://twitter.com/andygrunwald)Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk

This interview was recorded at GOTO Copenhagen 2021 for GOTO Unscripted.gotopia.techRead the full transcription of this interview hereAino Vonge Corry - Author of "Retrospectives Antipatterns"Klaus Bucka-Lassen - Agile Midwife, Coach & Trainer at aragostPreben Thorø - CTO at Trifork SwitzerlandDESCRIPTIONLearn the difference between effectiveness and efficiency and whether your team can be agile without knowing it in this Unscripted episode, recorded at GOTO Copenhagen 2021 with Aino Vonge Corry, author of “Retrospective Antipatterns”, Klaus Bucka-Lassen, agile coach and trainer and Preben Thorø, CTO of Trifork.RECOMMENDED BOOKSAino Vonge Corry • Retrospectives AntipatternsGamma, Helm, Johnson & Booch • Design Patterns (Gang of Four)Subramaniam & Hunt • Practices of an Agile DeveloperUncle Bob • Clean AgileDerby, Larsen & Schwaber • Agile RetrospectivesJeff Sutherland • Scrum: The Art of Doing Twice the Work in Half the TimeLee, Wickens, Liu & Boyle • Designing for PeopleStone, Chaparro, Keebler, Chaparro & McConnell • Introduction to Human FactorsTwitterLinkedInFacebookLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket at gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted almost daily.Discovery MattersA collection of stories and insights on matters of discovery that advance life...Listen on: Apple Podcasts Spotify

We end this season with a look at using patterns and anti-patterns throughout your work.  The value they provide is obvious and costs little.  We gain the lessons learned from others and have those available for our projects.  Those experiences are valuable to us and jumpstart our solutions. Using Patterns Patterns are just that.  They provide a recommended series of steps or an approach.  However, they are not the solution.  We need to use these tools as an outline or guide to building our specific solution.  That means we may need to add or subtract from a pattern to make the most of it.  Do not consider these to be hard and fast rules.  Rather, review them and determine where they can inform the solutions you are building. Avoiding Anti-Patterns I often think of anti-patterns as a slippery slope warning sign.  Just as everything about patterns is not all good, anti-patterns are not full of mistakes.  We often see that anti-patterns arise from the best of intentions or at least the goal of getting things done quickly.  We can make those trade-off decisions without falling into an anti-pattern.  On the other hand, the point of an anti-pattern is to warn us as to where a few small steps in a direction can lead to great strides.  Think of these as caution signs that make us aware of the danger ahead.  Avoid them if you can and be intentional about taking these steps when you do not have better options. Challenges Whether embracing patterns or avoiding anti-patterns, every problem is unique in some way.  Thus, we need to use these as suggestions and cautions.  We can easily fall into a trap when we take a general concept like patterns and force our solution into it.  Allow for tweaks and customizations as you use these for the greatest impact. At the end of the project, it is still your unique solution that is created.

The BHAG or Big Hairy Audacious Goals approach to vision or roadmaps is often recommended.  The objective is to keep from limiting ourselves.  The problem is that too much of a good thing can turn into a mental block or analysis paralysis.  Too many options or too many tasks to complete is often overwhelming. The Big Hairy Audacious Goals Anti-Pattern Defined This anti-pattern occurs when the focus is on the overall goals or scope rather than what is in front of you.  There is a difference between seeing a goal and being able to complete it today.  While people generally see that difference, it is not always made clear. That can lead to a sort of "are we there yet, are we there yet?" drumbeat.  Urgency has its uses.  However, there are times when it gets in the way.  This anti-pattern is just one example.  The problem is that we spend time planning out some grand strategy or reviewing all that needs to be done instead of actual work.  We end up concerned more about all we have to do instead of doing it. Avoiding The Anti-Pattern I often think the Alcoholics Anonymous approach of "one day at a time" is more of a life suggestion.  It also has a biblical root in the idea of each day has enough worry for itself.  Do not worry about tomorrow.  To be clear, that is not an admonition to only focus on the step in front of you.  However, there are times when we are looking too far ahead and stumble over something right in front of us.  This anti-pattern is best avoided by good estimations and communication.  We keep our focus short-term or tactical through most of the project.  That allows us to make steady progress and not get worried about how long the journey may be. For example, a tightrope walker needs only worry about the stem they are taking instead of how many more steps they need to cross the gap.  Our approach can be the same.  An attempt at embracing the whole project or scope can be daunting and install fear or stress.  We can avoid that and stay positive by taking smaller steps. Challenges The start of a project, in particular, can lead us to look at the overall plan.  All of those tasks and steps leave opportunities for missteps and mistakes.  All of that summed up risk is often worrisome and leads to mitigation strategies.  Too much focus on mitigation can leave us struggling to take the first step.  Furthermore, how much of that worry about risk will end up being useful?  If we take a proper step then worry about the misstep was somewhat misplaced.  As always, everything in moderation.

We looked at an incorrect focus based on faulty data analysis in our prior episode.  This time we explore solving the wrong problem with the misdirection anti-pattern.  While this situation can arise from the data bigotry anti-pattern, it is often a failure to grasp requirements fully.  It is a problem that comes from improper focus and lack of communication.  Those are two prevalent weaknesses in a project that lead to challenges and even failure. The Misdirection Anti-Pattern Defined This anti-pattern is simply defined.  We are not solving the correct problem.  Yes, there is a  problem described, and it might even be correctly addressed.  However, it is a red herring of sorts and not what we need to solve to make the customer happy.  Similarly, it may solve the problem but in a completely irrelevant way.  That second situation can make this tough to assess.  Likewise, it can render an entire architecture obsolete or insufficient. The Anti-Pattern In Action The misdirection anti-pattern often arises when the focus is on the answer rather than solving a problem.  Thus, we can even pass through QA and testing with flying colors.  We get the correct answer while reaching it incorrectly.  When we "show our work" for the solution, we get a zero for that portion.  Similarly, the incorrect solution will often fail to address outliers adequately and may fail to solve it for all happy paths. My favorite example is a request from years ago.  We spent weeks working on building a report that could display hundreds of thousands of rows in a reasonable amount of time.  The query result set was huge, and even paging was slow.  They needed the whole report but only cared about the last page.  That is where the misdirection anti-pattern became apparent.  The actual goal was to get a count of records.  The details of each record were not helpful in this situation.  Thus, the query only needed a summary and not all of that detail.  Unfortunately, this is not at all uncommon.  There are many examples of reports and results with a lot of detail that is often ignored.  The wrong problem was solved.  Therefore, the summary data provides the answer, while the details are extra work that is not needed.   Avoiding The Anti-Pattern There is a useful method architects use to gather requirements.  They follow each answer to a requirement by, "and then what?"  That approach helps us avoid this anti-pattern.  It requires a solid understanding of the problem and also its context.  We can not ask about pain points and then jump right to relieve those.  Instead, have a conversation around the issues and obstacles that highlights the various options available.  This process includes suggesting a couple of solution approaches to determine whether the pain point is the source of the problem.  It is like a doctor that asks a patient what hurts, and instead of addressing the hurt, they dig to find its source.

This podcast season is a great excuse to highlight new anti-patterns.  We look at a new one we call statistical bigotry in this episode.  That is an excellent emotional word and a common challenge across many areas of problem-solving and debate.  This anti-pattern appears when we give too much weight to our data and improperly use statistics. Statistical Bigotry Defined We use data and facts to support our decisions regularly.  However, we can not blindly use data in this way.  We need to ensure the basis for our decision is based on overall reality instead of a small subset.  When we improperly use a small subset to assume the whole, we are committing statistical bigotry.  The issue may arise from anecdotal data or other situations where the information is given more weight than it deserves. For example, we see this in cultural discussions all the time.  An example is when someone says everyone or no one they know does or believes X.  That may be entirely true.  However, it is also utterly irrelevant to the discussion. The Anti-Pattern In Action Statistical bigotry is a focus problem when crafting solutions.  We spend too much time or resources on something that appears essential but is not.  Thus, the solution is imbalanced in its approach.  Unfortunately, It is not always immediately apparent.  For example, we may think a particular feature needs to be highly tuned due to its use.  Then, when it goes out to real users, we find that highly tuned functionality is rarely used, and another one was ignored that is needed. This situation also can arise when we start to see actual data in a system.  Row counts and result sets are different in reality than we saw during development, and performance bottlenecks arise.  The issue is not that we did not tune our solution.  We just misplaced the emphasis.   Avoiding The Anti-Pattern This anti-pattern is one of focus.  We will see others in this area, and intelligent testing is often the way to avoid these anti-patterns.  While the testing will not reach the "real world" data levels, it will help us see where our focus has been in more of an apples-to-apples comparison.  The issue of spending too much time on one area at the expense of another is far more likely to appear as a result.  Ideally, testing also brings in more real-world usage than during development.  Likewise, it provides a different and new view from the implementor's focus.

We have highlighted many areas of quality software development.  However, the stovepipe enterprise is a maintenance anti-pattern.  This situation occurs when we build a system that has a high maintenance cost.  Even worse, maintenance often requires to be done quickly and more as a patch than a build.  Therefore, we produce a house of cards that becomes more fragile as time goes by. Stovepipe Enterprise Defined Stovepipes are historically a form of a kludge.  Wood-burning stoves needed a way to get rid of the exhaust, and it goes through the pipe.  However, the material often wears down a stovepipe quickly, and it is patched with whatever materials are available rather than replaced.  We see this in software solutions when we have high maintenance areas of the architecture.  That frequent touching of the system can introduce bugs and reduce the overall quality.  Stable is better today, but it also makes it likely we will have working software tomorrow. The Anti-Pattern In Action There are a few typical results from this anti-pattern.  One is the constant requirement for coding (bugs or enhancements) to an area of the solution.  Another is a form of fire-fighting approach to parts of the system.  In the latter case, we regularly see issues in code sections and have to do a quick fix rather than refactor or redesign.  The solution itself is essentially flawed in this case, even though it does the job.   Avoiding The Anti-Pattern Shortcuts are a leading indicator of stovepipe enterprise.  We make design decisions or craft solutions that are suitable but not ideal.  Sometimes a less-than-ideal solution works out fine.  For example, in an 80-20 approach, the "eighty percent there" portion of it supports our needs.  On the other hand, that last twenty percent is needed to provide a complete solution.  The missing pieces change maintenance and stability in many solutions.  That is where the anti-pattern starts to show.

The "warm bodies" anti-pattern is sometimes subtle.  However, it can be frustrating and sink more than a project.  This approach is based on the fallacy that more developers or resources will create better software sooner.  Instead, the reality is closer to the idea of getting nine women to give birth to a baby in one month. Warm Bodies Defined This anti-pattern is an attempt to work faster or get a project back on track by adding resources.  It often is identified by a manager hiring more team members to address complex or time-consuming parts of a project.  Unfortunately, architecture is not immune to this.  The challenge comes when the architecture is complex, and there is a temptation to fix that by creating a more extensive implementation team to compensate.  That is where the anti-pattern rears its head. The Anti-Pattern In Action Fortunately, this anti-pattern is easy to spot once it kicks in.  The response to design and architecture challenges is to add to the team.  When team size is driven by architecture or design, you are on the slippery slope to an anti-pattern.  It harkens back to a common practice in the past of improving an application response time by purchasing more or larger servers.  Resources are not a good way to fix design flaws.  Likewise, laws of time and physics preclude the "warm bodies" approach to improvement.   Avoiding The Anti-Pattern Simplicity is always going to be the better approach than a complex solution.  We can avoid this anti-pattern by sticking to realistic expectations and designing accordingly.  Part of your estimation strategy and improvements should be an attempt to determine minimum time frames around projects.  For example, you will find a minimum time required to create even the most straightforward solution given unlimited resources.  General overhead and interactions make it impossible to do better.  Once you know some basic metrics like minimum deployment time, you can set baselines and assess estimates.  Glaring mistakes and over or under-estimating will make it easy to adjust and get on track before this anti-pattern appears.

Full video interview available here: https://youtu.be/oJbZF1yiWvg  Guest Bio: Aino Vonge Corry (born 1971 in Aarhus, Denmark) is an independent consultant, who sometimes works as an agile coach. After gaining her Ph.D. in Computer Science in 2001 she spent the next 10 years failing to choose between being a researcher/teacher in academia, and being a teacher/facilitator in industry. She eventually squared the circle by starting her own company, Metadeveloper, which develops developers by teaching CS, teaching how to teach CS, inviting speakers to IT conferences, and facilitating software development in various ways. She has facilitated retrospectives and other meetings for the past 15 years during which time she has made all the mistakes possible in that field. Aino has lived in Stockholm, Lund, and Cambridge, but she is now back in Aarhus, Denmark, where she lives with her family, and a growing collection of plush cephalopods.   Social Media/ Website LinkedIn https://www.linkedin.com/in/aino-vonge-corry-9a23801 Twitter: @apaipi Website: https://metadeveloper.com   Books/ Resources Retrospectives Antipatterns by Aino Corry https://www.amazon.co.uk/Retrospectives-Antipatterns-Aino-Corry/dp/013682336X Coaching Agile Teams by Lyssa Adkins https://www.amazon.co.uk/Coaching-Agile-Teams-ScrumMasters-Addison-Wesley/dp/0321637704 Agile Retrospectives by Diana Larsen, Esther Derby https://www.amazon.co.uk/Agile-Retrospectives-Making-Pragmatic-Programmers/dp/0977616649 Retrospectives for Organisational Change by Echstein https://www.amazon.com/Retrospectives-Organizational-Change-Agile-Approach-ebook/dp/B07NS796KY Fearless Change Patterns by Linda Rysen https://www.amazon.com/Fearless-Change-Patterns-Introducing-Ideas-ebook/dp/B0054RGYNQ Prime Directive by Norm Kirk https://retrospectivewiki.org/index.php?title=The_Prime_Directive   Full Interview Transcript Ula Ojiaku: Many thanks Aino for making the time for this conversation and for being my guest on the Agile Innovation Leaders podcast. Aino Corry:  And thank you for inviting me, Ula. It was great to have you in the course, you had a lot of good questions. And that's how we met. And I've been looking very much forward to this day. Ula Ojiaku: So could you tell us a bit about yourself, you know, who is Aino Corry? Aino Corry: Yeah, so Aino Corry is 50 years old, she lives in Denmark, she's got three children. And she, she's always wanted to teach. Actually when I was in primary and secondary school, I wasn't so happy with mathematics teaching, so I decided after school, I wanted to be a mathematics teacher in secondary school. Actually, I thought about it and I thought I didn't really like school. So maybe I should be a teacher in high school instead. And so I decided to try to go to university to study mathematics to become a high school teacher. But then I had to do some programming in the mathematics course. And I really, really fell in love with that. So I changed subject to computer science. And then I did my Master's degree with a focus on design patterns, which was very new at the time. And when I finished, I wanted to continue working with design patterns. And that's why I applied for a Ph.D. I applied for a Ph.D., actually, just to prolong my university studies to make more of the fun thing that I've done. And then when I finished, I thought, I wanted to be a researcher and a teacher and I had a job at the university as an assistant professor. Aino Corry: And then I decided that I wanted to go out in industry instead, because I, I had a child already, and I wanted to have another child. And I really, I was dead poor, so I wanted to earn a lot of money, so I went down industry to get some money. And that worked, I got some money. And after a few years there, I went back to university to do some research and some teaching, because they had a research project, which was interesting. It was when Bluetooth was quite young and was about programming pervasive computing devices, what you would call IoT today, yes. And then I was there for a few years, and then went back to the industry, and was there for a few years. And then I went back to university. And then I did my research in how to teach computer science and how people learn. So that was also interesting. But then I wanted to stop again because then I was full-time at university and I also did some consulting in the IT industry. So I thought I would go back to the industry. Aino Corry: And then I thought, Naah, I want to do something else. I want to be my own boss, I don't want to work that much anymore. I had three children at the time. So I decided to be an independent IT consultant, thinking that then I would work less, that was a huge mistake. I, I like having my own company, but I wouldn't say that I work less because if you have a job and you have a boss, you can tell your boss ‘Oh, it's too much. I don't want to do that much. And please take some of the tasks away from me.' But when you're your own boss, and you're a time optimist, like I can be, you think ‘I can do that. And I can do that.' And especially now with COVID, it's even worse because at least prior to this, I had to calculate time in to get from one meeting to another, you know, from one client to another from one country to another. But now I can actually I can work with clients in four different countries in a day. And I've actually, one week I spoke at six different conferences in one week. So normally I would only be at one conference. So it's actually made me a little bit confused and looking very much forward to actually spending time on trains and planes and cars again, Ula Ojiaku: To have the downtime… Aino Corry:  Yes, I thought I'd never miss that, but I do, so I guess I guess that's my career. Ula Ojiaku:  Great. Now, just a little bit more about your research you did on teaching, on how to teach computer science. Now I would expect there would be an intersection of you know, disciplines; it wouldn't just be computer science itself. Was there an element of maybe psychology (of), you know, how people learn and all that? Aino Corry: Yeah, it was a lot of that it was about, well, the psychological aspects of how people react to different, being in different situations, and being spoken to in different ways. And there was something that I don't think maybe you call it neurology but thinking about how to model the brain in order to make it remember what you're saying. And just something like what does it actually mean to learn something? And in Danish, the word for teaching and learning is the same word, but in English teaching and learning are two different words. And that's actually a subtle difference, which is a big difference, which makes it maybe even harder for me as a Dane to start thinking about this because you think about it as the same process. Aino Corry: But it's two very different processes. And one of the biggest things that I learned when I started doing research and teaching, and that was after having taught for 16 years or something like that, the thing that I learned was that I was so immensely focused on how to condense this book into presentations and assignments so that the students could listen to me and do the assignments. I didn't think enough about the relation between the student and the material. So I was thinking more about the relation between me and the material, and me and the student. So the really important thing is that, when you have any sort of conversation with people, it's a student, or it's a presentation that you're doing, what you want to do is that you want to change their brains really, right. But you can't see the change in the brains. So you need to figure out how can I, how can I assess that they've changed the brain? So, the first thing you have to do is think about what is it actually that you want them to be able to do differently? Do you want them to say something else? Do you want them to be able to program, to design, to facilitate, what is it that you want them to do? Because then you can set up? What is the assessment? How do you assess what they can do? Do they actually have to look at the design at an oral exam? Do they have to process some words in a written exam? What is it that you want them to do? And then when you know what you want them to do to assess it, then you can figure out what is it that you want them to do while training do you want them to do the same when you're training them, that they have to do in the assessment. Aino Corry: So that the exam is actually what they have been doing for the past hour, month, year, instead of examining something completely different than what they have been doing. And then when you know all that, then you start thinking about okay, so what material do I need for them to read? And that's, that's actually the last thing. And prior to this, I would take a book and I would think, this is the thing that I want to put in their brains. And then at the exam, I would ask them, do you understand that? Can you explain that, but maybe they never explained it during the course, maybe they just did exercises or something like that. So that was one of the most surprising things is I guess, maybe it's neurology, maybe it's psychology, it's definitely different. It's lending, from different fields. And, and you can say that the computer science part of it is actually the least part. But the interesting part about computer science and teaching computer science or natural sciences is that it's mostly not so much about discussing things. It's more about being able to understand things and relate things and apply things. Now, I guess well, you can say that all issues, all subjects are like that. But with the natural sciences, it's much more about understanding the world, changing the world. So yeah, I think it's very interesting, but also trying to explain difficult subjects to people. How do you actually do that? Ula Ojiaku: So you've already mentioned that you, you know, started your business because you wanted to be an independent, and then you realized, oh, well, there are other things because as a business owner, you probably would do all the other admin tasks that someone else would have in person. Yeah. Now, am I right? In the understanding, you still run, you know, your business, which is the meta developer, right? Do you have employees right now? Aino Corry: No, I don't, and I don't want to. And I've had a lot of people asking me over the years if I want to employ somebody and I, I did try once for just a small gig that I needed a helping hand and I employed that person and that person was not a problem, but all the extra paperwork, with taxes and insurances, and what do I know. So if I'm working with people, now they have their own company, and then they can send me an invoice and then I can pay them like that because I really want to be independent and five, no six years ago, my family and I, we moved to Cambridge in the UK for a year. And it was so easy for me, I could just do it because even though I had to really work a lot less because I didn't have my network in England and I had three kids who had to move to a different country so I had to focus on them. I could just do it, I could just work less and not make any money or almost no money. Because I didn't, I wasn't responsible to anybody, I was only responsible to myself. That gives me the freedom that I want to have. And during COVID I lost everything in my book. My calendar just was empty. Wow. And I didn't know how to continue with the company. But I only had to worry about myself. I didn't have to worry about anybody that I employed. So that was nice. Ula Ojiaku: Yes, I completely agree. I mean, it would be a lot of responsibility, having other people's livelihood as well as yours to think about that. Yeah,  Aino Corry: Especially. I mean, this is such a fluid thing. It's difficult to promise anything. Ula Ojiaku: Now, but hopefully, with the, you know, lockdown restrictions on I mean, unfortunately, we're still not out, you know of the red and unfortunately, many lives have been lost, and many people have been affected but it seems like there is light at the end of the tunnel with the (covid) vaccination (roll-out) and all that. So would you say your calendar is filling up again? Aino Corry: Yes, it actually became overfilled, yeah during COVID. Because my book came out. So I had hoped that when my book came out, I would travel everywhere in the world and sign my books. Unfortunately, that couldn't happen because of COVID. But that's the least of the things that could happen to people during COVID. I've been very lucky. But my book came up... Ula Ojiaku: Retrospectives Antipatterns… Aino Corry: Yes. and, and that meant that there were a lot of people who wanted to talk to me about retrospectives, which was why I wrote the book. So that was great. So I don't know if it had filled up as easily without the book, but it definitely helped, I think. But I'm looking so much forward to getting out and speaking at conferences again. I taught at the university yesterday, and I will again tomorrow. And that was in real life. It was so nice, people were laughing and we were clapping. And we were like doing icebreaker exercises where we were standing up and moving towards each other. And it was really nice. Ula Ojiaku: Yeah, I mean, nothing can ever replace that, you know, face-to-face in-person interaction. Whilst we're grateful for technology, you know, for bridging the gap, you know, but once in a while, it's definitely important. Yeah. Great. Now, so since you've shown us your book, Retrospectives Antipatterns. And you've talked about it briefly, why don't we delve into that a bit. And for the audience who are listening either (via) audio or video only, there will be the links to the, you know, to the book, and other resources that we touch on in the show notes. So what you said people were, you know, asking you lots of questions about retrospectives, and asking for advice, which was one of the motivations for writing the book. Could you tell us the story behind that? Aino Corry: I love to tell the story behind the book. Thank you for asking, Ula. So I started facilitating Retrospectives because Linda Rising gave me a book by Norman Kerth called Project Retrospectives. And then I started facilitating them. And then Diana Larsen and Esther Derby wrote a book about Agile Retrospectives - Making Good Teams Great, which condensed all the retrospective activities into smaller bite-sized ones that you can use after each sprint. And I facilitated retrospectives at in the time I worked for a company called Trifle, inside Trifle with the customers. When I went back to university, I facilitated retrospectives there. And I just really, really liked it. I even facilitated retrospectives with my family and myself, and everybody basically who couldn't get away. And I, I got a lot of experience. And then once I was at a conference that I'd been part of organizing the conference and inviting speakers and what I do at these conferences is that if a speaker gets sick, or can't be there, then I fill in with a presentation. So they came to me and asked me is ‘Could you fill in with a presentation? Just 20 minutes?' ‘Okay, I said, When do you want it?' And they said ‘In 20 minutes, and we would want it to be a new talk, could you do that?' I was like, how can I? How can I prepare a new talk in 20 minutes for a 20-minute talk? And then I thought the only thing that I really, really know about that I can talk about for lengths, are all the mistakes that I'm continuously making when facilitating retrospectives So I thought this is definitely something I can talk about. So I just, I just, I think I drew some pictures, or I found some pictures online. And then I just spoke out from those I, I spoke about three different things that I called Antipatterns for Retrospectives, things that often go wrong for me and how to solve it. So not just explaining the problems, but also how to get out of the problem situation. And they really liked it. And then I started giving that talk. And I extended it to 45 minutes to an hour, I extended it to a day. And people kept asking me, ‘Where can we read more about this?' And I said you can't really because it's, it's in my head. And then somebody said ‘Maybe we you should write a book.' And so I thought I'm not going to write a book, I already did my Ph.D. dissertation, and I'm not doing that again. Not the best part of it for me. But then I started just writing, you know, first, it was just a few Word documents that I shared with people in my retrospective network. And they gave me feedback on that. And then I started a Leanpub book. And it turned out people wanted to buy the Leanpub book. So I thought, well, maybe I should add some more chapters. And then I thought it would be interesting to see if there's any publishers who would like to publish it. Aino Corry: And luckily, I have a very good network in IT, so I asked a lot of people who are already authors and, and Martin Fowler introduced me to somebody from Pearson, Greg Dench, and he, he read my book, the PDF that I sent from Leanpub, and he said that they thought they'd like to publish it. And there was a lot of back and forth and back and forth. And could you change the title? Because Antipatterns sounds so depressing and negative? And I said, but it is an Antipatterns, so I cannot. And then those things about I want this octopus, this big octopus? Ula Ojiaku: Yes, yes. Aino Corry: Well, it looks a little bit like a children's book, are you sure you want it to look like a children's book and I said actually, I'm, I'm really like a child myself. So I want it to be me. And then I said, and it has to be printed in color. Because I want all these Antipatterns to have not just a name, but also a picture. Because with Antipatterns, what you do is that you create an awareness, so I described, this is the context you're in, this is what normally happens, but that's the Antipattern solution. That's actually another good solution that gives you these drawbacks. But then you have the refactored solution, which gives you these benefits. And I want the patterns as well as Antipatterns, it sort of enables you to have a discussion and a higher level of extraction. So you can say, for instance, with patterns, you can say, then I use the observed or I implemented composite, and then you don't have to explain all the nitty gritty details. And it's the same with these Antipatterns. So instead of saying, ‘Well, we tried to vote, but then some people held up their vote, and I allowed them to do so. But maybe I could have done it differently', you can just say, well, then I ended in political votes. And there's also the name and then the picture because for some people, the name is easy to remember, but for other people, the picture. Ula Ojiaku: The pictures, yes. Aino Corry: I definitely am very visual. So I, I really remember pictures like that. And graphs, it really helps me understand I love UML, and when I work with architecture, it's very important for me to be able to draw these things. So that's how the book came about. And there were other publishers who didn't want it because they thought it was not technical enough or they didn't like the Antipatterns in the title or they thought it was too negative, but Pearson wanted it, so that's great. I'm very grateful for that. Ula Ojiaku: That's fantastic. Again, we'll have the link to the book in the show notes. And I mean, so I do identify with, you know, the things you said or where you kind of held your ground and in terms of how the book was meant to look for pictures. And if it's playful, it's easier to absorb. There is the saying in English, you know, a picture is worth more than a thousand words. Definitely. And in that way, you're kind of trying to cater for different people with different learning styles, because there are some of us who can read you know, but pictures kind of makes it, breaks it up and kind of, you know, conveys the message even more effectively in some instances. On that note though, are you, do you already have an audio version of it? Or do you think it would bode well as an audio version? Aino Corry: Yeah, that's a bit embarrassing, Ula, because I have narrated, I think five of the chapters. But then I stopped, but I will narrate it. I am doing it and it will happen, hopefully, yeah, but it turns out it's much more difficult to make an audiobook than you think I want to narrate it myself. I agree. Have you tried it? Ula Ojiaku: Well, no, just with, you know, starting the podcast and you know, kind of speaking, there is a whole lot to it. So I can imagine trying to bring a book to life, you know, kind of enunciating, and there'll be some places you need to emphasize. That's why I've never done it yet. But I can imagine. Aino Corry: Yeah, well, I could have hired an actor to do it, but I wanted it to be me, because it's my experience. It's, it's my voice that should be in this book. And then so I'm Danish and English is my second language. I normally think, Okay, I'm pretty good at English, I can speak fluent English, people understand what I'm saying I can express myself and the book is written in English. But then when you start recording it, and you'll listen to it afterwards, you make so many mistakes, or at least I do. So I have to repeat that again. So it just takes a lot longer than I thought, but it will be there, it's my plan. Ula Ojiaku: We'll be looking out for it, definitely, yeah. Okay, so, in your view, what are Retrospectives, and why are they important? Aino Corry: Well Retrospectives is a way for a team to set time aside to reflect on where they are, inspect, you'd say, and learn from, that, appreciate what happened, and see how can we improve going forward, the way that we communicate, the way that we work, the way that we program or design, or whatever we do. It's simply taking time aside to appreciate and inspect and then adapt to the situation. In a sense, it's the core of Agile, right, inspecting and adapting. And for a team to have regular Retrospectives, I think it's so important. Sometimes they'll think we don't have anything to talk about, we don't have any problems. But there's always something that can be improved, even if it's a small thing. And having those regular Retrospectives helps you remember, to continue to improve in all different aspects, but also, I think Retrospectives is a way to gain trust between team members, it's not the only thing you need to gain trust, but that sharing thing that showing, “Okay, that didn't go very well”, or “I need to learn this”, or “I got stuck with this”. But also, “I was really happy about this”, ”this made me so energetic, and really optimistic about these things”. It helps people understand each other as human beings and as sort of parts of the machinery or parts of the system, that's the team or even the organization. So I think it's important in all aspects. And for everybody. Ula Ojiaku: It's interesting, your definition of what a retrospective is, and I'd never really thought about it as a way for team members to, you know, build trust with themselves, so thanks for mentioning it, that really stood out for me, do you have any examples in your experience where, you know, this happened where there was maybe little or no trust and, you know, subsequently through the Retrospectives the team, started having more trust towards themselves? Aino Corry: I would like to say yes, but I have to say that when I realized in the retrospective that there's not enough trust, it is something that you have to work with also between the Retrospectives in a sense if there is not enough trust to share anything, then, then the retrospective will not be trust-building in itself, but it can help you reveal that there is not enough trust, and then you can start working with it, and to me trust is sort of the equation between relationships and that you can rely on people that you rely on people and you have a relationship. So if you have a relationship, if you know a little bit about each other as human beings, it makes it easy for you to trust people. And also if you can rely on other people, for instance, if they say, ‘Oh, I'll do this', then they'll do it. Or they'll say they can't do it, that's part of the trust as well. And if you understand, if you learn at the retrospective that there isn't enough trust, the retrospective can become a waste of time. Aino Corry: Because if they don't want to share the things that are really difficult, then you will just talk about the meal in the canteen, or whether we should have a meeting that's two hours long, or one hour long, or something like that, which is not really changing anything. It's usually things about how to give feedback or whether the code reviews can be done in this way or the other and whether we need to learn something more. So, but you can definitely be aware that there's trust issues that you can work on outside the retrospective, but then I think another important thing is that if they have already sufficient trust to be able to share things, then I've heard from a lot of people that it can, it can feel almost like team therapy to have a retrospective because they don't have to think about it, they can sort of relax and let the facilitator carry the conversation forward sometimes. And then if it can help them say, now, we talk about this, Now perhaps we've talked enough about this, now we should talk about this or could you see this from the other side, which is something that I sometimes do as well. So it can be a little bit conflict handling as well to be a facilitator to say what did you hear him say right now? Or can you imagine what his day was like yesterday or something like that? So it can be therapeutic if you want to, but that depends on the facilitator. You can also have a retrospective facilitator, which is perfectly fine, but only wants to talk about how we can improve the way that we actually design things, the architecture we make, the meetings we have, it can still be helpful, doesn't have to be therapy, but it can. Ula Ojiaku: Yeah. In running the retrospectives I would assume, I would imagine, there would be some sort of advanced preparation from a facilitative perspective. Now, would you when you get asked to do this by you know, other organizations and teams? Do you normally have a point person and you'd get the brief in terms of what they're trying to achieve from the point person, and that would set the agenda? So have you always found yourself sticking to the agenda? Or have you ever had to kind of flex depending on what you sense the team needs? Aino Corry: Yeah, I've definitely had to change my agenda. So if I get invited to facilitate a retrospective, I talk to the one who sponsors me to ask them why, why have you reached out? Do you already have Retrospectives? If you have Retrospectives, why do you need an external facilitator? What normally works for you in retrospective? What doesn't work? Is there any conflict? I should know about it? Is there anybody who's really quiet? Anybody who's really a loudmouth? Is there anything that can help me plan this retrospective in the right way? Then sometimes they say, oh, we'd really, really like this retrospective to focus on how they can learn as a team, or we'd really like this to focus on their communication with other teams. And then in some, sometimes I'll say, okay, so, so we'll say that's the theme for the retrospective. And then I'll let people know that that's a theme for the retrospective. But other times, if it's a new group, then I'll probably encourage that sponsor to allow me to make some, just a generic retrospective. So for a new group who has to work together, maybe he or she will allow me to create a futurespective for them, which is the kind of retrospective where you imagine that you're in the future, looking back at what happened. And then they say, okay, then we, then somebody got fired, or this didn't work, or the users hated it. Aino Corry: And the way that I have this futurespective, with the new team is that then I get to understand and they get to understand about each other. What do they hope and what do they feel will happen in this project, and then we can have action points, which will allow them to get the things that they hope and avoid the things that they fear. So sometimes I'll let the sponsor know, well, actually, we should do it a little bit different way. And sometimes I'll say, that's fine, we'll focus on that. But it is often so that you need to have an extra agenda when you prepare for a retrospective, at least a little bit. Because sometimes you suddenly end up in a situation where you have somebody who's speaking all the time or somebody who's really quiet. And then all the plenary discussions that you decided on, you can't have those because plenary discussions are not very nice if you have like a big difference in how much people wants to speak. And then you have to divide them into smaller groups, or you have to change it in writing. Or you have to make round robins where everybody takes turns in saying something, so just as an example. But it could also be that you notice that all the things that they're talking about are problematic, turns out to be things that we think are sort of out of their hands, not really something they can do anything about. And then if you spend all the time discussing things that you can't change, then it's just like a session where you're just complaining about everything. And in those cases, I sometimes get out the soup exercise that I learned from Diana Larsen where you make the three circles, things the team can do, things the team can influence, and then you have the soup outside. And then I say well out of all these problems that you're complaining about, how many of these are things you can do something about, how many of these things you can influence, how many of these things are in the soup, and for the things in the soup, you might just have to accept that this is the world we live in, like Corona right now. Yeah, It's what it is. Ula Ojiaku: Amazing. So, so what would you say would be, from what you've observed, I'm sure you've had a spectrum of or a continuum of teams from what you'd consider high performing to maybe people… I mean, a team that's still up and coming. What would be your view of the characteristics of a high-performing team? Aino Corry: Yeah, that's a good question. In my experience, it's not so much the individual's skill set that makes a high-performing team, an individual with the highest skill set can do a lot on its own. But if we talk about a high-performing team, it's about a team that can communicate, it's about a team where you feel there's psychological safety to say when you're stuck, or when you need help. Because if you're only working on what you want, first and foremost, and only helping other people, if you really have to, then it's not really high performing, and things will clot up and it'll be slow. One of the symptoms that I see in teams that are high-performing is that they're laughing together. So I evaluate sometimes teams based on how much they laugh, and not how much they laugh over each other, but how much they laugh together. And how, yeah, I think, I think it's a good litmus test. Because if they laugh together, then it makes them happier for each other, because the laughter starts, you know, all the happiness hormones in your brain and sensing around your body. So if you laugh together with somebody, you like them a bit more. And if you like them a bit more, you might trust them a bit more. And if you trust them a bit more, you might reach out and ask for help. Or you might offer help, when you see that somebody needs it. And if you are in an environment where you will you think that you can work freely, and you can speak freely, and you feel nice, then you're much more efficient together with other people. So that's what I see in high-performing teams. Ula Ojiaku: I mean, everything you've said because I was going to ask you to define for the benefit of the audience who might not be familiar with the term what psychological safety is? So would you say, you know, it's pretty much what you've broken down, you know, how much they laugh together, how safe they feel in asking for help, and, you know, yeah, being able to work together. Aino Corry: Yeah, I think that Gitte Klitgaard has, has taught me one of the most important things about psychological safety. And that is that it's actually not about being comfortable all the time, but it's about feeling comfortable about being uncomfortable. So even if you're saying something, which doesn't feel nice, you should still feel comfortable about it. And I think that's an interesting difference. So it's not just about making everybody feel good all the time and not having problems and only laughing and talking about positive things. That's not psychological safety. It's being okay to say I have a down day, or it's being okay to say that I don't understand what you're saying, or I feel negative, or I'm worried about this, or I don't think that this was done well enough, we could do it differently, that to me is psychological safety. Ula Ojiaku: Would you say that psychological safety, you know, having an environment that encourages the sense of psychological safety, is that only up to the team to foster? (If not) So who else would be involved, in your view? Aino Corry: I think that there's a culture in an organization and there can definitely be a culture of organizational safety and there can be a culture of non-psychological safety. And if, if the management is also showing that they're comfortable with saying uncomfortable things, I think that helps. If they're comfortable with saying, ‘Oh, we didn't do very well about that, or I made a mistake, or, if they're okay with telling people to do things differently, instead of making it really awkward or being very angry about it. That's, that's brilliant. And I remember one of the great managers, I had once that I made a huge mistake, that was really embarrassing. And when I noticed it, I felt so bad. I was beating myself up about it, but I had to tell my manager, and I had to come forward and say I messed up completely. And the way that he reacted was just wonderful. He said, ‘Well, we'll have to look into that. We'll have to figure out how we can change the process so that that doesn't happen again.' Because of course, I mean, I probably could have avoided that mistake if I thought about things in a different way. But what he said was that we should have a process where you know, that you should do this at this point in time, that should help you, support you. And I thought that was one of the things that created psychological safety for me because now I felt much safer about saying that I had a problem or made something wrong. Ula Ojiaku: In facilitating retrospectives, because you mentioned earlier that if there was anything you could talk about at length, you know, without needing preparation, it would be about the mistakes you've made in facilitating retrospectives. And hence, maybe they could also be some of you know, lead to some of the Antipatterns, could you share some of these Retrospective Antipatterns that you've observed? Aino Corry: So one of the Retrospective Antipatterns that I see most often or that I ran into most often myself is the one that I called Prime Directive Ignorance. So the Prime Directive is what Norman Kerth wrote about retrospectives. There was a longer text that states ‘everybody did the best they could at all times, and remember that before you enter a retrospective', but the problem is that, at least in some of the organizations that I've worked in with some of the people that have worked, they thought it was a bit ridiculous to expect that everybody did the best they could all the time. And to really believe that they couldn't have done any better, because they knew that somebody was slacking. They knew that somebody was being lazy. They also knew that they themselves didn't do the best they could. Aino Corry: So how could they really, genuinely believe that? So sometimes I've had retrospectives where I didn't, I didn't state that, I didn't say it out loud, I didn't state in an email or the invitation, I didn't say remember, this retrospective is not about finding a scapegoat or naming and blaming, it's about figuring out how we as a system of people can move on better together. And then I've had some awful retrospectives where some people had been made scapegoats, and they got really sad, and some of them left the retrospectives because they didn't feel safe. And then, and I think some of them may never have entered a retrospective again because it really ruined it for them because in their head now, the retrospective is a free for all, just sending arrows towards somebody, some poor person and shaming them and blaming them. So I think that the Prime Directive Ignorance Antipattern is one of the most important ones and the refactored solution, obviously, in the Prime Directive Ignorance is not to ignore the prime directive. So remember to bring it, put it on the poster in the wall, say it out loud, write it in the email, you can do it with your own words, it doesn't have to be in Kerth's words, if you like your own words better. But just make sure that people try to do that. Because the thing that Norman Kerth wanted to achieve with this was that people had the mindset of everybody did the best they could. But it's difficult to have that mindset. We're probably all brought up with our parents asking who left the milk out on the morning table? Who broke that vase, who started that fight, right? We're always trying to find a scapegoat and punish them. Although it's not very constructive, not even with children, and not even with grownups either to find that, it's, it's better to figure out how can they play? And where can they play so that they don't break the vase? How can we remind people to put milk into the refrigerator? Instead of saying you're stupid, you're forgetful, you're lazy, right. But I also appreciate that it might be a bit naive, that you might think, okay, but they could have just done a little better. But helping them out with processes, I think it's a good idea. Ula Ojiaku: With reference to the Prime Directive, you know, one of my mentors said something to me that also stuck which is that, you know, most people come to work wanting to do their best job, but sometimes it's the system that restricts them. So if we, like you said, you know, kind of move away from trying to find a scapegoat or someone to point the finger at, you know, to blame for what's going wrong, can we look at how we can shape the system in such a way that those things, you know, it would be hard to fall into those mistakes because the system is already shaped in a way that would help them focus on the right behaviours and practices and not fall into the wrong undesired ones? Yeah. Amazing. Any other Antipatterns you'd like to share? Aino Corry: Yeah, I think that the other one I'd like to share is one that I am becoming more and more aware of how important it is with so many people starting to facilitate retrospectives, because so many people are understanding how powerful it is. A lot of people who maybe aren't, let's say fully dressed, not very experienced in facilitating retrospectives are being thrown into facilitating retrospectives, by people thinking that it's easy. And it's not easy. It's really, really hard. It's hard to do it right. It's easy to understand, but it's difficult to do, it's like that one minute to learn, a lifetime to master. And a lot of people become disillusioned. So one of my retrospective anti-patterns is called the disillusioned facilitator. Because a lot of people are thrown into this role of oh, you can start facilitating retrospectives next week. And then they, maybe they hear something in a podcast like this, oh, this is an activity, you should definitely try it, or they read it online, and then they do it. But then probably they haven't done it before. They're doing it in real life the first time and they might be a bit, not really sure about it, not really having the heart in it. And people can feel that right away. And then they won't put their heart into it either, and then it will fall to the ground, you won't get what you expect to get out of it. So, I always encourage people when they start facilitating to try doing it in a sandbox, first, try out the activities with somebody that you trust and know, maybe you have some other people who want to learn how to facilitate retrospectives, and then you can try these activities out with them. Because explaining these activities can be difficult, coming up with examples that make people understand what they should do can be difficult. But also, really understanding what is the expected outcome, as we talked about right in the beginning Ula, the learning goals, what is it actually that you want to achieve? You're not doing the activity to do the activity, you're doing the activity to achieve something, to figure out what it is you want to achieve makes it easier to perform the right way. So with the disillusioned facilitator what I'm trying to say is, don't worry, you're doing your best the prime directive holds for you as well. Try it out with people, start with things that you're absolutely sure of, take boring activities for a start if you understand how to explain them. And if you understand what the expected outcome is. And we remember to debrief after the exercises to make sure that the people in the retrospective understand what they just got out of it. Because sometimes if you go just from one activity to the other, maybe they're wondering, why did we do that? Why did we spend half an hour on that? They don't understand that actually, what we got out of it was sharing this experience, or perhaps seeing the weight, how many people thought this or something like that? Ula Ojiaku Yeah, never assume, I guess is the cardinal rule there, don't assume, explain why you're doing what you're doing. You're carrying them along on a journey. And you have to (do so) like a good tour guide. This is what I, I tell the teams I coach or some of the coaches that I'm coaching: you're a tour guide, so you have to, you know you're saying ‘this is the destination we're going (to)' and as we get to some notable, you know, attraction points, call it out to them, because you can't assume that everyone is following. Aino Corry No, no Ula Ojiaku Amazing. Now what books, in addition to yours, can someone who wants to learn more about retrospectives and activities, ideas for activities to run during retrospectives? What books would you recommend to them? Aino Corry Well, the interesting thing about retrospectives is that there's a lot of different books that apply. Like when we talked about teaching computer science, it's not just computer science. It's also psychology, ethnography, neurology, things like that. And when you want to become a good retrospective facilitator, you also have to look at other things. You have to look at books about body language. A book that I keep returning to is the book Coaching Agile Teams (by) Lyssa Adkins. It's not necessarily about retrospectives, there is a little bit about that in there, but Coaching Agile Teams is about all the different ways of thinking about helping people coming from this place to this place. And that's actually what retrospectives is about. But also Jutta Eckstein has written the book Retrospectives for Organizational Change. And I think that's important as well to think about retrospectives in a different setting because then you might see that okay, so these retrospectives that you have been asked to do every sprint for a team, maybe that's actually something you can use for the whole organization to help a change or something like that. So I think sort of not just talking about the retrospective books, but other books in general about coaching or communication are very important. Ula Ojiaku: Fantastic. So are you on social media? And how can the audience who would want to get in touch with you do so? Aino Corry: Yeah, I'm on LinkedIn. LinkedIn, I think Aino Corry, just that link, and I'm on Twitter with my name, @apaipi. I'm also on Instagram, but I never use it. So that's the best place to reach me. And it's really easy to Google me because as with you, we probably have very unique names. Ula Ojiaku: Yes, yes, definitely. Aino Corry: And I have to say, Ula, thank you for that thing from the coaching that you said about pointing out the different parts of the landscape in the journey that people might not have noticed. I think that's a very, very good analogy that I'll use in my retrospective teaching as well. Ula Ojiaku: You're very welcome for that. Thank you for that. Thank you. You're welcome. Any final words before we just wrap this whole thing up? Aino Corry: Yeah, make sure you have something that you enjoy every day in your life. Ula Ojiaku: Amazing. Thanks again Aino.

This episode covers the vendor lock-in anti-pattern.  It is another one that we have seen before.  However, it is slightly different when you apply it to software architecture.  This situation is fascinating as we can fall into it thinking we are making the best decisions.  However, comfort and ease are not always the best way to assess our solution.   Vendor Lock-in Defined This anti-pattern occurs when we craft an architecture that hinges on a vendor or third-party product.  Sometimes the vendor is an open-source tool or approach.  While that is far better and can save us from being locked into their solution, it is still important to recognize.  We will be better off when we are free to craft our solution to our problem than we are chained in some way to a general offering.  In short, vendor lock-in occurs when we are bound to our solution, and someone else controls its growth and support. The Anti-Pattern In Action There are many ways this can appear in your solution.  However, the symptoms tend towards heavy reliance on third-party support or releases.  When you are often referring back to a vendor to plan your approach and schedules, you are likely in the vendor lock-in situation.  There are cases where this is acceptable.  However, vendor fluctuations and business objectives can dramatically impact your solution and even cause it to fail.  No solution or organization is too big to fail.  Therefore, proceed with caution when you rely heavily on a vendor or vendors.   Avoiding The Anti-Pattern Vendors exist to assist us.  They provide products and services that increase productivity and reduce costs.  Thus, we do not need to avoid them altogether.  We need to be strategic in our use of them.  It is best to include contingency plans as well.  Lock-in can be a minor issue if we have ways to quickly move off of or away from a vendor.  Of course, having complete control of our solution, such as offered by open-source technologies is always the safest way to avoid reliance on outside parties.

This next anti-pattern is "reinvent the wheel."  It is not a rare issue in solving problems.  However, it is still worth exploring.  Knowledge is not enough to avoid it.  Otherwise, it would be less common.  Likewise, the speed of progress in technical solutions makes it a challenge to keep current and avoid this anti-pattern.   Reinvent The Wheel Defined We see this in many ways.  However, it always boils down to looking at a problem as a novel challenge, rather than something already solved.  The anti-pattern can appear from ignorance through to a false sense of accomplishment by solving any problem.  These lead us to be busy solving problems we could move past rather than productive.  It is the height of busyness over productivity. The Anti-Pattern In Action The result of this approach can be hard to see.  It is the act of taking a wrong path that is not going to be obvious unless the correct path can also be seen.  Therefore, we can merrily plow forward in a "reinvent the wheel" trap without knowing it.  That is why we need to spend time doing our due diligence and research into a solution before we implement it.  Otherwise, we will never know what we do not know.   Avoiding The Anti-Pattern The many ways this anti-pattern appears can all be addressed through research.  There are far too many sources available on the Internet for reviewing similar problems and retrospectives.  These can point to, or describe in detail, solutions your team can utilize.  Thus, a little time upfront can save a lot of time spent on implementation.

Communication and consistency are key traits of patterns.  Likewise, a lack of these creates anti-patterns like the wolf ticket.  We all know that standards are helpful and a worthy pursuit.  However, there are de facto standards that can cause us headaches.  Let's look at how a good intention can turn into an anti-pattern. A Wolf Ticket Definition A wolf ticket is not that different from smoke and mirrors.  It is a standard or other conforming to rules where there is no enforcement.  Buzz words are a common example.  We see a word or phrase thrown around because it is the hot topic of the day.  However, there is a lack of vetting or validation to ensure compliance.  While people may tend to go the same way and have the same view of the architecture (in our case), there is no way to prove that is the case. Therefore, a wolf ticket is related to a wolf in sheep's clothing.  We think we are doing the right thing and it looks good from the outside.  However, an anti-pattern lurks beneath the surface. The Anti-Pattern In Action We have seen similar issues in other anti-patterns that are driven by assumptions.  This one is no exception.  We start with a good intention of looking to standards.  There are many benefits to standards and we will not rehash them here.  However, we fail to document and define those standards.  Instead, we just sort of let them happen organically.  While there is some value in this as a starting point, the lack of a formal standard can bite us. For example, the web is based on a standard for HTML and related technologies.  Browsers have to support these in order to work properly.  However, there are extensions that grew based on needs.  These sort of fell into standards but were not defined enough.  That led to issues with browsers being inconsistent in what they supported and how.  The base standard was consumed by a wolf ticket anti-pattern and countless headaches were created.   Avoiding The Anti-Pattern Clarity and validation are the two ways to avoid this particular anti-pattern.  We need to be clear on what is and what is not a part of any standard (or architecture) we create.  Likewise, there must be a way to validate adherence to the standard.  Unit and regression testing are excellent tools for building in and confirming adherence.  However, there are many other ways including documentation and code reviews.

There are a lot of ways pair programming can go wrong. Thankfully, it's possible to pair well simply by avoiding pairing poorly and, by steering clear of some of the common mistakes that we outline in this episode, you'll automatically up your chances of success! Today, on The Rabbit Hole, Michael Nunez, Sophie Cruetz, and Dave Anderson talk pair programming antipatterns, from multiple disruptions to over-philosophizing, from keyboard hogging to decision fatigue. For some simple tips on how to make pair programming a great tool for knowledge sharing and team building rather than a chore, tune in today!

One of the funny things about anti-patterns is that they are obvious in the name alone.  We might not know what it is but everyone avoids a jumble.  There is no technical knowledge required to judge this is not a good idea for a solution architecture.  In this episode, we review the jumble anti-pattern, what it looks like, and how to avoid it. The Jumble Defined The key to the jumble anti-pattern is horizontal and vertical elements of the design.  We want to keep those separate much like in Ghostbusters, do not cross the streams.  There should be a clear usage for a component either in the horizontal or vertical sense.  That allows us to use them properly and within the proper stream or flow of data. Think of a series of plumbing pipes.  Different liquids or temperatures flow depending on the pipe.  Our horizontal and vertical pieces of the solution are similar.  There might be very different items in each.  Likewise, the connections from one to the other can quickly become confusing and turn into a jumble. The Anti-Pattern In Action Almost every solution has general components and those specific to the problem.  While we can keep all components as stand-alone to the particular solution, it is better to utilize general components as well.  We see this creep in when components have to pass around a lot of data.  A need to change the source code of a framework or library also points to a jumble.  The mixing of vertical and horizontal components often leads to "breaking" well-encapsulated code.   Avoiding The Anti-Pattern The first step in avoiding this anti-pattern is designing your solution with an eye to problem-specific components and general pieces.  Next, do not intermingle those components.  They have different inputs, outputs, and purposes.  Thus, we need to keep our design focused on the task at hand and not allow the architecture to sprawl into areas that are not needed.

Overkill is a theme among many anti-patterns.  The cover your assets approach is one of those types where it just goes too far.  There is nothing wrong with providing a solid paper trail and communication.  However, we can make documentation the point and miss the true goal of a project. Cover Your Assets Defined This anti-pattern is the same as documentation for documentation's sake.  We get lost in administrative red tape, but do not make it to analysis paralysis.  The whole project becomes thinking about the architecture and documenting it.  However, decisions do not get made.  Instead, there is a lot of discussion and options provided.  That all adds up to loose ends and is a waste of time for the readers. The Anti-Pattern In Action The funny thing about this anti-pattern is that it results in documentation that often sits on a shelf.  The readers quickly see how pointless the documents are and stop reading.  That creates a lot of busy work without productive outcomes.  It is an anti-pattern of spinning your wheels.  A lot of activity is occurring.  Yet, no progress results from it.   Avoiding The Anti-Pattern The best way to avoid this particular anti-pattern is to keep your focus.  There is a "why" for a project and for the architecture.  That includes the related documentation.  When the work is not contributing to either understanding or productivity then adjust.  That adjustment may be a change in process or halting something completely in a paradigm shift.  Of course, the best way to avoid the problems in getting away from this situation is to never get into it.  Keep things simple and direct.  That goes a long way towards following a proper and useful pattern.

Much like the make people happy obstacle, we have the Swiss Army Knife Anti-Pattern.  This mistake is another example of over-architecting a solution.  Think of it as throwing everything into a design instead of thinking through what is needed.  However, this approach is not gold-plating and bells and whistles.  Instead, it adds things "just in case" they are required. The Swiss Army Knife Anti-Pattern Defined We often have pointed out patterns that break down and simplify a problem.  The Swiss Army Knife Anti-Pattern is almost the opposite of that.  Instead of breaking a problem into smaller parts, there are fewer, more complex components.  That leads to complicated usage and often confusing results.  Even worse, this anti-pattern creates side effects and magic numbers.  Those last errors come from attempting to do too much in one place. The Anti-Pattern In Action Confusion is the word of the day with this anti-pattern.  The users do not see a simple input and output or series of those in the architecture.  Instead, there are large or monolithic components that have dizzying descriptions.  Think of a database with a single table and several conditional fields or values.  There is too much to absorb and keep track of.  Again, the exact opposite of breaking down a problem into digestible chunks.   Avoiding The Anti-Pattern Like many anti-patterns, we avoid this with intention and simplicity.  There is a balance in a good solution between doing work and staying focused.  We avoid tripping over this mistake by sticking to our focus on the problem and solution.  While it is valuable to ask "what if?" questions, that can lead to an attempt to handle too many variations.  Stick to reasonable and likely paths, and your solution will be much easier to understand and manage.

This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubAino Vonge Corry - Author of "Retrospectives Antipatterns"John Le Drew - Agile CoachDESCRIPTIONRunning retrospectives can be intimidating, especially if you're just getting started. However, their importance in shaping teams cannot be contested. To ensure that you run successful retrospectives it is essential to understand what common pitfalls or anti-patterns appear while running them. Moreover, in the second episode, based on the book "Retrospectives Antipatterns," Aino Vonge Corry and John Le Drew highlight the role of the facilitator as a team psychologist and what future retrospectives can do for you.The interview is based on Aino's book "Retrospectives Antipatterns": https://amzn.to/3naFk84Read the full transcription of the interview here:https://gotopia.tech/bookclub/episodes/how-to-avoid-failure-agile-retrospectivehttps://gotopia.tech/bookclub/episodes/retrospective-antipatterns-aino-corryRECOMMENDED BOOKSAino Vonge Corry • Retrospectives Antipatterns • https://amzn.to/3naFk84https://twitter.com/GOTOconhttps://www.linkedin.com/company/goto-https://www.facebook.com/GOTOConferencesLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket at https://gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted almost daily.https://www.youtube.com/user/GotoConferences/?sub_confirmation=1

We have marched through 31 examples during this antipattern season.  Therefore, we have enough of them to step back and look at themes, bad habits, and commonalities.  While it is helpful to know about the individual patterns, it is better to see the big picture approaches we should avoid.  Let's get to beating some dead horses. Communication Is Key We can do everything right and still end up down a dark hole if we fail to communicate.  This recommendation involves vertical communication among staff and management as well as horizontal across roles.  We also want to be sure that we have made context and our "why" clear as part of the communication.  Provide a good map and give it to the team.  If you fail to create a good map or fail to give it to the team then the destination they arrive at may be surprising. Embrace Change The modern business world moves fast and changes often.  IT is at the forefront of this controlled chaos.  Thus, you need to plan for change and be ready to adjust as often as needed.  That requires our plans to be flexible, but also our tools and processes.  The perfect tool for our current project may be practically useless for the next one.  We want to learn from our experiences without getting tied tightly to them. Smell The Roses While smelling the roses does not help our productivity, stopping and considering our path does.  We all want to get the solution out the door as fast as possible.  However, the phrase about fools rushing in is very pertinent to our work.  When we dive in without design and thinking through a solution we are far more likely to end up spinning our wheels.  There are always dead ends and rabbit trails we can wander down.  The time lost by these can be reduced with some time sent planning our approach to implementation even down to a detailed level.  Therefore, things like pseudo-coding can be very valuable.  Use this antipattern season to embrace new habits and become a better developer. If nothing else, take a look back at the anti-patterns we have covered.

Death by planning is an anti-pattern that makes us look like lemmings.  We make a plan, and then we follow it mindlessly.  This approach can work for some projects like building a house.  However, software development does not work this way.  There are always changes and unknowns that we encounter during the SDLC process.  Thus, we want to be able to adjust to those instead of staying rigidly to the initial course. Defining the Death By Planning Anti-Pattern The Sourcemaking site provides the definition we will use for this episode.  It is lengthy, but this anti-pattern calls for that. [Click Here to See The Page] "In many organizational cultures, detailed planning is an assumed activity for any project. This assumption is appropriate for manufacturing activities and many other types of projects, but not necessarily for many software projects, which contain many unknowns and chaotic activities by their very nature. Death by Planning occurs when detailed plans for software projects are taken too seriously." The primary factor in this anti-pattern is that last sentence.  We gain value from creating detailed plans.  However, they should be taken with a grain of salt.  We often run into situations that are much like a battle where all the plans are thrown out after the first shot is fired.  It is rarely that dire, but software development should no more be a slave to design than an army is to a battle plan. It Is Not Entirely Academic One of the common arguments from those that follow this anti-pattern is the design is the "right" way to proceed.  The idea is that the time put into planning needs to be respected and veering from that course will invalidate the plan.  This mindset often comes from an academic environment where the process is considered the critical thing to focus on.  Once we get into the implementation phase of the SDLC, the solution is the key thing.  The process is there to help us, not shackle us. If a Process Occurs And No One Notices... While it may be tempting to skip the design and related processes, that is not the solution to this anti-pattern.  Death by planning is not a problem because of the planning part.  It is a bad practice when you focus too much on the plan.  This is not very different from most things in life.  Things are best when done in moderation.  Too much of anything throws off the balance.  In this case, it is worse because of planning being a secondary part of the life cycle.  The goal should always be building a solution.  Every other best practice is there to help us achieve that primary goal.  Therefore, rules (and even design decisions) are made to be broken.

The fire drill anti-pattern is one that falls on project management.  While we can personally place ourselves in this sort of situation, the anti-pattern comes from planning.  To be specific, it comes from poor planning.  Think of the idea that we can cram for a test the night before and extend it to slamming home a project at the last minute. Defining the Fire Drill Anti-Pattern The definition for this anti-pattern has been selected from the anti-pattern site.  IT provides a bleak picture of the pattern that is also a common root cause. [Click Here to See The Page] "Management waits until the last possible moment to allow developers to proceed with design and implementation; then they want results almost immediately." The above definition oversimplifies the ways this anti-pattern can appear.  Yes, this can come from blocking design or implementation.  However, it can arise from systemic blockers of any kind.  Thus, specific requirements or constraints may not be resolved until the last minute, and then the deadline is unreasonable.  We may even see this occur when a demo goes "too good."  This happens when the hacked together demo we showed management is seen as almost done, which leads to unrealistic deadlines. Setting The Pace The best way to avoid this anti-pattern is to set milestones and push high-risk items to the front end of the plan.  When we take this approach, we will have tasks defined that require a "push" to hit those deadlines.  Instead of one big push, we reduce stress by setting up smaller pushes on a regular basis.  That reduces the dead periods as well as lowering the peaks.  When this is done to perfection, we get a straight and level line for the development effort. Just In Time Development The modern business world is full of just-in-time this or that.  A fire drill can be avoided by doing this with your SDLC process.  Part of the design and requirements steps should be a definition of prerequisites.  These will help you lay out deadlines for tasks in a way that helps the team avoid bottlenecks.  For example, the user experience design should be complete before the user interface is implemented.  When it is not, the implementation will stall until that design is done and communicated.  There are numerous situations like this during the creation of a solution.  However, when they are identified early on, they provide a roadmap that can help create some smooth sailing.

The throw it over the wall anti-pattern is shared across a broad range of disciplines.  However, it is particularly damaging to the software development process.  We will focus on that discipline as we dig deeper into this communication-related issue. Defining the Throw It Over The Wall Anti-Pattern The Sourcemaking site provides an excellent setup for this anti-pattern.  Thus, we will start there instead of our typical definition approach. [Click Here to See The Page] "Rarely is documentation entirely self-explanatory, yet understanding the vision and insight of the authors is an essential part of understanding the documentation. This is especially true of guideline documents, where there is an implicit assumption of independent decision making. This assumption also implies an in-depth knowledge of the authors' intent." Communication is where we see a breakdown with this anti-pattern.  While assumptions can lead us into this situation, it often is just a lack of being thorough.  Even worse, there usually is a culture that lacks respect for those on the other side of the wall.  This environment not only suffers from the anti-pattern, it is also one that kills morale and teamwork. It All Comes Back To Why There are numerous issues that arise with this pattern.  However, the most glaring (and damaging) is that it avoids communicating the "why" of a solution throughout the team.  The point where documentation is thrown over the wall is the death of the "why."  That leaves subsequent teams without the ability to do more than they are told.  They will not be able to contribute to the solution outside of being a labor pool.  In the highly competitive modern business world, any resource that is not being fully utilized can make the difference between success and failure.  Trust your teams with context and clarification.  This approach empowers them to make a difference above and beyond their work effort. A Downward Spiral While there are many other reasons to avoid this anti-pattern, productivity may be the easiest to measure.  When content is thrown over the wall, it loses context.  That means that downstream resources have to ask questions by throwing it back over the wall.  This back and forth cycle can quickly add a lot of time to the project.  That time can be the difference between "on time and on budget" or blowing past those milestones.

The "Analysis Paralysis" anti-pattern may be the most well known.  It has a few other names.  However, a search on this one will return a broad range of results.  The detrimental effects of thinking over action are not seen only in software development.  They make an appearance universally. Defining the Analysis Paralysis Anti-Pattern This time our definition is more of a description.  The linked article provides a lot of reasons to avoid this anti-pattern. [Click Here to See The Page] "Delaying action while over-analyzing information clearly doesn't help when it comes to getting things done.  In fact, a 2010 LexisNexis survey showed that, on average, employees spend more than half their workdays receiving and managing information rather than using it to do their jobs!" We have covered the value of analyzing, considering, and design throughout this season.  Thus, the idea of analyzing alone is not an anti-pattern.  There is nothing to be gained by charging into something without forethought.  Therefore, we have an example of extremes being harmful and moderation the best approach.  Too much or too little time spent analyzing your situation can be detrimental. Finding a Proper Balance I like to think of analyzing a problem as similar to a trip to a museum.  The goal of the trip is to see all of the artwork.  The best path through the museum is one that allows you to see each item once and only once.  When we are analyzing a problem, there is a similar need.  We want to address every point and facet of the problem (within reason, more on that later) without spending too much time on any given item.  When we find ourselves re-analyzing an item, then we are likely going too far. Reasonable Analysis I mentioned the idea of considering every facet of a problem within reason.  This is worth further discussion.  Every problem includes knowns.  There are facets we can accept related to a problem.  These include environmental standards, foundational knowledge, constraints, and other attributes.  There is no need to re-invent the wheel for these items.  That is another anti-pattern.  The key to determining what is reasonable brings us back to what is essential.  When we know the "why" for solving a problem, then it will allow us to ignore some items.  They are not pertinent to our "why" and not needed for a suitable solution.  This ability to ignore attributes of a solution can be crucial.  For example, speed may not be a factor or even quality.  Sometimes an answer of any kind is better than the nothing that we have.

The mushroom management anti-pattern is one that appears everywhere.  While it can be simplified to keeping employees in the dark, there is more to it.  The side effects of this anti-pattern can cause long-lasting problems and even prevent a company from success.  Let's look at it from the software development point-of-view. Defining the Mushroom Management Anti-Pattern The simple definition provided by Wikipedia gives us an excellent starting point for discussing this anti-pattern. [Click Here to See The Page] "Mushroom management is a style of management in which the personnel are not familiar with the ideas or the general state of the company, and are given work without knowing the purpose of this work, in contrast with open-book management. " I love this definition because it highlights one of our favorite topics.  This implies the value of knowing the "why" for your work, even at an enterprise level.  Confusingly, this is not a surprise to anyone.  The reason behind things like vision and mission statements is communicating a corporate "why" to employees and customers.  Why stop there?  It only makes sense to carry that sharing of why things are done down to the lowest levels.  When it is then you by definition are building the culture into everything a company does.  Need To Know If you have ever talked to people that work in highly secretive situations, then you have heard about the challenges those environments create.  This approach can even lead to the left hand, not knowing what the right is doing.  While that may be required to protect some projects, it should be avoided where possible.  There may be a sense of power in being able to keep knowledge from the staff, but that is detrimental to a team approach.  It implies that team members or staff are somehow not worthy or capable of knowing completely the problems they are solving.  I can not see how trust and loyalty will ever grow in such an environment. Trust Your Staff While there are many problems this anti-pattern creates, the most damaging is the lack of using your team.  A lack of information about a problem prevents team members from using their experience and skills to address the problem fully.  They do not have the context to bring all of their abilities to bear. For example, we can look at the idea of driving a nail into a board.  When all the worker is told is to hit the nail with a hammer, then they will hit it once and maybe without the best amount of power.  There is no context to allow them to use their nail driving skills.  Now, let them know they are to drive the nail into a board and that it is best to do so until the nail head is flush with the surface.  In this case, the worker can use previous hammering experience to take the best number of swings and proper force to complete the job.  Better yet, they will not just finish it, but do so faster and better than if you have to talk them through it blow-by-blow.

Feature creep is one of the most prevalent anti-patterns in my experience.  I personally find it a recurring challenge to avoid.  The issue is that we can always find features that are nice to have with our solution.  That makes them very attractive to tack on to our release or version.  There is also a limit to what can be called feature creep.  Let's look a little deeper into this one. Defining the Feature Creep Anti-Pattern Scope creep is incredibly common as an anti-pattern, and Wikipedia gives a helpful, concise definition. [Click Here to See The Page] "Feature creep is the excessive ongoing expansion or addition of new features in a product,[1] especially in computer software, videogames and consumer and business electronics. These extra features go beyond the basic function of the product and can result in software bloat and over-complication, rather than simple design." Notice the modifiers in the text above.  When you see words like excessive, it always begs the question of what that means.  Unfortunately, scope creep is a sort of dark art.  We want to strike a balance between adding features that are worth the cost without blowing past target dates.  This brings us back to the challenge of knowing when to declare victory.  However, with feature creep, we can get ourselves into a situation where we are forced to go forward instead of cutting scope.  Less Is More The way to beat this anti-pattern is to focus on the truism that something is better than nothing.  Thus, a product with fewer features is better than one waiting for one with more features.  There is always a minimum viable product that needs to be released.  However, the challenge arises when you add to that MVP.  The ROI for additional features can be tricky to calculate.  The complexity is that it is not an either-or situation.  It is often a now-or-later decision to be made.  That is where I find we can best argue for or against a scope change.  The decision comes down to whether we need the feature now and cannot wait until later. Unintended Consequences All scope creep is not an instance of this anti-pattern.  There are changes we can make that are done so in an intentional manner with the trade-offs duly considered.  However, any change should be drilled into to ensure the costs are appropriately measured.  There are all sorts of side effects that even small changes can trigger.  The best way to approach any change is to have a template of things that are potentially impacted by a change and use that as a checklist.  If you miss something, then add it to the list for the next time.  Here are a few to start you off. Testing Documentation Application Flow Additional/Changing Security Requirements Data models and Back-End Impact Application Performance End User Cost This is not a comprehensive list, so spend some time thinking about the impact you have seen changes make.  If you do this regularly, then you may find the feature creep anti-pattern to be one that fades into the distance.

The magic strings anti-pattern implies a much more entertaining experience than it is.  This coding style is not rare.  Thus, it is likely you have encountered it or even fallen into this trap.  As always, proven design principles and best practices help.  However, the reasons this is an anti-pattern are worth reviewing. Defining the Magic Strings Anti-Pattern The DevIQ definition for the magic strings anti-pattern provides an excellent discussion of the cons of this approach. [Click Here to See The Page] "Magic strings are string values that are specified directly within application code that have an impact on the application's behavior. Frequently, such strings will end up being duplicated within the system, and since they cannot automatically be updated using refactoring tools, they become a common source of bugs when changes are made to some strings but not others. " The first sentence gives us a brief definition, and I like how it dives right into the problems this causes.  The challenge with this anti-pattern is that it is so easy to fall into it.  There are some reasons we might think that we can get away with a magic number.  It is best to avoid these temptations.  The sanity you save may be your own. Clever Is Not A Best Practice I have had arguments over the years about magic numbers.  There are all sorts of discussions about speed, performance, clever solutions, and more.  The thing is, none of that matters.  The anti-pattern can drive you nuts and reduce quality dramatically.  Consider a situation where you have to change a magic number.  You have no way to determine how often or where it is used in the code.  That alone could lead to weeks or months of tracking down outlier bugs caused by the number change.  Even worse, the update could lead to data corruption if you miss a couple of usages in the code.  Always fall on the side of more straightforward code over saving a process cycle or two. Fixes Are Hard The example provided above is also why this is so hard to recover from.  First, you have to realize there are magic numbers in use.  Then, you have to track down where they are used.  You might even have to figure out what they mean and why they are there.  Nothing good can come from that. We have looked at a lot of anti-patterns.  However, this may be the most insidious one yet.  It is incredibly easy to fall into and almost impossible to correct.

The death march anti-pattern is one of the most painful to endure.  There is even a tendency to envy those involved in actual ones.  This situation crushes morale and feels like it will never end. Defining the Death March Anti-Pattern This anti-patten is so common we can go to Wikipedia for a good definition. [Click Here to See The Page] "In project management, a death march is a project that the participants feel is destined to fail, or that requires a stretch of unsustainable overwork. The general feel of the project reflects that of an actual death march because project members are forced to continue the project by their superiors against their better judgment." I think the key here is the word "unsustainable."  There are projects that run a long time and burn a lot of hours but are almost pleasant to work through.  The most significant difference is where one feels destined to fail.  In a good situation, it feels like the team is moving to a big victory.  Thus, a project becomes demoralizing to part of the group.  On the other hand, it is worthy of the effort to others.  This is rarely the case.  A typical death march sucks everyone into the abyss, and thus, failure seems inevitable. It Is A Project Management Problem Note that the perception of the team is the driving reason for determining the existence of this anti-pattern.  The product or solution is often unrelated to this anti-pattern.  The best project in the world can become a death march through mismanagement.  On the other hand, even horrible projects can go smoothly and keep morale high. Key Indicators It can be seen as a flippant answer.  However, the action of considering whether a project is a death march is a leading indicator that you have found one.  In this case, the time spent considering whether you are in a death march is proportional to the likelihood that you are.  Communication and clearly defined goals are also indicators.  When you see a project floundering to keep members informed or goals are regularly changed, you probably have the anti-pattern. If anything is a perfect illustration of this anti-pattern, it is a downward spiral.  This is not always the case.  However, many of these situations include some example of running in circles.  Thus, a lot of effort results in no progress.

In this episode, we cover another anti-pattern that everyone has experienced.  However, the CYA approach is not often seen as something to avoid.  There are downsides to the cover your assets approach that need to be seen for what they are so our use of it is tempered. Defining the Cover Your Assets Anti-Pattern The Antipatterns.com site has a short and sweet definition of this anti-pattern for us. [Click Here to See The Page] "Document driven software processes often employ authors who list alternatives instead of making decisions." This definition provides us something close to analysis paralysis but from a different starting point.  There are many reasons why we stumble into this anti-pattern.  It can be to provide plenty of information for a decision.  On the other hand, it can show our lack of desire in making a choice.  The anti-pattern arises when our goal is to make a decision, communicate it, and move forward.  Too much information about the decision process can be a waste of time.  Even worse, it can confuse the reader as to what decision was made. Clear and Concise When you are tasked with making a decision and communicating it, the KISS method is best.  Keep it simple.  Declare the decision, state it clearly, then add color and commentary only if necessary.  Your audience may desire more information.  However, there should be other ways to find that content.  Do not confuse the answer by providing a reason for the same.  Think of it as the reader asking the question, "What did you decide?"  Answer the question directly instead of boring or confusing them with a dissertation. A Time and A Place There are plenty of vehicles for communicating the how and why of a decision.  SDLC documents are not those vehicles.  The assumption we make in reading design and implementation documents is that the decisions were made with a proper amount of research and thought.  The reader is not going to assume you decided in a vacuum or without forethought.  Thus, there is no need to defend it in these documents.  Let them know the decision.  Then, they can focus on getting it implemented.

This anti-pattern implies a heavier hand than is common.  While the intellectual violence anti-pattern sounds shocking and over-the-top, it is common and often subtle.  We have many ways of shutting down discussion or "protecting our turf" that are easy to miss. Defining the Intellectual Violence Anti-Pattern The Sourcemaking site has a good definition and discussion about this anti-pattern.  They also focus on the primary issue with this anti-pattern. [Click Here to See The Page] "Intellectual Violence occurs when someone who understands a theory, technology, or buzzword uses this knowledge to intimidate others in a meeting situation. This may happen inadvertently due to the normal reticence of technical people to expose their ignorance." That primary issue I mentioned is that it puts a damper on a discussion.  The general results from this anti-pattern are fewer questions and review of statements in a meeting.  This has a wide range of symptoms including the classics like, "that's how we have always done it" and "everyone knows that." Question Everything The best way to avoid this anti-pattern is to create an environment (or culture) that embraces questions.  Destroy any sacred cows and have no fear of rebuilding them as needed.  We see this sort of environment in the solution to other anti-patterns as well.  The world is changing every day so it is short-sighted to think that what we know today will hold true next year (or even tomorrow).  While intellectual violence can be traced back to other reasons, (like job security and fear of having ignorance shown) a culture of feedback and discussion will overcome those as well. The Tip of The Iceberg Intellectual violence as an anti-pattern is worth digging into when it appears.  There are other issues that may be behind this approach.  They may be individual issues such as worries of job security or enterprise level problems of respect in the workplace.  All of those are valuable issues to be aware of and address.  It can make your team happier and improve morale.  When that happens you will not only stop intellectual violence now, you will likely squash it in the future as well.