This course is designed for you if you are a manager in a software company or if you’re involved in managing software development teams.
If you want to know what is slowing down your team’s performance and making everyone’s job harder, so that you can take steps to address the issues that will make the most difference to the effectiveness of your team.
You do not need to be a software developer to get the value from this course!
Why should you care about Technical Debt?
Technical Debt costs the industry trillions every year and yet it frequently goes unnoticed, neither measured or managed.
In 2018 the cost of poor quality software in the US was estimated by the Consortium for IT Software Quality at $2.84 Trillion. Within the same report they identified that most IT leaders lack a basis for estimating the answers to how their software practices related to quality affect the overall cost of ownership of software.
Technical Debt is an escalating problem that affects all software products to some extent. If left unmanaged it increases year on year and is a major cause of frustration not just for the Developers who have to navigate it every day, but also everyone else in the software company.
Who this course is designed for
This course is designed for you if you work in a software organization in a management role, or if you are involved with managing the software practices of your development teams.
Are you the kind of software development leader who wants to create a more productive environment for your team, where people come to work enthusiastic and excited to work on your products? Then please check the course contents out.
Do you want to head up one of the elite minority of software development teams who are aware and actively managing this problem? If you are, I’d love to see you in class.
What we’ll cover
In this course, we look under the hood at the software practices which lead to technical debt, and take the first step in addressing this ubiquitous software development problem
We’re going to take a look at some of the common symptoms and categories of technical debt that affect real world software products.
We’ll look at common types of technical debt, and real world case studies to bring them to life.
Knowing that there is a problem with technical debt in your software practices is the first step to solving it, and knowing where to look for the problem is the second step.
What you will get when you purchase this course
You will also get a certificate of completion to download and keep at the end of the course.
30 Day Money Back Guarantee
Finally, I have built this course to share the insights I gained from my industry experience over the past 30 years because I want to help more software teams become amazing places to work. However I don’t want to take your money unless you are satisfied with your course and get value from it.
You can watch the course promo video, and also I have unlocked a couple of the course videos, so that you can try for free before you buy.
In addition, Udemy offers a 30 day money back guarantee if you are not happy with a course, so you can take this course completely risk free. Please check out the Udemy refund policy for the full details.
You get a course of 10 video lessons on Udemy that takes you from zero to Technical Debt Detective, containing 55 minutes of videos, with downloadable transcripts, real world case studies and activities to enable you to make a difference in your own company.
The underlying cause is probably to do with technical debt, and recognising the root cause problem is the first step to solving it. This course will arm you with the information you need to recognise technical debt in your software development organisation, and know where to start looking for it.
Armed with this knowledge you will be in a strong position to negotiate for the resource you need to deal with it.
This lesson introduces the course with the question ‘What Is Technical Debt?’.
On completing this lecture you will know some of the common problems that are caused by technical debt in real world software companies, and which types of companies are affected.
After completing this lecture you will be able to explain what the term technical debt means in the software industry.
You will have a useful and practical definition of technical debt that covers all the types of technical debt you need to be aware of as a manager in a software company.
You will know where the term Technical Debt came from, what it means, and how it applies to the software industry today.
Sometimes the easiest way to illustrate an idea is by example. In this lecture you will see a real world example of an e-commerce company struggling with technical debt, and find out how much an early design flaw in the software ended up costing them 10 years later.
After completing this lesson you will feel more confident discussing the impact of technical debt with your development team.
In this module we look at the visible symptoms in your company that indicate the presence of technical debt in your software.
After completing this lecture you will be able to recognise the symptoms of technical debt in your own organisation and identify whether Technical Debt has become a problem that is affecting your ability to meet your customers needs or hampering your growth in the market.
In this case study we look at a real world example of a large software as a service company who are struggling with a lot of symptoms of technical debt.
You will start to be able to differentiate between a desire to use new technologies for their own sake, and updating parts of the software that are really costing you more than they should be
In this lesson we are going to look at the different places technical debt can be hiding in an organisation and where to start looking for it in your software company.
After completing this lesson you will know where to begin to look for technical debt in a software company.
In this lesson we take a closer look at technical debt within software code and some of the reasons it arises.
In this lesson we take a closer look at how the overall software architecture can result in technical debt.
In this lesson we take a closer look at how the overall software architecture can result in technical debt.
In this lesson we will take a look at some non-technical causes of technical debt!
This is the final module of the course, where we pull together everything that we’ve been talking about.
After completing this course You will feel confident discussing the impact of technical debt with your development team, and your colleagues and you will be capable of differentiating between a desire to use new technologies for their own sake, and updating parts of the software that are really costing you more than they should be.
I’m the CEO and Founder of Chaos On Toast, a software consultancy dedicated to helping software companies with their legacy code and technical debt.
I’ve worked in the software industry for 30 years now, and seen it all. I have managed development projects and worked with many development teams in all these scenarios.
I know how it feels to be under pressure to deliver, staying up all night to ensure a software release goes well for customers and playing whack-a-mole with bugs following a rushed release, I understand why it happens, I’ve been there. Balancing the business priorities between ensuring future development won’t be compromised and getting the next release out now is a problem common to all software companies.
Armed with this knowledge you will be able to assess where your company is on the timeline, and make informed decisions on when and how much of development resource you need to allocate to paying down your technical debt to avoid more serious problems down the line.
Once you start to see the invisible mountain of technical debt your team are climbing, you will be better able to negotiate for the resources you need to scale the mountain and start paying off your technical debt instead of racking up more and more interest without knowing where it is coming from.