Developing Through the Ages with Factory 73’s Technical Director Colin McMillan - E2

Colin McMillan’s career has seen him at the precipice since the web’s early years, placing him perfectly to observe the evolution of development through the ages.

Progressing along his journey to become Technical Director for Glasgow-based Factory 73, Colin joins us on Great Software People as we delve into embedding culture, the irreplaceable value of job satisfaction, and one project that changed his approach forever.

Episode highlights

• “Job satisfaction has always been important to me. It means that when the stressful times come and go, there’s still a good outcome at the end of it.” - 10:00 - Colin McMillan

• “Everybody knows everything about what’s going on when you’re a small agency and information is shared really easily. When you get to a certain size, that breaks down.” - 15:15 - Colin McMillan

• “You can build a company with the culture you want from the start - you don’t have to tackle trying to change a culture when it’s already embedded. That was a real opportunity and a gift.” - 20:00 - Colin McMillan

• “I would always - and I do always - look to do due diligence on any site we’re taking in from a third party because, be it small agencies or enormous global organisations, I’ve seen good and bad code from all of them.” - 29:30 - Colin McMillan

• “If people don’t intrinsically care about their job and the code they make, then you won’t get good code. It starts with people, with their attitudes, and their desire.” - 31:30 - Colin McMillan

LISTEN HERE

Spotify:

Apple:

Amazon Podcast:

00:00 Rich Bundock

This is Great Software People, a podcast sponsored by HeadChannel.

Welcome to another episode of Great Software People. With me today I’ve got Colin McMillan, a technical director at Factory 73 who has been in software for a long time. We’re very excited to have you with us, Colin.

00:30 Colin McMillan

Hello, thank you very much for having me, Rich. It’s good to be here.

00:34 Rich Bundock

So, I think the first thing to do is start and get a bit of background about how you got into software. Did you wake up one morning as a teenager and say yes, this is the job for me? Just talk us through that whole journey to where you are now.

00:51 Colin McMillan

Yeah, it’s different to many people, but I consider myself very lucky to have ended up in this industry. I was a student on my second attempt at university. Effectively, the internet had just hit Glasgow; we were behind the .com boom in London. But by the mid-90s, people were starting to get dial-up connections and looking at the internet. By 1998, a friend had approached me and started talking about building web pages. And he’d found this software called Dreamweaver. And he had done a little bit of digging into it. And I thought, oh, that sounds interesting. The internet is exciting and new, and I’m up for a challenge.

So the two of us spent a few nights figuring out how the software worked from effectively just using it and seeing the code put out. And there were a few early websites that were go-to places where you could get answers to questions. I think WC schools and some classic ESP website forum places were already up there. So yeah, I’m self-taught; I’ve hardly done a day’s computer or IT training in my life. And certainly, at that point, I hadn’t done anything outside of school.

But the two of us got into it and as friends bit by bit with bands and various other, you know, small groups that wanted a lot of website presence. And so we started working away on those and learning HTML from scratch. So yeah, that’s really where I started.

2:31 Rich Bundock

See, you’re at that moment in time when HTML came out. Shortly after that, JavaScript came out, and no one knew anything about JavaScript apart from the fact that you could just copy and paste scripts from other sites, which sort of worked.

2:47 Colin McMillan

Dream Weaver had these built-in widget things. I can’t remember what they called them, but they were snippets. And they would do mouseovers, rollover effects and straightforward things like that. But they were all you really needed. On click events, you’ll remember the early days of the internet; everything was about pop-ups. For most sites, the more pop-ups they could deliver you with adverts, the better. So yeah, we could use that stuff within Dreamweaver to get us started. And, at the time, we weren’t doing anything much more complicated than that. You just wanted a little interaction on a mouse over a navigation or something like that, maybe a drop-down navigation if you’re feeling adventurous. But it was all straightforward.

Web pages were built using HTML tables, which is entirely the wrong way to do things, but that was how everybody did stuff at the start. Getting frustrated over moving things by a pixel to try and make them lined up for them was very challenging. You look back on that stuff, and some of my earliest sites are on the Wayback Machine on archive.org. You can go back and look at how simple they were, but they served their purpose at the time.

03:54 Rich Bundock

So what happened was, you were sort of doing web stuff. And then what happened?

4:03 Colin McMillan

Yeah, I got to the point where I thought I could get employed doing this. I was running it alongside university and was losing interest at university at the time, doing a course that wasn’t right for me. A job opportunity came up with the Carnyx Group, who run the Drum magazine and Drum website, and they had a broad range of magazines at the time. And they were looking for somebody to come in and do web development and start an online presence. And it was very much a training on-the-job rule. They were happy to bring in someone who had basic experience. I learnt PHP on the job. I had done classic ESP as my server-side, dynamic pages, and functional programming, but it was pretty basic. They were happy because of a fundamental inability to hire.

So, my first job in tech was with them. I spent a year there, building the ability to edit news and keep their websites up to date and not be static Ad News articles that were going into magazines or different events and things like that, working alongside a graphic designer and a dedicated web designer. Then, by circumstance, I met my now-wife in the design studio, and that’s now 23 years we’ve been together. So yeah, that was a great first job to have as things really came together. And that job kickstarted me to be able to call myself a developer.

5:48 Rich Bundock

That’s when you felt that that’s what you were?

Colin McMillan 5:53

Yeah, and I enjoyed it; it’s important. Sadly, many people don’t get the opportunity to enjoy their jobs. For reasons of circumstance, or the kind of company they worked for or, you know, whatever has come their way. I kind of fell into this, and I’ve always enjoyed its logic. Code works like my brain works in a lot of ways. But you can still be creative with it. And you can get a sense of satisfaction from delivering something that is fully working, and if that’s what you wanted it to do, and it looks good, other people can use it and appreciate it because you’re launching it to the public. So, with many of those elements, I felt like this was good, and I enjoyed this as a challenge. But this was a career path at the time because there were many opportunities to work there.

06:47 Richard Bundock

And so, after that, you really flourished as a developer.

6:52 Colin McMillan

Yeah, I had another strange opportunity. There was a recession around that time. And sadly, I lost my position with Carnyx Group. I picked up a job with a defence engineering company, which is quite a different world to be in, and not necessarily, ethically, that I was happy to be in, but at the time I needed the work, I needed the job. That threw me into application development using the same technologies. However, they had a variation of classic ESP and US in there, which I am trying to remember if it was more JavaScript syntax but built on top of classic ESP.

7:36 Rich Bundock

I think J scripts are the ones you mean.

07:35 Colin McMillan

Ah, yes, it’s a bit like F sharp in a different language for the same platform. The job there was to head up a team building a financial and project management system for a big defence project. This would be used as a stepping stone towards them buying a big monolithic off-the-shelf commercial package. Still, they felt the whole team and the company needed to train the methods we will use for this called Earned Value Management. So, this is a methodology used in Australia for managing huge, very high-budget projects.

And effectively, as you’re tracking work packets, completed work packets running late, over budget, under budget, and so on throughout the project, there was a series of formulae that would give you an idea of how far over or under budget you will be at the end, or how far over or under schedule, you would be at the end. So, quite a lot of mathematics is in there. It was used to track these big projects over five years to ensure you didn’t have a four-month and 6 million pounds overrun at the end, which wasn’t uncommon in that industry.

So, I spent two and a half years working on that product and getting that to the internal market effectively, which was a real challenge. Still, I worked with some really clever people there, some great engineers and financial experts who were keeping me right; they were working on spreadsheets; I was comparing my code to the spreadsheets to ensure it was all right and in place. And, by chance, I bumped into somebody on Garden Street in Glasgow one afternoon, who used to work there. And to my surprise, several years after they were still using this platform, they’ve never actually transitioned to the extensive commercial off-the-shelf system they planned. So that gave me great job satisfaction that I’d written something, and it was robust enough to stand up to that kind of the level of the project.

9:50 Rich Bundock

Yeah, it’s always satisfying to know that after you’ve left, your code is still working and serving a purpose. You get that feeling of satisfaction.

9:55 Colin McMillan

Yeah, definitely. I think job satisfaction has always been important to me. It doesn’t matter if I was 16 and mowing our neighbour’s lawn, having a good look at the end, seeing the stripes, and seeing it’s all even then, and there are no mistakes. And I got satisfaction out of that even at that age. It’s intrinsic to some people, maybe not others, but that’s how I am built. I certainly do. It keeps me going and makes me happy with what I’m doing. And it means that when stressful times come and go, there’s still a good outcome at the end of it. You hope it’s all going to be worthwhile.

10:30 Rich Bundock

Yeah, and we’ll come on to that in a bit; I think about the satisfaction because as you continued in your career, you ended up more with teams, right?

10:47 Colin McMillan

Yeah, it all changed towards the agency world when I took a job with Dog Digital in 2006. That was my first job in an agency with which I had been corporate. Well, obviously, with Carnix, a publishing company that had been corporate either at the defence or housebuilder, doing sysadmin stuff, quite a variety of tech work, really. Then, I was invited to become a developer at Dog Digital, and that was my first time working in an agency building commercial websites for big-size clients and learning on the job.

It was fast-paced as brand new technology had come out, and we had to keep up and learn as we were going and collaborate within the team to find out how we could get past various blockers thrown in our way. If anybody remembers DotNet 1, DotNet 1.1 was slightly better, but not. It took a good few iterations before DotNet became a sensible, easy-to-understand framework that didn’t throw real curveballs in your way as you tried to achieve something. So yeah, those days were challenging. But we did some nice work back then.

I’m eternally thankful to Dog because as it grew, I had opportunities to grow within the organisation, from developer to senior developer. At one point, there was a need for an infrastructure manager. So, I had some server management experience, and I took that role to run the internal infrastructure, network, firewalls, and all that kind of thing.

And eventually, as the company grew again and Graham McClurkin exited, I became a development manager. And that was my first management position running the development team. But under a technical director, who took over from Graham Crawford-Tate.

So yeah, that was the first time I had direct responsibility for a team of people. And I dug into books, believe it or not; rather than being very aware that I hadn’t done any management training, I looked around, bought a few books, and started getting into those. Quite a lot of good lessons, approaches, and strategies came out of that at the very early stages of my gearing up and ramping up to try and be a decent manager and not be a failure in the first few weeks.

13:57 Rich Bundock

You know, you talked about job satisfaction previously, but how did that translate with the team because you can’t necessarily do the job anymore? Because you’ve got other people to do the job. So, how did the satisfaction piece change for you there?

14:11 Colin McMillan

The satisfaction came out of improving what was coming out of that team in one way or another. You know, there were many things to address that I think could have been neglected over a few years. Some processes needed to be put in place; some areas had staffing issues. I think I was facing up too much of that and deciding to move forward properly; we have to think about this as a team and get the team around doing things differently and, to a degree, behave differently, using different technology to what we originally used. There wasn’t anything specifically around what was happening there that was unusual. I think pretty much every agency that had grown as seismically as it had would reach this point.

You can’t be a small, easy-to-manage, or family agency, but I hate using that term. But everybody knows everything about what’s going on when you’re a small agency, and information is shared quickly; when you get to a certain size, that breaks down. Obviously, the size of projects is getting bigger and more complex as well. My satisfaction came out of the successful deliveries or projects, which would be the reduction of issues and bugs because of new processes coming in; client satisfaction goes up as a direct reflection of your good work. And I bounce off that if clients are happy, I’m happy; it means the team is doing a good job. And if internally, you’ve got fewer fires to fight regularly, then that, again, is something that you can be quite proud of, that something’s working in the leadership structure. And you know, you’ve got respect from your team.

I felt like I had that; for the most part, we had a good rapport. They respected me even when I was dishing out the bad news or difficult news. But for the most part, we worked well together as a unit at that company.

16:26 Rich Bundock

Yeah, then you became a solutions architect, and now you’re a technical director. So, how did that transition from the head of technology across?

16:41 Colin McMillan

Yeah, so the Development Manager at Dog Digital became Head of Technology. There was more than strategic technical sales solutions, architecture, and team oversight. But that was challenging; an awful lot was going on there. At times, I enjoyed that pre-sales part of the solutionising, you know, presentations proposals. But then, other times, I realised that I’ve spent weeks and only really looked at Word and PowerPoint; on my computer, I’ve not opened Visual Studio, I’ve not looked at code, and I’ve also slightly lost touch with what is happening. And, you know, talking about war stories, but from the front line of development, the actual guys who are coding and who are facing the deadline and who are, under the cost and the project managers and so on. I didn’t like losing touch with that because I felt I was less able to help, intervene, and provide solutions to help.

I think I always saw myself as being ‘ it’s quite a cliche and a bit corny’, but the glue that keeps the team together and the oil that keeps the machine running, I felt like a good leader is that they’re not necessarily interfering. Still, they’re there to keep things together, and they’re there to make sure things keep moving on. And when you take some of that away, you see those things start to happen: the team, maybe fragments or the machine seizes up to a degree and stops being as efficient as you might want it to be. So, I think you need eyes on what’s happening at that level to be an influential technical director.

So Graham McClerken, who I mentioned earlier, was an original founder and technical director at Dog Digital. And he was my first boss there. He exited in about 2010 or 2011 and started his own thing; several years later, he had an opportunity with a new project that needed somebody else to come in and approached me to see if I wanted to get back in the tools and help deliver this project to join forces with him and partner up. That was an opportunity I really couldn’t turn down. It’s not an opportunity I’ve ever had before to join a business and be part of it. And I thought there was a risk I could go the rest of my days, never having that opportunity. And so I jumped at it.

We were very small at the time. I was employee number four when I joined Factory 73. But really, getting back to that core team, where I was a developer, I was part of the team, and I was leading the team, we were hiring our first staff to try to grow the company over the coming years. So, my life has simplified an awful lot since moving to Factory 73.

But as well as that, I think the real benefit and gift of having a fresh start after being through the difficult times with a team, which was partly inherited from previous leaders, was partly a result of the organisation itself, the organisational culture and so on. Having this fresh start of only having two employees and two directors and building the company back up means you can build it up with the culture you want from the start. You don’t have to try, or you don’t have to tackle trying to change a culture when it’s already embedded. So it was a real opportunity and a gift to have that and to be working on that over the last six years. It’s nearly six years since I started there. So, like I say, it’s been a simpler life, but it is getting more complicated as we grow. But we have a good formula, great people, a good culture, and everybody’s happy. Nobody’s left us, touch wood, and nobody’s going to leave us. So we must be doing something right.

21:50 Rich Bundock

That’s good; it is hard building a culture and even harder changing it, so it’s good that you’ve had that other opportunity. Looking back, everybody who listened to these, you know, loves the stories of challenges. What are some of the most challenging projects you’ve had you’ve had to deal with?

21:36 Colin McMillan

I have to be careful and shouldn’t be naming any names or being very specific. Those involved will know a particular project was set up in good faith. It was entered to help out an existing client, and the statement of work and the estimate were effectively run through on a weekend or a long weekend because there was a serious deadline to get this work signed off and started. Several things needed to be fixed with that process. There’s a lot of trust in the client because of an existing relationship that we would work through any difficulties along the way; we were helping them get up and running. But the technology was wrong for us. The timescales were wrong, and we didn’t fully understand the project. And it was going to involve a lot of contractors to get people started very quickly. I can’t stress how big a lesson was learned for everybody involved. It was a very tough one. But within a few weeks, we recognised at least that this wasn’t going in the right direction, and I was already not seeing a good outcome. Because other parties were involved, IBM was engaged as an SI on the project, the client environment was very challenging, and the developers hired and contracted weren’t up to scratch with what they were doing. That was the perfect storm, where we recommended that we pull out of the project, but that wasn’t followed through.

We ultimately went too far into the project before it came to a sticky end. Our delivery was under, and the client decided that enough was enough and to change supplier. Those frustrations were on several levels, one being that we had recognised the situation. Still, it hadn’t been taken seriously as a critical business situation that needed to be addressed. We continue to fight through the problems, put our best foot forward, and try to make everything better. But that wasn’t going to happen. We thought that it was going to happen. I thought we could try, but it won’t come through that way. And most critically, there was no contract in place. So because of the speed, and it wasn’t uncommon to enter in and start work without an agreement as legal, take ages and turn around, and you’ve got iteration after iteration going through. But there should have been something light that gave us some get-out and commitment. So, without the correct paperwork, we were left alone, and bills weren’t paid either. We never completed the project; it was done differently by someone else. I’ll never forget the day the contractors arrived back at the office, having just been effectively taken off-site. That’s not a good feeling at all.

When you look back on it, you see that the circumstances of why you entered into that job were all wrong. It was bad from the statement of work being rushed, contracts not being in place, and not using a technology we were familiar with. Reaching out into a new technology stack that wasn’t natively ours gave us difficulty and governance.

And then, when it turned out the coding standards we were expected to adhere to effectively tripled the workload on the guys. And we weren’t aware of those coding standards when we entered them into our estimate. So, lessons learned. I can still smile about these things; I genuinely hope I’ve remembered all my lessons. And I will not repeat them; some can send you a bit too risk-averse. And you could just try and live your life playing safely, safely all the time, but that’s unrealistic; we’re still in business and looking to grow the business. There are risks and rewards with what we do. But it’s likely not taking risks of that level that could put you out of business if you’re in a certain financial situation. So yeah, that was probably one of the worst that I’ve been involved with.

Other factors have been external; we worked with another agency delivering a global platform on Sitecore. And we were doing the UK delivery of that, for the first release for the first UK market for a major brand, a well-known brand, with a lot of pressure about it, and it was running late by about a year. So the head office was jumping up and down and wanting to get this out the door. The quality of the delivery from the primary agency was horrendous. But there was no ability to go back and throw that out and start again. We were trying to work against this core platform and struggling with it. And remembering now, though, the project had no specs, and even though it’d be run from head office, nobody had written anything down. And so the UK team didn’t know what to expect. The development team on our side is not 100% sure what we were supposed to be building. So we were figuring out specs, discussing them with the client and head office and then moving forward. But it was like wading through a treacle. The project eventually, I’m not exaggerating when I say, kicked over the line. It was the fourth deployment that they attempted that didn’t roll back. It was going to launch at midnight. They started the launch process at about 11 o’clock; there was a head office, technical architects and infrastructure guys, including hosting and load-balanced testing and everything. So, it wasn’t a small deployment. But unfortunately, when the thing you’re deploying is a mess, there isn’t a good outcome.

Sadly, that was the second iteration of that site; the first iteration was a worse mess. It was the current live site, and it had been delivered from a global IT organisation based in India, to whom their prime minister has certain links, shall we say. It was some of the worst code I’ve ever seen in my life. Then, version two of that came out, and it’s not much better. So, due diligence, that one nearly broke me. Maybe it did break me. The fourth night, up until two o’clock in the morning, only to find out that it was a no-go instead of a go because of various issues. And then going out that again the next day, until it eventually went live, but all always with the opposite of the feeling of satisfaction that we discussed earlier on, for your feeling that you’re only going to come out with a sense of dissatisfaction about this because it’s not a project you can be proud of as it’s not your code, it’s full of holes.

When we got involved with the client and the account, there was no way of telling that it would be the way it would go. So, there was no opportunity for upfront due diligence and understanding. Sometimes, you just find yourself in these circumstances and have to get through it. But I would always look to do due diligence on any site we’re taking in from a third party because I’ve seen good and bad code from all of them, small agencies or enormous global organisations. And it really is impossible to tell based on an organisation. Hopefully, we are excluded, of course. There’s a degree of trust or an understanding of quality from some brands, but with many agencies and big organisations, it’ll just depend on what team or developer you’ve got. And there can be a large variety of outputs from these.

30:40 Rich Bundock

Interestingly, in our industry, the standards are everywhere; everyone has different standards. And a lot of what I hear, generally from people, is that clients ‘if you say, ‘Oh, we’re going to do 50%, unit test coverage, and so, the client then goes, Oh, it’s too much money, and you start to get into those kinds of weird conversations. But do you find that with clients to try and maintain standards? Actually, you have to say no a lot more.

31:19 Colin McMillan

Yes and no, I recognise in terms of lessons learned, I could see fairly clearly why equality issues existed. I can’t talk about anybody else’s organisation or how things were run on other projects when I wasn’t there. But in terms of looking at people within the team, seeing guys in the group who are not as good developers as others, and understanding why they might be, a lot of it is attitude. As somebody I worked with as an Ops Director said, you can teach skills, but you can’t teach attitude. I think you can, to a degree, encourage and try to get somebody to care more, but if they don’t intrinsically care about their job and the code they make, you won’t get good code.

It starts with people’s attitudes and desire to put out good code first. In terms of the processes that get wrapped around that, like unit testing, automated testing, extreme programming, peer review, etc., We use a blended approach to a few of those. But we recognise that in the web development website industry, budgets are too tight to support, and competition with other agencies is too fierce. Therefore, the budgets you propose to run a better business don’t allow that extra money for writing unit tests for unit test coverage. So, it’s been about being creative about achieving quality in other ways. The first time has been one of the things I’ve been driven for, and that’s nothing new across any industry. But trying to instil within the team that if you self-test and you get your work out there, that’s the right first time, then we avoid this big loop that if it’s an internal bug, then fine send development, it’s easier to fix, you can pin it down, you’re working in the project anyway. But that means if you have found a bug out in the wild, it will cost ten times the time if it was caught when you self-tested. Because it goes to the client to our support desk and tech support person looks at that gets triage replicates, it sends it on to a developer, they check the code they do blah, blah, blah, and then eventually it leads to support deployment.

Overall, catching things early is really the most significant part of it. If humans do that with each other’s code, they’re learning the approach to testing and how to test. As well as learning from other people’s gaps and things they’ve overlooked. That feedback loop will make everybody a better self-tester without necessarily taking the time and cost of doing test-driven development, which I 100% believe in terms of an internal software team. I think there are various processes, agile, proper pure, agile being one of them, that lend themselves very much to a dedicated team who have flexibility in what they deliver, flexibility in time and a relatively fixed stable number of people on the team. But in agencies, as you’ll know, we put people on the project who are available in the schedule for when that project needs to start. You can’t compare somebody’s velocity with another person’s because they’re on different projects and then at varying career levels. And in other disciplines, sometimes front-end back end or JavaScript specialists or whatever it might be

35:10 Rich Bundock

Sometimes, it fills in a gap in the capability.

35:15 Colin McMillan

Yes, exactly. So, for us, it’s trying to maintain that philosophy. Everybody buys into company culture, which is foremost, and the priority is quality. And through our quality output, our clients will be happy. If our clients are happy, they’ll bring us more work and referrals. And the whole thing should be maintained from there; it’s a bit like you’re only as good as your last meal. In a restaurant, having a negative project, which has problems, has a big knock-on effect on morale internally. Nobody wants to be fixing bugs for weeks after the project’s been delivered, as I’ve suffered in the past. So yeah, right the first time, learn how to test your code and how a user uses websites, which is doing ridiculous things sometimes, to try and shake and break the site. I think that allows ownership within the team, that they can be proud of their work, and avoids an issue as developers will do the basic, bare-bones and throw a tester for the test or detail and everything they’ve not done and then complete the work. A developer told me that was a strategy once. He just got it working and let the tester tell him what he needed to finish.

36:45 Rich Bundock

Yeah, I’ve seen that happen before. So we’re getting near the end of the conversation, which has been fascinating. But I mean, this podcast is about great software people and how the software greatly impacts those people. Obviously, we’ve talked a lot today about how software actually impacts people on the internal side rather than the actual users of a system. But what is your proudest release or project that made a difference?

37:38 Colin McMillan

Yeah, I think. It goes back a while. It goes back to my early days at Dog Digital when I was a developer, maybe just about a senior developer at the time. And we did a lot of work with the NHS at that point. And NHS 24 had started as a single website, which was everything; it was information, health information, as well as three services and self-help guides and things like that. Obviously, the phone number at the top for dialling the nurse’s service that had just been launched.

That was a project that I effectively ran. The NHS and forum brand were created for Scotland during that time, so it is the Scottish equivalent of NHS Direct in England. And there was a lot of uncertainty from the client about what the brand was actually there to do. There were a lot of discussions happening; we knew we wanted to separate the information delivery part of it, Health Information Service, and the triage part of it from looking for help. I’ve got a problem, a health problem. I need to find out what to do about it. So, a big project went on, and I led that. We built a brand new, I think at the time, it was a Sitecore website for the NHS and forum, which included A-Z ailments, self-help guide, there was lots and lots of information, find your local pharmacy, all these kinds of services and separated some of that stuff of NHS24 at the same time. This was all against a very, very fixed deadline. Nicola Sturgeon was health secretary at the time, and she would be standing up at the ACCC in Glasgow and launching the brand. So, there was no flexible deadline.

39:37 Rich Bundock

Were there no four releases before you finally went live?

39:39 Colin McMillan

No, exactly. So we were right up against the wire. Evenings and weekends were involved in getting that project where it needed to be, mainly due to a late start and understanding of what we were trying to achieve. But it was delivered, and it was delivered on screens on terminals at the launch event. And the reality, I think, at the time, was that the website was one of the few things delivered for that date; the rebranding on health brochures that you could find in your GP or hospitals came later, and a few other things were delayed, too. But we got there, we met the deadline, and it was launched. Then, seeing the NHS as a brand advertised on television regularly over the following weeks and months was a very proud moment. It was because it was a very personal project; there wasn’t a big team around this; it was mine. I was a senior developer on it and worked directly with the client. And between us, obviously, front-end developers, other designers, and everybody else that needs to be part of a website, but a pretty small team, knowing that it was public domain, everybody knew NHS 24, within a few months, and many people have used it. And for the years that lasted on that ownership, it was a great project. And, between NHS 24 and NHS and Forum, they genuinely helped people in a difficult situation.

41:02 Rich Bundock

Yeah, that’s very fulfilling and very satisfying, which I think brings us quite neatly back to the point that you made right at the start, which is that the whole enjoyment of being in the software industry is that satisfaction you get from seeing something delivered that makes a difference?

41:33 Colin McMillan

Yeah, absolutely. And I think it still happens to this day, even though it’s not my work, it’s other people’s work; we should all share in success and celebrate that success. The tricky thing is finding the timing for it. There’s one thing I’ve learned over the years in delivering a project: you’re often not providing the end of the project; you’re delivering phase one. So, having a big launch party, I think we’re always up for that. We always want to be doing that. But very often, you get to that phase one launch. And everybody is already talking about phase 1.1, phase 2, or the next bit. I joked years ago that the actual time you should be celebrating the completion of a great website is when the client takes the website somewhere else for a brand-new one because only then is it finished. And it’s going to be replaced with something.

But no, everyone should be proud of the work that they do. Everyone should be encouraged to meet those standards and, therefore, feel good about the output they’ve done and the impact that it can have on the client.

42:52 Rich Bundock

Yeah, it’s great to hear your story and share some of what it’s been like over the years with everything you’ve done in your experience. So Colin, thank you for being our guest today on great software people. It’s been an absolute pleasure. I thoroughly enjoyed that. Thanks so much.

LISTEN HERE

Spotify:

Apple:

Amazon Podcast: