Ramblings of a software engineer — and what I learned

What makes work great? Projects and jobs come and go, but the people you worked with, the friends you got to know and the difference you made will stay longer…

Big projects can start small

The ‘small’ project I joined over a year ago grew into a large, multi-discipline team of developing a whole host of solutions and services, battling against critical deadlines that seemed so immovable only a few months ago.

When I joined the project, there were 2 developers, BAs, designers, consultants and the usual delivery management team. I was brought on to be part of the proof-of-concept (POC), ultra-fast, super technical developers that can deliver at speed. Our remit was to demonstrate what could be done.

The power of Azure

The first thing I learned on this project — you can create things in Azure, and have them deployed, at speed. We created AD Domain servers, virtual machines, websites with AAD authentication that interacted with email APIs using Microsoft Graph in a matter of days.

This would become what I rather fondly called the fun period; create and destroy a multitude of compute resources on demand, with little fuss and an open remit to “get it done”.

In the coming months, and subsequent leavers and joiners on the project, I was given the chance to become the technical lead. The scale of the work to come was becoming ever clearer and the need to ramp the team up grew with it.

This is where I learned the less than optimal way of having the right amount of people at the right time; the value of domain knowledge throughout the project life-cycle, a strong QA and development presence, and small enough “pizza sized teams” to plagiarise Mr J. Bezos. It was so true: it’s like ensuring your threads are working efficiently and minimising bottlenecks and deadlocks… You can’t have everyone working too closely in the same areas.

Parallelism and agile at scale; many small teams working on various independent areas. Getting this right was one of the keys to success.

Leveraging DevOps

From the get-go, I wanted a fully comprehensive CI/CD pipeline, incorporating fully automated releases right from developer code check-in all the way to production release with the correct branching strategies. Everything was to be deployed went through CI, code reviews, PR and fully automated builds and deployments using Azure DevOps and Octopus. Nothing was manual from an application code/database/configuration deployment. The key takeaway from this was getting your automation and CI/CD right, your “route to live”, it really can make or break the software delivery lifecycle.

Like with all projects, there were areas that could be improved and my main take away point is this: don’t let your infrastructure CI/CD lag your application CI/CD (or vice versa!).

The SOLID foundations

What became evident from this project was the need to be loosely coupled. We were growing at a rate of knots, to the tune of 14 app services, 5 databases, some Azure Functions and Logic Apps, Storage accounts, Queues, Redis cache, Virtual Machines and all the associated infrastructure being deployed into Azure.

We had as many front-end individual applications as back-end APIs — and we did this in less than a year from inception to hitting our target of 29th of March. We also had 27 CI pipelines to support this…. And nearly as many release pipelines, plus the QA automation pipelines!

We were embracing ever more the need to be a micro-service architecture: many individually deployable components worked very well, especially in the run up to releases and production hotfixes… we defined what we wanted to update and when. No dependencies. Just a front-end app for content? Just the GUI, please. Some business logic error? Just the API.

Whilst we’re at single responsibility: there was a time when we weren’t SOLID enough. Not something that I’ve normally been afflicted with, but the pace of development required an ever firmer approach to code reviews and development patterns. If I was to go back and do it again, I’d take the patterns I’d started the teams off with, enhance them, continue with the ideas the other valuable team members provided, and enforce them even more by further showing the true value of why we do it — I am proud to say the team truly got it.

Security — the profession that loves to say NO

Security. Most people love to hate it. I used to believe it was the job of the security architects to say no on any given Sunday:

• Want to release to production? Nah.
• You’d like to connect to virtual machine via a VPN? Only if you do these 3 other things first…

You get the point… I took it seriously — and stubbornly — from the beginning. I created a (what I called) “Gold Standard” list of configuration options;

• Reviewed Azure AD API authentication best practices,
• Reviewed web application configuration best practices for MVC,
• Investigated all the application’s JWT validation parameters for Azure B2C

I am proud to say that the project, across all our applications, never got a single “high” security risk. This was from two external ITHC suppliers and one internal team. My main takeaway is bake in the security practices and architecture from the get-go: it’s a pain to retrofit at best.

Stakeholder engagement

The team we had was made up of not just Capgemini permanents and contractors, it was also client permanents and client contractors.

Herein lies a key component of successfully delivery:

• Open and constructive discussions with the client.
• Stakeholder engagement is so important and building those relationships from the start

I had a good relationship with the client. I was able to build a strong rapport with them, and challenge, advise and guide through what sometimes you could describe as a minefield of ups, downs, challenges, successes and confusion. I will miss working with them in future. So many character’s and personalities, and so many nice people who ultimately want to get this done and achieve the best they can.

The value of a team and the people in it

The team was fantastic. It was one of the best examples of teamwork I’ve seen, working relationships were built into proper friendships. The project’s success did come down to its people. Not resources, not bodies or bums on seats. Don’t underestimate this fact — building the team from 1 developer to 12, and supporting the other various areas ramp up to the same degree, was a privilege not a right or just a ‘job’.

Closing it off

I believe the project encompassed all of Capgemini’s core values from the ground up, especially Honesty, Fun, Team Spirit and Trust. The big question… if I could do this all over again, would I?

Yes, without doubt. But I’d ask for more team pizzas. And better internet.

Join the Capgemini Microsoft team, open roles here.