Better ROI from Software Development

Welcome to the 25th episode.

I decide I wanted to use this episode as both a recap to the series so far and as a good entry point for new listeners.

During this episode, I'll be summarising the key takeaways so far - and which episodes to listen to if you want more.

In last week's episode I introduced the idea of Pair Programming.

A software development practice that has two developers working on the same thing on the same computer. One acting as the driver - the other as a navigator - with regular role reversal.

I talked about, while there is an increase to the developer-hours spent on a problem, the benefits of faster delivery, better quality, knowledge sharing and better team communications soon outweighs the cost.

In this episode, I want to talk about a similar software development practice - but much more amped up - mob programming.

In this weeks episode, I want to introduce the practise of Pair Programming.

At first, Pair Programming can seem completely at odds with achieving returns from your software development investment.

Though this episode, I will look at the common misconceptions and why this is a valuable practice for ROI.

In the last few episodes I've started a mini-series introducing some of the tools and practices that allow for the fast delivery of software and ultimately delivery of value to our customer.

In episode 18, I introduced Source Control, what it was, why your developers will be using it and the value it brings.

Following your development team saved their software code to the Source Control, I then introduced Continuous Integration in episode 19. I described how Continuous Integration allows us to find problems faster - allowing us to address them much more cost effectively and making Software Development much more productive.

In episode 20, I introduced Continuous Delivery. It builds on Continuous Integration and make the releasing of our of software as easy as a button press. Through automation we make our release process a repeatable, reliable, easy, non-event.

And then in the last episode I introduced Continuous Deployment which builds upon Continuous Delivery by removing the manual button press - automating the entire process from developer to customer many times a day.

In this, the final episode of this mini-series, I want to talk about how to handle incomplete work.

In the last few episodes I've started a mini-series introducing some of the tools and practices that allow for the fast delivery of software ... and ultimately delivery of value to our customer.

In episode 18, I introduced Source Control, what it was, why your developers will be using it and the value it brings.

Once your development team has saved their software code to the Source Control, I then introduced Continuous Integration in episode 19. I described how Continuous Integration allowed us to find problems faster - allowing us to address them much more cost effectively and making Software Development much more productive.

Then, in the last episode, I introduced Continuous Delivery. It builds on Continuous Integration and make the releasing of our of software as easy as a button press. Through automation we make our release process a repeatable, reliable, easy, non-event process.

In this episode, I introduce Continuous Deployment.

In the last few episodes I've started a mini-series introducing some of the tools and practices that allow for the fast delivery of software, and ultimately delivery of value to our customer.

In episode 18, I introduced Source Control, what it was, why your developers will be using it and the value it brings.

Once your development team has saved their software code to the Source Control, I then introduced Continuous Integration in the last episode, episode 19. I described how Continuous Integration allowed us to find problems faster - allowing us to address them much more cost effectively and making Software Development much more productive.

In this episode I introduce the next step in the process of getting that software into the hands of your customer - Continuous Delivery

UPDATE: I noticed after initial publish the order of the clips in this episode where very incorrect.  I've now updated - apologies for any confusion.

In last week's episode I started a mini-series introducing some of the tools and practices that allow for the fast delivery of software and ultimately delivery of value to our customer.

In that episode, I introduced Source Control, what it was, why your developers will be using it and the value it brings.

Once your development team has saved their software code to the Source Control, what happens next?

In this episode I introduce Continuous Integration.

In this episode, I want to talk about Source Control.

Source Control is a tool that should be available to your Software Development and at the heart of everything they do.

The aim of this episode is to introduce to you what it is, why they should be using it and ultimately why your are probably spending money on it.

This is part of a mini-series which takes us up to Christmas. I will introduce some of the tools and practices that allow for the fast delivery of software and ultimately delivery of value to our customer.

We start with Source Control in this episode, then move through a number of closely related topics to getting our software investment in front of our customer as quickly as possible.

In this weeks podcast, I wanted to talk about how the size and complexity of a deployable piece of software matters to the ability to deliver value to the customer - and thus ROI on our Software Development.

In this episode I want to introduce the term Technical Debt.

The term Technical debt was coined in 1992 by Ward Cunningham to describe what happens when we fail to adequately maintain what he calls “immature” code.

I find technical debt a great way to express choices we make in prioritising our software development investment.