This article is the first in a series about a real-life journey undertaken by a company which had little knowledge of software development but which absolutely needed this capability to sustainably serve the evolving needs of their customers.
Spoiler alert, this story has a happy ending and the team is now super confident being masters of their own software destiny and just last month released their fantastic next generation global platform to better serve their customers into the future.
Like all journeys there is a beginning, and this one for me started several years ago with a chat to my neighbor who asked me if I would be able to help a Managing Director friend of his with a software problem. No worries! I said as it’s always nice to have the opportunity to use your experience to help someone.
What a mess, that code base was not easily maintainable and certainly not sustainable.
Soon after, all three of us met for a coffee down the road and the MD started to describe the issues. She had just taken over as MD of a well established business after key portions of the old guard had stepped back. To top it all off, the corporation maintaining their key aging software solutions, was stepping back from software development to focus on their core business.
The MD and her team were working furiously to not only train new staff but also to introduce new processes to improve the business and having a solution which could not be changed was totally unacceptable. Unfortunately, the MD and her team knew little about software and didn’t even know how to begin but were happy to learn. No Worries! I said, how about I help you find someone to maintain your software solution.
And so the journey began …
The first step was to work out what shape the existing solutions were in and what technology was in use. From a stakeholder perspective the existing solutions were solid and functioned well although they appeared dated … under the hood the story was bad, it turned out it was written by two different companies using legacy technology in a custom framework now pretty well obsolete. What a mess, that code base was not easily maintainable and certainly not sustainable.
Therefore, the problem was to find a provider who not only was capable but more importantly willing to work with the old code and the custom framework. The provider would also need to have the skills to eventually produce a new more sustainable solution. This is really tricky as software developers who maintain old skills rarely also have the skills in new technologies needed to produce a new more sustainable solution. The available choices were rapidly narrowed down to:
- Large software development houses who still maintained staff with skills in old technologies but also had teams working with the latest and greatest
- Smaller more beautique providers who had very experienced staff who used to work in these old technologies but had now updated their skills.
I invited three large providers and a small independent development shop comprising of a single developer for the MD to interview to work out who her team would be comfortable working with. All providers could have done the job easily and were far more skilled than her current provider.
The small independent provider was chosen. One reason was that the larger organizations were deemed likely to have more staff turnover and so less likely to provide a continuous points of contact for what was a long term key supplier relationship. The one concern with the small provider was that given there was only a single developer, this could place them at risk of suddenly having no provider again if something happened to him.
The small independent provider was chosen.
Being a highly skilled developer, the new provider was in high demand and we were lucky that he only became available when another client suddenly dropped off. To help him get a better understanding of the business needs, the team and also the code we did a meet and greet through the office and described the code base and current solution. He was not really keen on what we had described about the old solution as he didn’t really like to work with such a mess. Fortunately, the meet and greet paid off and he admired the MD and her teams’ efforts as well as their long term forward thinking and came to the conclusion that this could become a great arrangement. So he agreed to help two days per week.
Who hoo! Problem solved right?
Who hoo! Problem solved right? Well not exactly, just having an external developer, even a phenomenally experienced one, did not automatically mean the team now had a sustainable software capability.
In the next article The Road to Building Sustainable Software Capability – Part 2: Stabilization I will detail what internal changes the team had to make to be in a position to maintain their existing solution and set themselves up for a sustainable future.
