The future of software engineering?

For those who have worked closely with me before, you will know I'm not a big fan of one-size-fits-all development models. Utilising individual skill sets and aptitude has always been more important to me than assembling a scrum team of 8 with a scrum master (in my opinion) an often unnecessary role — typically brought in to try to knit together a team that was never constructed or trained correctly in the first place.

Having been a development lead for several years, I know first-hand that a team of 8 is generally too much for one person to actively mentor, manage and still continue to add meaningful value to the team — i.e., not just become a manager.

So why is the above relevant to what I'm about to open for discussion?

Having moved recently from the corporate world and the ubiquitous pressures of offshoring 70% of the team to "save money", the ever-changing agile methodology directives that shift every time a new “expert” replaces the previous transformation lead (whose tenure often resembles that of a failing Premier League football team manager!), I've got far more flexibility to re-imagine how development teams should be structured and it has made me really think about what a development team of the future looks like.

I've always said that the easiest team to manage has always been a team of one. Everyone knows what everyone is doing, communication is clear, and prioritisation is simple.

Each additional person you add to a team makes alignment harder. Remote working, distributed locations, and often unclear requirements or direction make getting the best value out of a team a real challenge (cue agile coaches saying “let’s add a scrum master").

Recently, I was scoping out the designs and estimates to build 4 new products to accelerate our business. The goal was to understand what team sizes I would actually need. With a mindset of practising what I preach — not creating bloated teams — the largest team I ended up with was 5. I even aligned 2 products together and concluded one team could work on both in parallel. Maybe that goes against the grain, where it’s often claimed a team can’t multitask — but again, my experience has shown that’s simply not true with the right people.

But then I started thinking about recent conversations with my team, sparked by an event I attended with other CPOs/CTOs about the use of AI in software engineering.

This made me ask: am I being too old-fashioned in my thinking?

I started reflecting on the work we’re already doing with AI.

One of my team recently refactored a pretty sizeable codebase over a single weekend. In old-school terms, that project would have taken a team of 5 a couple of months.

We’ve had failures too — where we realised domain knowledge and understanding the programming language are still vital when using AI. But it was a fail-fast moment and, thankfully, some of it will be recoverable through R&D grants!

But we’ve also had some great successes: small "teams" of one or two people building incredible solutions that drastically speed up product development — or even become products themselves.

I raised the topic on my architectural forum recently and discussed it with my senior engineers. Listening to their thoughts, what I suspected was true: senior developers are using AI far more effectively than junior ones. AI to them is effectively becoming their junior developers — allowing them to scale with how much they can do themselves.

It's not to say AI is perfect. A well trained engineer will probably write better code, the LLM's haven't seen the full universe of source code, so for example, complex financial models are still not it's forte.

One thing I'm pretty sure of though, if not already true, is that software engineers not using AI effectively, will cease to exist.

 But this begs some serious questions about dependency you have on your current SMEs and how long you have that experience around for and how do you ensure the new generation also becomes able to fully make use of AI.

 So my questions:

•  How do we now train engineers entering the industry?
•  Is programming language-specific training becoming less relevant?
•  Is product/domain knowledge becoming more important than in depth programming language knowledge?

Are we finally entering an age where Test-Driven Development, aka a well understood specification combined with a well defined .md file, reflecting the organisations architecture and SDLC standards is maybe a future that is already here?

 I have my own views on these questions, but very interested in further opinions.