Better ROI from Software Development
Providing advice on how to get the best Return On Investment from your Software Development. Hosted by Mark Taylor of Red Folder Consultancy, this series is targeted at those that fund software development in improving their return on investment. Through a series of short weekly podcasts, Mark explores and explains why "traditional" management techniques will not only produce poor returns, but actively encourage it.
Episodes
#205: Estimation - a wrap-up
This episode is a wrap-up for a mini-series looking at estimation in software development - recapping the guidelines I provided in Episode 189 and providing some additional tips that didn't have a home elsewhere in the series.
-----
Find this episodes show notes at: https://red-folder.com/podcasts/205
Have an idea for an episode topic, or want to see what is coming up: https://red-folder.com/podca
#204: Estimation - Professionalism
In this episode, the penultimate episode in the Software Estimation mini-series, I want to discuss how Software Estimation works in terms of professionalism - and in many cases, surprisingly, the professional response is not to provide an estimate.
-----
Find this episodes show notes at: https://red-folder.com/podcasts/204
Have an idea for an episode topic, or want to see what is coming up: https:
#203: Estimation - Is Artificial Intelligence the answer?
This episode is part of a wider mini-series looking at Estimation in Software Development.
In this episode, I ask the question, is AI the answer?
Following on from the episodes on Qualitative and Quantitative approaches, it's easy to see there are pros and cons to individual practices. And realistically, it feels like you will need a blend of various approaches to create truly valuable estimates.
#202: Estimation - Quantitative approaches
This episode is part of a wider mini-series looking at Estimation in Software Development.In the last couple of episodes, I've looked at a number of methods that fall under the Qualitative approach to software estimation.Qualitative estimation is predominantly based on expert judgment, some think based on subjective thought process.In this week's episode, I want to move on to discuss some Quantita
#201: Estimation - the #NoEstimate approach
This episode is part of a wider mini-series looking at Estimation in Software Development.
In last week's episode, I looked at a number of methods that fall under the Qualitative approach to software estimation.
Qualitative estimation is predominantly based on expert judgment, something based on subjective thought process.
In this episode I wanted to take a specific look at another method I perso
#200: Estimation - Qualitative Approaches
This episode is part of a wider mini-series looking at Estimation in Software Development.
In last week's episode, I introduced two approaches to software estimation, Qualitative and Quantitative estimation.
Qualitative estimation is predominantly based on expert judgment, something based on subjective thought process.
Whereas Quantitative is based on something we count or calculate. A use of stat
#199: Estimation - Quantitative vs Qualitative
This episode is part of a wider mini-series looking at Estimation in Software Development.
In this episode, I wanted to look at practical methods to help develop the team's estimation skills.
We cannot expect valuable estimation without investment. It's like any skill, it has to be practiced and refined to obtain a good level of proficiency.
So in this episode, I want to take a look at two approac
#198: Estimation vs the punitive target
This episode is part of a wider mini-series looking at Estimation in Software Development.
In this episode, I wanted to highlight the emotional baggage that you developers may associate with estimation, and through no fault of your own, will carry that baggage into future estimation work.
In the episode, I look at the psychological scarring left behind from decades of using estimates as punitive t
#197: Estimation vs Dependencies
This episode is part of a wider mini-series looking at Estimation in Software Development.
In this episode, I wanted to look at the impact that dependencies have on software estimation.
This episode was inspired by a blog post on scrum.org entitled "Eliminate Dependencies, Don't Manage Them", which I read while preparing this series.
In brief, the article talks about how you're better off eliminat
#196: Estimation vs Planning
This episode is part of a wider mini-series looking at Estimation in Software Development.
In this episode, I want to encourage you to mentally separate estimation and planning.
They are often conflated, which leads to confusion, distrust and dysfunctional behavior.
An estimate is generally part of a plan, and a plan can be the outcome of the act of planning.
Software development can't be delive
#195: Estimation - An estimate by any other name
This episode is part of a wider mini-series looking at Estimation in Software Development.
In last week's episode, I asked you to think about what the term "estimate" means to you, your team and your organisation.
In the episode I talked about different definitions that could easily be conflated - the amount of effort, a target, and a commitment.
In this week's episode I want to continue the discu
#194: Estimation - What are you actually asking for?
This episode is part of a wider mini-series looking at Estimation in Software Development.
In this week's episode, I want to discuss what the term "estimate" may mean to you and the colleagues that you work with.
The term 'estimate' is often used interchangeably to mean the effort required, the target completion date, or even a commitment to complete the work by a specific date.
Often the meaning
#193: Estimation - How much to invest
This episode is part of a wider mini-series looking at Estimation in Software Development.
In this episode I want to take a deeper dive into the cost of achieving that - what is the correct cost for the perceived value of the estimate to you and your organisation.
This episode continue on from 190 where I asked "Don't invest in estimates unless there are clear demonstrable value in having them"
--
#192: Estimation - Predictability vs Optimism
This episode is part of a wider mini-series looking at Estimation in Software Development.
In the last episode, I talk about the short hand of a "valuable estimate" - an estimate that is desirable for the organisation asking for it.
While what constitutes "valuable" will differ from organisations to organisation, team to team, and maybe even piece of work to piece of work, I feel that it will mos
#191: Estimation - what is a valuable estimate?
This episode is part of a wider mini-series looking at Estimation in Software Development.
So for this episode I want to introduce the idea of a "valuable estimate" and what that may mean for you.
As I go through this series I will use the term "valuable estimate" as a short hand for some value that is desirable by the organisation asking for it.
This may seem a little vague … and to be honest, by
#190: Estimation - Do you get value?
I started the mini-series in episode 189 by providing the following guidelines:
Don't invest in estimates unless there are clear demonstrable value in having them
Agree what a "valuable" estimate looks like - this will likely be a desirable level of accuracy and precision for an estimate
Provide the team with training & time to develop their estimation skills
Collect data on points 1-3 a
#189: Estimation - a review
Back in January 2023, in episode #160, "Revisiting
Software Development Estimation," I made the commitment to revisit and potentially revise my views on software development estimation.
While I acknowledged the desirability of estimations for reasons like cost, risk, and planning, the episode recognized that these desires don't always make estimations attainable or accurate, particularly in comp
#188: Bad for ROI - More Developers
Following on from the last two episodes that look at the dysfunctional and unexpected results that can from the seemly well intentioned call for "more planning", this week's episode takes a look at a similar paradox - the call for "more developers".
We look at why "more developers" does not generally equal "greater output" - the unexpected operational ov
#187: Bad for ROI - More Planning - Part 2
In this episode, the second of two, I conclude the exploration of the dysfunctions and unexpected results that can occur from the seeming well intentioned call for "more planning".
In last week's episode, I looking at the historical context of why the request for "more planning", and explored the high cost and dysfunctions that can arise from over-planning.
And this week
#186: Bad for ROI - More Planning - Part 1
In this episode, the first of two, I start to explore the dysfunctions and unexpected results that can occur from the seeming well intentioned call for "more planning".
In this episode, I will start by looking at the historical context of why the request for "more planning", and an exploration of the high cost and dysfunctions that can arise from over-planning.
And in next week
#185: Bad for ROI - Overemphasis on Perfection
In the last episode I the dysfunctions and unexpected results of a "feature factory" within Software Development.
This week I look at what happens if the pendulum swings too far the other way - where an overemphasis on perfection leads again to dysfunction and unexpected results.
-----
Find this episodes show notes at: https://red-folder.com/podcasts/185
Have an idea for an episode topic
#184: Bad for ROI - the Feature Factory
In the fast-paced world of software development, the “feature factory” model, with its promise of rapid growth and high ROI, can easily captivate businesses.
This episode takes a dive into why the the feature factory is so alluring - and why beneath the allure, lies a multitude of hidden dysfunctions and potential for long-term damage.
-----
Find this episodes show notes at: https://red-folder.co
#183: Bad for ROI - Performance measurements in software development
In this episode I look at another practice that can be bad for ROI - a practice that may commonly be considered good or common practice, but is actually causing dysfunctional, and unexpected, results.
In this episode I want to explore the dangers of performance measurements in modern software development - how, while they are a useful and powerful tool, they are so commonly used incorrectly to dis
#182: Bad for ROI - Bonuses
We all know that a heft bonus improves productivity. Its a management stable - dangle the carrot and good results just roll it.
But is that really true?
In this episode, I look at the negative consequences of using bonuses for motivation - once again, leaning heavily on the work of Daniel Pink and his book "Drive" to explore the idea of extrinsic and intrinsic motivators - and what works
#181: Bad for ROI - RAG reporting
Occasionally I record an episode exploring something that may commonly be considered good, or common practice, but is actually causing dysfunctional, and unexpected, results in modern software development - and thus would be bad for ROI.
This week I look at the RAG (Red Amber Green) status reporting and its impact on modern software development.
-----
Find this episodes show notes at: https://red-
#180: Bad for ROI - the HiPPO
Occasionally I record an episode exploring something that may commonly be considered good, or common practice, but is actually causing dysfunctional, and unexpected, results in modern software development - and thus would be bad for ROI.
This week I want to introduce you to a strange beast, found way too often in our organisations, the HiPPO. While the term might sound comical, its implications in
#179: Does the manager still have a role to play in the modern software development team?
In this episode I wanted to explore what it means to be a manager for a development team - and more importantly in the world of diverse, cross-functional, self-managing, value stream teams, does the manager still have a role to play?
Picture this: You've successfully built a software development team that's as diverse as it is dynamic. They are cross-functional, self-managing, and entirely
#178: Transaction-based costing - a wrap-up
In this episode I wrap up this series of episodes on transaction-based costing by looking at the common themes and revisiting some of my initial reasons for starting the series.
For me the key takeaway is the common theme of constantly rethinking our best practice and adapting to the changing landscape of technology, our organisation, and our markets.
-----
Find this episodes show notes at: http
#177: Transaction-based costing and Small Batch Sizes
In this episode I continue the discussion on transaction-based costing by looking at the relationship with Small Batch Sizes.
I began by defining small batch sizes - the breaking of work down into more manageable tasks, which can improve the speed and quality of your output.
I then explore how small batch sizes play a pivotal role in transaction-based costing, promoting efficiency and cost-effec
#176: Transaction-based costing and Value Stream Teams
In this episode I continue the discussion on transaction-based costing by looking at the relationship with Value Stream Teams.
I start by defining value stream teams - cross-functional groups that work towards delivering value from customer request to service delivery. I explore how they fit into the software development landscape, leveraging principles of lean manufacturing for better efficiency
#175: Transaction-based costing and its relationship with serverless and cloud
In episode, I discuss the relationship between transaction-based costing models, serverless computing, and cloud computing in a dynamic business environment.
I look at how this model offers flexibility, scalability, and cost-effectiveness by allowing businesses to pay only for the resources they use - and compare this model to the traditional capex/opex model and highlight how the transaction-bas
#174: Transaction-based costing in Software Development
Are you struggling to track the true return on investment in your software development projects?
Traditional CapEx and OpEx models may not be enough in dynamic environments. But don't worry, there's a solution!
In this episode, I introduce transaction-based costing.
By assigning a cost to each transaction within the software development process, you can achieve better transparency, tighte
#173: AI Coding Assistants - the future
In this episode, I discusses the potential benefits of organization-specific AI Coding Assistants.
While AI won't replace developers, it can provide more refined and less generic answers, leading to improved code quality and enhanced productivity within the organization. By tailoring AI Coding Assistants to an organization, it can understand and adapt to project-specific requirements, suggest
#172: AI Coding Assistants - the potential negatives
In this episode I discuss the potential negatives of using AI Coding Assistants in software development.
I cover topics such as:
over-reliance and skill degradation,
lack of creativity and innovation,
false positives and incorrect suggestions,
limitations with domain-specific knowledge,
dependency on internet connectivity,
adoption and learning curve,
and privacy and security co
#171: AI Coding Assistants - the benefits
In this episode, I discusses the expected benefits of using AI Coding Assistants in software development.
These benefits include:
increased productivity,
code optimization,
learning and knowledge enhancement,
error detection and debugging,
collaboration and coding consistency,
code documentation,
and code completion and suggestions.
-----
Find this episodes show notes at: https
#170: AI Coding Assistants - an introduction
In this episode I discuss the growing use of AI Coding Assistants in software development, particularly large language models like ChatGPT.
I explain how AI Coding Assistants can greatly improve productivity and efficiency for developers, with examples of popular products in the market.
AI Coding Assistants will not replace developers, but rather enhance their work.
-----
Find this episodes show
#169: ChatGPT - initial conversation thoughts
In this episode, I review last weeks conversation with ChatGPT, an artificial intelligence language model developed by OpenAI. I discuss the technology behind ChatGPT, its potential risks and benefits, and the ethical and societal questions it poses. I also talks about my personal experience with ChatGPT and my intention to use it for podcast scripting.
-----
Find this episodes show notes at: http
#168: ChatGPT - my first conversation
In this episode, I aim to explain what ChatGPT is and its future for a non-technical managerial audience - and I do this through conversing with ChatGPT.
I share this first chat I've had with ChatGPT - with a followup planned for next week to talk through my experience and initial thoughts.
-----
Find this episodes show notes at: https://red-folder.com/podcasts/168
Have an idea for an episode
#167: Password Hygiene
In this episode, I discusses the LastPass breach that occurred last year and how it has prompted me to improve my password hygiene.
I talk about why the breach has led me to move away from LastPass - and how it has provided an opportunity to clean up my password data and reset passwords for critical accounts.
I also re-emphasizes the importance of good password hygiene and using multi-factor auth
#166: The value of certifications
In this episode, I discuss my personal experience with Microsoft Certifications and their value in the IT industry.
I believe that certifications provide a wider breadth of knowledge that may not be obtained through day-to-day work - but is still no subsitute for experience when it comes to recruitment.
-----
Find this episodes show notes at: https://red-folder.com/podcasts/166
Have an idea for a
#165: Introduction to the Actor Model
In this episode, I introduce the Actor Model as a Design Pattern that can offer faster and more efficient processing by managing state in memory.
I discuss potential use cases for the Actor Model, such as in online gaming and IoT sensors, but acknowledge that it is a different development model than traditional approaches.
-----
Find this episodes show notes at: https://red-folder.com/podcasts/1
#164: Design Patterns
In this podcast episode, I introduce the concept of design patterns in software development and explain their importance in improving code quality and readability.
I give examples of design patterns in everyday life and emphasize how they can speed up the development process by providing tested and proven development paradigms.
I also highlight the confusion that can arise when design patterns ar
#163: Taking time for self care
This is the first episode after a prolonged break - so firstly, an apology for the gap in recordings.
In this episode I wanted to talk about why I took a break, the lessons to learn and what I've been up to over the past few months.
-----
Find this episodes show notes at: https://red-folder.com/podcasts/163
Have an idea for an episode topic, or want to see what is coming up: https://red-folder
#162: Recommendations in a downturn
As we start the new year, its not uncommon for organisations to looks at budgets and general expenditure - and given the current financial outlook, I would have expected many organisations to be taking the time to look at how best to weather the storm.
I've found that many organisations typically react with a combination of cost cutting and putting pressure on staff for "more" in such periods.
How
#161: State of DevOps 2022
This episode, I wanted to take a quick look at the 2022 edition of the State of DevOps Report.
I've talked a number of times about the State of DevOps report. I originally introduced it back in episode 13, and last year I devoted seven episodes, 120-126, to a deep-dive into the 2021 edition.
-----
Find this episodes show notes at: https://red-folder.com/podcasts/161
Have an idea for an episode top
#160: Revisiting Software Development Estimation
I've long held the belief that Estimation is the source of much dysfunction within Software Development.
However, with a New Year, I'll like to take this as an opportunity to revisit my strong opinions on the subject - are they still valid? Are there better ways?
In this episode I recap the understandable desire for Software Development Estimations, why I feel that its a source of so much dysfunct
#159: Gantt Charts revisited
I originally discussed Gantt charts back in episode 62, but I found more history behind them while researching Scientific Management and Taylorism for episode 156. I originally thought to include this additional history in that episode, but it felt out of place - thus this separate episode to revisit Gantt charts.
-----
Find this episodes show notes at: https://red-folder.com/podcasts/159
Have an
#158: The Pitch - one-size does not fill all
In episode 150, I reintroduced this series with a new pitch. It was my way of taking what I've learnt over the last three years, the last 150 episodes, and almost 33 hours of content and updating the why of the podcast. Over recent episodes, I've take a deeper dive into the themes of the pitch and why they made the cut.
And in this weeks episode, I want to explore the idea that there is no a
#157: The Pitch - its not like flipping hamburgers
In episode 150, I reintroduced this series with a new pitch. It was my way of taking what I've learnt over the last three years, the last 150 episodes, and almost 33 hours of content and updating the why of the podcast. Over the coming episodes, I'll take a deeper dive into the themes of the pitch and why they made the cut.
In this episode, I look at why Software Development cannot be determ
#156: The Pitch - the management practices of yesterday
In episode 150, I reintroduced this series with a new pitch. It was my way of taking what I've learnt over the last three years, the last 150 episodes, and almost 33 hours of content and updating the why of the podcast. Over the coming episodes, I'll take a deeper dive into the themes of the pitch and why they made the cut.
In this episode, I want to take a deeper dive into the management pr
#155: The Pitch - the age and maturity of software development
In episode 150, I reintroduced this series with a new pitch. It was my way of taking what I've learnt over the last three years, the last 150 episodes, and almost 33 hours of content and updating the why the podcast. Over the coming episodes, I'll take a deeper dive into the themes of the pitch and why they made the cut.
Over the last few episodes, I've looked at the business side of the pit
#154: The Pitch - doing change
In episode 150, I reintroduced this series with a new pitch. It was my way of taking what I've learnt over the last three years, the last 150 episodes, and almost 33 hours of content and updating the why the podcast. Over the coming episodes, I'll take a deeper dive into the themes of the pitch and why they made the cut.
In this episode, I follow on from last weeks introduction of chan
#153: The Pitch - the Age of Software and Digital
In episode 150, I reintroduced this series with a new pitch. It was my way of taking what I've learnt over the last three years, the last 150 episodes, and almost 33 hours of content and updating the why the podcast. Over the coming episodes, I'll take a deeper dive into the themes of the pitch and why they made the cut.
In this episode, I wanted to talk about why I led with "Welcome to the
#152: The Pitch - lets talk business
In episode 150, I reintroduced this series with a new pitch. It was my way of taking what I've learnt over the last three years, the last 150 episodes, and almost 33 hours of content and updating the why the podcast. Over the coming episodes, I'll take a deeper dive into the themes of the pitch and why they made the cut.
If you listen back to the pitch, you will notice that it is almost half
#151: Mini-budget implications on contractor and permanent markets
On the 23rd September, the UK Chancellor announces a series of change during a "mini-budget".
The mini-budget, and its contents, have been the subject of much debate ever since.
What might have been missed by many people where the changes to the IR35 off-payroll rules - which, as I discuss in this episode, could have material impact on both the contractor AND permanent recruitment markets
Note: Si
#150: An updated pitch for the podcast
Welcome to the 150th episode of the podcast.
In this episode, I take a moment of introspection to revisit the "pitch" for this series.
-----
Find this episodes show notes at: https://red-folder.com/podcasts/150
Have an idea for an episode topic, or want to see what is coming up: https://red-folder.com/podcasts/roadmap
#149: Legacy Data - advice for dealing with it
Over the last few episodes, I've focused on legacy software - what it is, how it occurs, and various strategies to deal with it.
Alongside that legacy software is the legacy data - which is arguably more important than the data.
In last week's episode, I talked about why thinking about that legacy data is so important.
In this week's, I will provide advice for dealing with it.
-----
Find this epis
#148: Legacy Data - why you should be thinking about it
Over the last few episodes, I've focused on legacy software - what it is, how it occurs, and various strategies to deal with it.
Alongside that legacy software is the legacy data - which is arguably more important than the data.
In this episode, I want to talk about why thinking about that legacy data is so important
-----
Find this episodes show notes at: https://red-folder.com/podcasts/148
Have
#147: Legacy Software - addressing with Outsourcing
This is part of a new mini-series looking at Legacy software - the term "legacy" is often seen as a positive - yet within computing it is a negative term generally uses to indicate the need to replace hardware or software.
A few weeks ago, I introduced three methods to address legacy software:
Evolution - continual improvement to the existing system to bring it out of its "legacy" state
Revolut
#146: Legacy Software - addressing with Revolution
This is part of a new mini-series looking at Legacy software - the term "legacy" is often seen as a positive - yet within computing it is a negative term generally uses to indicate the need to replace hardware or software.
Two weeks ago, I introduced three methods to address legacy software:
Evolution - continual improvement to the existing system to bring it out of its "legacy" stat
#145: Legacy Software - addressing with Evolution
This is part of a new mini-series looking at Legacy software - the term "legacy" is often seen as a positive - yet within computing it is a negative term generally uses to indicate the need to replace hardware or software.
In last week's episode, I introduced three methods to address legacy software:
Evolution - continual improvement to the existing system to bring it out of its "legacy" state
#144: Legacy Software - how to address
This is part of a new mini-series looking at Legacy software - the term "legacy" is often seen as a positive - yet within computing it is a negative term generally uses to indicate the need to replace hardware or software.
In this episode, I'll introduce three methods to address legacy software:
Evolution - continual improvement to the existing system to bring it out of its "legacy" state
Revol
#143: Legacy Software - a risk matrix
This is part of a new mini-series looking at Legacy software - the term "legacy" is often seen a positive - yet within computing it is a negative term generally uses to indicate the need to replace hardware or software.
In this episode, I'll describe a simply risk matrix that can be used to monitor and highlight how legacy your software products are.
-----
Find this episodes show notes at: https:/
#142: Legacy Software - the causes
This is part of a new mini-series looking at Legacy software - the term "legacy" is often seen a positive - yet within computing it is a negative term generally uses to indicate the need to replace hardware or software.
In this episode, I'll talk about some of the causes behind how our software can become "legacy".
-----
Find this episodes show notes at: https://red-folder.com/podcasts/142
Have an
#141: Legacy Software - the impact
This is part of a new mini-series looking at Legacy software - the term "legacy" is often seen a positive - yet within computing it is a negative term generally uses to indicate the need to replace hardware or software.
In this episode, I'll talk about the impact of Legacy software and why the software industry invests so much effort into addressing.
-----
Find this episodes show notes at: https:/
#140: Legacy Software - an introduction
This is the start of a new mini-series looking at Legacy software.
The term "legacy" is often seen as positive - yet within computing it is a negative term generally uses to indicate the need to replace hardware or software.
In this episode, I'll give you an introduction to Legacy software.
-----
Find this episodes show notes at: https://red-folder.com/podcasts/140
Have an idea for an episode topi
#139: Automation - the higher value work side-effect
I've talked many times about the productivity benefits from automation.
In this episode, I talk about the higher value benefits we get from automation - something you could describe as a side-effect.
Automation gives us productivity - but not just to do more, but to do better. Automation gives us the opportunity to elevate the work carried out by our teams - ultimately leading to better, che
#138: Automation - the knowledge sharing side-effect
I've talked many times about the productivity benefits from automation.
In this episode, I talk about the knowledge sharing benefits we get from automation - something you could describe as a side-effect.
I discuss how, to be effective, any new software developer needs to learn not just the technical tools and practices, but also the domain - the environment in which the software will operate.
I t
#137: Automation - the auditability side-effect
I've talked many times about the productivity benefits from automation.
In this episode, I talk about the auditability benefits we get from automation - something you could describe as a side-effect.
I discuss:
Why having audit data is helpful to our organisations
How automation can help to provide that audit data
How automation can remove a whole class of questions over manual access to produ
#136: Automation - the security side-effect
I've talked many times about the productivity benefits from automation.
In this episode, I talk about the security benefits we get from automation - something you could describe as a side-effect.
I discuss:
Reduced access
Reduced manual interpretation
Logs
Controllable environments
Automated security tools
Signed software
-----
Find this episodes show notes at: https://red-folder.com/pod
#135: Infrastructure-as-Code
In this episode I introduce Infrastructure-as-Code - a way of defining your Operation's infrastructure as code - an example of DevOps in practice with our Ops teams learning from our Dev teams.
Why you may be interested in this episode:
For an explanation of Infrastructure-as-Code
The advantages of using it
And some of the common excuses for not using it - and how to address them
-----
Find t
#134: DevOps Topologies - Working types
In this episode I want to continue the talk about the team structures discussed on https://web.devopstopologies.com/ - with a focus this week on the topologies are shown to work.
The devopstopologies.com website is based on the work by Matthew Skelton & Manuel Pais. I introduced Matthew and Manual as authors of the Team Topologies book in the last episode. The work is a pre-cursor to the
#133: DevOps Topologies - Anti-Types
In this episode I want to talk about the team structures discussed on https://web.devopstopologies.com/ - with a focus this week on the anti-types.
The devopstopologies.com website is based on the work by Matthew Skelton & Manuel Pais. I introduced Matthew and Manual as authors of the Team Topologies book in the last episode. The work is a pre-cursor to the Team Topologies book - and wor
#132: Inverse Conway Maneuver
In the last episode, I introduced "Conway's Law" - an observation of how our organisational structures influence our software structures.
In this episode, I want to talk about how we can utilise this law when we want to improve problems in our software structures - commonly referred to as the "Inverse Conway Maneuver".
Why you might be interested in this episode:
A recap of Conway's Law and the
#131: Conway's Law
In this episode, I introduce Conway's Law, which talks about how our software structures will reflect the structures of the organisations that create them.
Why you might be Interested in this episode:
Why our organisational structures affect software structure
The history of "Conway's Law"
The negatives that the Law can help us highlight
And why the adoption of Microservices and small Cross F
#130: To Checklist or not to Checklist
This episode, I want to take a look at Checklists - when to use and when not to.
Much of this episode is inspired by the Sight Reliability Engineering practices that come out of Google.
Why you might be interested in this episode
The value of a checklist
Situations where it is appropriate
And situations where it isn't
CORRECTION: During the episode I refer to "The Manifest Checklist" - this s
#129: Handling Failure
Failure in our software systems is inevitable - be it a failing hard drive, broken network cable, power outage, virus, or simply a bug in the code.
"Hope is not a strategy" - thus we need to think about how we handle that failure.
Why you might be interesting in this episode:
The differences between how failures impact our traditional monolith applications and the more modern distributed applica
#128: Error Budgets
In this episode, I take a look at "Error Budgets"
Much of this episode is inspired by the Sight Reliability Engineering practices that come out of Google
Why you might be interested in this episode:
You want to understand what "Error Budgets" means?
You're struggling to prioritise effectively between feature development, defects, risk and debt
You want to see how "Error Budgets" can help you w
#127: System Availability - Service Level Indicators, Objectives and Agreements
In this episode, I take a look at how to measure the availability of our systems.
Much of this episode is inspired by the Sight Reliability Engineering practices that come out of Google
Why you might be interested in this episode
How Google uses Service Level Indicators, Objectives and Agreements
Why 100% uptime might not be the correct target
And why "uptime" might not be the best indicator i
#126: State of DevOps 2021 - What it says about Site Reliability Engineering
The State of DevOps report provides excellent insight through rigorous analysis of its wide reaching survey.
The research provides evidence-based guidance to help focus on the capabilities that drive performance.
One of those are Site Reliability Engineering practices that came out Google's efforts to handle massive scale.
Why you might be interesting in this episode:
What is Site Reliability En
Recommended
Out To Lunch
Desert Island Discs
Making of a Fugitive
The Day After TNB
Tom Talks Junior Cricket Coaching Podcast
SONIC TALK - Inside Music Technology
Brief Account of the Bahai Movement
The Gargle
Canny Crystals: Manifestation, mindset and spirituality, with Mart Tweedy
The Clifford Chance Podcast
Legal updates | Simmons & Simmons
Securitisation Insights
