// Projects

// Study

We wanted to re-think the process of development so we conducted our biggest internal study to date. Focusing on our last 30 major projects in sectors such as Pharma, Conveyancing, HealthCare, Military and Finance, with projects ranging from major platform rebuilds, AI POC's, Start-up and BAU projects - this is what we have found!

Analysing these projects scanning 1000's of emails and 10,000's of tickets and combining anecdotal evidence from retrospectives we have narrowed down to 3 main pain points for CEO's and Stakeholders

• Time to implement features is slow
• Response time is slow
• System is buggy

And we agree 100% but why is this the case. Analysing the our big wins we see that our 3 main happy points from CEO's and Stakeholders perspectives are near perfect antonyms of the above

• Development was faster than expected
• Platform is fast
• System is rock solid

Why is this the case?

Breaking down the projects that had these wins we started to see obvious patterns and similarities

• Almost all greenfield
• The companies were not religious about technology
• The IT team was small

Let's breakdown what we think is happening

Treating projects as greenfield removes the shackles of legacy systems, makes for easier alignment of the user and technological journey tighter and allows for easier testing and validating of process.

Companies that are religious about specific technologies e.g. We must use MSSQL or we only have PHP or C# dev's in house so you have to use them often miss opportunities for existing technology which has a much better fit with there goals to relieve current pain points.

Smaller IT teams just work better in our opinion. Not only does it cost much less, development is more rapid and it's easier to get buy in and cohesiveness. The vast majority of clients we've embedded with, with multiple larger teams we have found that the teams have grown because Investors / Stakeholders and Directors have time pressure so more hands make faster development. We have found this to be one of the biggest and most costly fallacies. When there are many teams there are many chefs, there is a lot of contention and conflicting priorities. To build new features may require say the UX having a requirement on the API team but the tickets aren't yet ready and they have a blocker on the Infra team to make who have yet to make a change to a Terraform project and QA's are currently backed up for the next sprint so that simple API call won't be in place for 4 weeks. Were as a single team of a few full stack dev's would handle that in the course of an afternoon. That should sound familiar to lots of the C-Suite and is understandably frustrating.

Why do we do this though?

Not understanding the problem. In lots of cases we mistake a supply and demand of resources being the problem. Throwing more development resource at a project will not solve problems within the project wether they be data structure issues or incorrect infrastructure. Teams will often work a round these problems to show progress and hit targets. It will get the job done at the cost of higher barriers to entry in the form of knowledge and with greater number of caveats which also carry greater risk. Putting the breaks on and dealing with these so called technical debt issues is not a popular choice. But 9 times out of 10 with hindsight is the correct choice as incorrect modelling of data or sub optimal infrastructure choices can plague an organisation for decades.

Ultimately the best way of dealing with this is cultivating a flat structure to both business development and domain knowledge and eradicating the concept that an idea or concern is valued based on the pay grade of the person raising it. All to often we see developers confused by a decision in the lack of the knowledge of the wider picture not just from a development perspective but from a business one to and on the other end of the perspective there is situations where management have not been made aware of fundamental blockers which require a complete rethink to a system or solution which were known to the developers early on but because there was no way to raise the concern to the executives they continued to build until they hit the wall.

// Oxidization

Oxidization is the rework of applications in Rust Langauge. Why would you do this? There is a very good reason why

• Microsft has said all new developments that would previously have been in C++ are now to be rewritten in Rust
• AWS Firecracker VM's the virtual machines that run Amazon Lambdas is written in Rust
• That Rust has now made it into the Linux kernel

If you are not a 'techy' reading this, we appreciate that these seem like buzz words but the point is that Rust is first class citizen for the biggest technology and cloud providers and is deployed at the heart of the technology.

What are the advantages at a business level. Because applications are far smaller and can be whole orders of magnitude faster it means many things

• Massive reduction in resource costs either in the cloud or on premise.
• Code that can be re-used from the backend to the front and even on embedded devices
• Because of its type system if written correctly it guarantees state.

State Guarentees?

Why we should care about this or what even is it? Consider a database table or even spreadsheet of 'animals'. Now image a column 'Is Alive' and another 'Is Hungry' now ask yourself can an dead animal be hungry? This is a trivial example but add a couple more variables and you have a huge amount of states which can exist and handling them all can create a huge amount of cognitive complexity and lead to data becoming dirty. CTO's and tech leads know this problem all too well.

So how does Rust help? In simple terms by modelling data using the strong type system data cannot exist in that state. It will also not allow a program to compile unless all valid states are handled - in tern this forces questions to be asked and help uncover hidden edge cases within business and organisations.

// Contact