The Future of the IT and Software Solution Space
We speak with Jacob Anderson, President & CEO at Beyond Ordinary Software Solutions, about the typical software stumbling blocks faced by large corporations, the consistency of human elements in software development, and emerging trends in the IT and software solution space.
What is your process when it comes to identifying an organisation’s software failings and systems that might be streamlined?
Failing is an absolute, so let’s use shortcomings instead. The business is likely starting to feel a need to evolve, which usually means scaling to more users or being able to add more functionality with less cost. These are the common streamlining efforts that every business must encounter during their growth evolution. In this way, the biggest shortcoming of any software system is its inability to support future growth in the business. This is akin to a bodybuilder hitting a plateau, not being able to get bigger or stronger.
When I am asked to help in these situations I always ask about the next milestones for the business and how those milestones are measured. These milestones are important for software systems because they are the boundary conditions for performance. If the business is trying to double its revenue, then we need to know how the revenue is calculated and then what channels contribute to those calculations.
Once we have that enumeration we can focus on the software components that support the channels.
The harder problems to solve involve the marketing teams. Sometimes the business is stagnant and there is a need to attract a new set of users. The software will need to have new functionality, or it will need to rebrand the functionality it has. This kind of refactoring takes a lot of time and effort, spanning multiple business divisions, and has the highest risk of failure.
Following on from this, how do you work to develop bespoke solutions to these issues?
We have to know how we can customise the software for the business. Often the business is using an off-the-shelf solution that is no longer adequate for them. When that happens we look for ways to customise the software. If that can’t be done, then we look for a way to encapsulate the software with another system that can be customised. If neither of those options is possible, then we need to write a new solution from scratch.
There are times when we have to reverse engineer an interface to existing software. That’s never fun, nor efficient. If the software in question is old and not supported then we have to spend a good deal of time trying to figure out how to automate the use of the software so that we can encapsulate it with a modernised software tool.
When the organisation in question is particularly large, how does that impact the work of developing software solutions for their needs?
The time to start a project is directly proportional to the size of the organisation. That’s really the major hurdle with size when it comes to software. Once the project starts, the organisation’s size doesn’t come into play. Projects are usually done at the group level so we’d only be dealing with no more than 30 people in the organisation.
In your experience, what are the typical software stumbling blocks encountered by your large corporate clients?
Inertia is the most common problem. A large, established business always resists change, and the people who build the software at such an entity will resist changing it. In those situations, I have to be unassuming and move slowly through the shark tank until I can recruit some of the existing developers in an effort to refactor the software. So long as the existing team can come along with the changes and not be blindsided by them, then the project will succeed. It’s in the cases of “waterfall” when the project change is dumped onto the existing team that the new software encounters problems and business sabotage.
How has the nature of these issues changed during the 20+ years that Beyond Ordinary has been in operation?
They have not changed at all. The human element in software is very consistent and seemingly resistant to any change. With the advent of more advanced code generators, like ChatGPT, the software factory will change considerably.
I like to make an analogy that I am stealing from my WPI computer science professor. In 1947 the transistor was invented, by 1960 the computing curriculum was changing and the last class of vacuum tube engineers was told that their academic knowledge was obsolete thanks to the invention of the transistor.
Today, in 2023, I am telling all of the software programmers out there that this is the transistor moment. Everything that you know about programming is now obsolete. A software tool can write functions and implement algorithms similar to, if not better than you. It’s time to rethink your future strategy about software development. In as short as 10 years we will see the fall of software programming and the rise of system-level programming.
What new skills and knowledge have you and your team developed in order to better respond to these?
I’ve started to encourage the team to train up on system design and architecture. I’ve also continued to further my own understanding of artificial intelligence and machine learning algorithms. This is the direction where software is going, and hopefully, I can direct the team towards that goal.
Are there any specific emerging trends in the IT and software solution space that you find particularly exciting?
Machine automation is coming back quickly. We saw this back in the early 90s but it died out fast without the necessary fast computing that it needed. Today we have faster processing and broad scaling of computing. The greater level of automation is exciting to me, but that’s because I like automating processes. This automation will lead to much less error in computing, business, management, etc.
Do you have any projections for how this sector will develop in the latter half of 2023 and beyond?
This year we will continue to see LLM-style learners (large language model) being applied to software development. We will see automated software static analysers that can accurately identify software vulnerabilities and suggest reasonable fixes. Humans will still be programming for the next 5 years, but today is the transistor moment.
I had a conversation with Eneri, a dad on my daughter’s volleyball team. Eneri (Ed) is an industrial designer and a very good and successful one. We were waiting for the next match to start and started talking about software and AI and ChatGPT, of course. So I shared with Ed my future prediction for software development.
In the 90s we saw Aspect Programming come to light. This was an innovative way of reusing software slices across new software systems without having to program the same stuff, over and over. AP was only marginally successful, but it was a great idea. There are legal issues with AP, such as copyright infringement. AP is the process by which you extract a function (aspect) out of compiled code (DLL/lib) and link it with other extracts (slices) to make a new execution path (program). We do this already with reused libraries and modular programming, but that’s done in a trusted jail environment. AP was about breaking out of jail and creating slices across code that was foreign. AP didn’t take off because many different programmers were creating the libraries, and these programmers had different styles and code contracts for the interfaces. That means the slices were not compatible and required a lot of middleware wiring to make them work.
With LLM code generators the disparity of style is gone. Tomorrow we can have an LLM tool that generates the same code repeatedly. This means the interface into the aspects will be consistent, which is the key to making AP work successfully. 15 years from now, AP will re-emerge as a dominating technique for rapid application delivery. This will only be the result of these new LLM code generators being developed at Microsoft and Google. This could also be the birth of a generation of systems that optimise themselves.
In 25 years we will no longer see any programmers spewing out code in Visual Studio or Emacs. That is done. We will be seeing software designed like Jordi La Forge in Star Trek – “Computer, create a program that does X” – and the LLM will generate a program that pulls in aspects of other programs to create one that “does X.” For this to happen, though, the future of computer science teaching is going to be in system design and contracted interface architecture. The software design tools that output SysML to describe software will be able to run that SysML through an LLM and have code generated and be usable with no human interventions.
Can you tell us about some significant past projects involving large corporate clients that you and the Beyond Ordinary have worked on?
We’ve done quite a bit of work in the insurance industry. If you’ve ever bought insurance online then you’ve likely used the software that I wrote. When I started working in the insurance industry around 2000, there was no use of cryptography or data protection. It was a struggle at first and a steep mountain the climb, but eventually, I convinced some early clients to adopt cryptography in their databases. All of our insurance clients, today, start with cryptography on day 1. I am proud of that struggle as it has protected millions of people from data disclosures and elevated awareness of data protection in the industry.