I work at a software company whose flagship product (which I’ll refer to as SystemNow) has been around for maybe 20 years now. However, even way back in 2016, the software architects began a project to look into what the next software would look like (ProjectFutures), and development really started ramping up around late 2018/early 2019.
I reckon it took around 5 years of development for SystemNow to be initially released (then continuously enhanced and fixed), so maybe you would think 2023 could have been a good release date for ProjectFutures – its core features at least.
However, in 2025, as I began drafting out this blog. Despite the claim from managers that ProjectFutures has been “released” and is a “success”; in my opinion, it’s like 10% of the scope, and barely been spoken about. 2025-26 has seen little progress.
I think it’s been an absolute disaster and I do wonder where it stands among other high profile software disasters. So I thought I’d reminisce and go back through the many poor decisions and failures along the way. You could say there’s all kinds of failures, and you probably can’t point your finger at any one aspect/decision, but many intersect.
Why Rewrite It?
When we have a very successful software product, then why rewrite it? I had a quote from Cory House who explains some of the reasons for the initial drive:
“Each year, I work with a few teams that are basically doing the same thing: Rewriting old web apps to use React. The old apps use ASP NET Web Forms, JSP, jQuery, Cold Fusion, Perl, etc. Often, the requirements are simple: “Make it work like the old one”.
This might seem silly. If it ain’t broke, don’t fix it, right? But there are good reasons:
They’re having a hard time hiring and keeping good help.
It’s harder for them to add new modern features compared to modern technology.
The old tech isn’t actively supported.”
Each year, I work with a few teams that are basically doing the same thing: Rewriting old web apps to use React.
The old apps use ASP NET Web Forms, JSP, jQuery, Cold Fusion, Perl, etc.
Often, the requirements are simple: “Make it work like the old one.”
Internally, I’ve heard various of our Software Developers complain about “Technical Debt” (or the perceived amount of it); which was the excuse for slowly getting features out, or an excuse for introducing more bugs as we fixed other bugs. Common excuses like “this code is messy and hard to read or change”, “there’s a lack of tests so if I change it, some requirement may break which I didn’t know about”. The “old tech” was often criticised for contributing to a slow deployment process. We did lose a few developers who wanted to go work on modern web technology using Cloud and other buzzwords.
So for a company with previous experience making a market-leading software product, and with a large team of passionate developers who think they know what great code looks like; it should be pretty easy to deliver, right?
Failure Reasons
Reason 1: Skills in the wrong areas
SystemNow was C# front end and SQL Server backend. The vision for ProjectFutures was that it would be React (Javascript) frontend, then using various Cloud aspects (Lamdas, API, DynamoDB). Some developers have the capacity to learn quickly and could instantly claim they are a Senior in the new language. However, most people basically go from a Senior in C# to Junior in React. If most people are Junior, then you end up writing code that is full of technical debt and so you cause the exact same problem you criticised the old SystemNow code for. (I think this was proven by the restarting or cancelling projects as explained later).
As a similar point, we also hired people too quickly. We have severely reduced hiring people in the UK and gone for hiring in India. Aside from some being poor communicators (and then having Indian English grammar and phrases which people have to get used to; (ie “do the needful”, “preponing meetings”); being Indian isn’t inherently bad. The problem is that as a business we have wanted to hire large amounts at once; which then leads to an “accept all” type of hiring. In addition to wanting to pay low wages as well; you end up attracting people that can’t get a job elsewhere. So you end up getting loads of Junior developers all starting at once, some with no experience of making software at all, and some only having basic understanding in a programming language we aren’t even using e.g. Python. There were some good hires but I think it would be better just to go with far fewer staff but higher quality engineers that can really drive the decision making.
Reason 2: The Cloud
The current way of working is that the developers created software, then gave the build to the Deployment team to release. The clear separation means you can specialise your knowledge.
This mindset to move to “the cloud” means that now the Developers have to have more understanding how their code is actually deployed.
Historically, over time, specialist “Frontend” developers and specialist “Backend” developers were replaced with more generalist “Full Stack” Developers. Now you are throwing servers and deployment processes into the mix (DevOps), so now it’s like “Full Stack plus DevOps”.
Due to this, you spend more time learning, more time investigating, and giving worse output because you don’t specialise in it.
The world of cloud computing is full of buzzwords, especially if you use multiple providers (Azure vs AWS naming is completely different). This is extremely daunting and gives you a massive list of things to learn before you can even begin to communicate with people.
No idea where I stole this from, but I think it sums up the attitude that managers had:
The company’s technical leadership thrives on keeping tabs on the rapidly growing technology industry and new innovations built on top of fully-managed services provided by cloud providers. Like many other technical leaders, they are keen on learning new buzzwords and leaving it up to their developers to do something useful with them. The hottest trend these days seems to be ‘serverless’. The promise of consumption-based pricing, where you only pay for what you use and nothing more, is enticing. Furthermore, they have heard many good things about how serverless platforms help you prototype and develop faster by reducing the amount of code and configuration required by more traditional web platforms. The cherry on top is the fact that serverless platforms also tend to manage scaling resources to meet demand automatically, giving them dreams of releasing a wildly popular new ride share app and enjoying near-instantaneous customer growth.
We were a massive company and had our own Data Centres. I think Cloud is vastly beneficial to small companies who cannot invest in the up-front cost of their own server room, but also can easily scale up if demand drastically increases. We already had the resources for large demand but then moved to the Cloud just for the sake. I think managers were so obsessed with this “serverless” buzzword that they demanded it was the focus, rather than designing a solution with an open-mind, and using what was necessary to achieve the objective.
Reason 3: Fail Fast, the problematic developer, and working on tools/process
When we begun development on ProjectFutures, managers kept on telling us that a “culture of innovation” means “there is no such thing as failure”: You can try new things and as long as you feel like you have learnt, then it’s not a bad thing because failure then leads to you doing the correct thing.
This flexibility of being able to choose our tools/approach was taken a bit too literally, or extremely. So you had multiple teams investigating the same ideas. You also had teams successfully implementing something, then rewriting it using something else just to compare.
There was one problematic Principal Developer that they hired called Liam who seemed to have massive influence. Liam always persuaded people to investigate a different tool to what we were currently using. Then once people had made progress, he would then recommend something else. He wasted so much time. He’d end up arguing his case using some strange analogies too.
They are the same as chocolate bar wrappers. You need it for the delivery of chocolate, but once used, you get rid, otherwise it’s just messy 😉
Also I see a load of chocolate bar wrappers on a desk and I instantly check them all for chocolate.. Friends don’t let friends do this.
He’d often cause conflict, switch teams, then repeat his behaviour of changing all the tools and processes, then moving on once more. Instead of just cracking on and actually writing the software, we wasted months, even years switching between different tools which then got abandoned.
“these guys makes me wonder if I can even call myself a developer if I just don’t care about processes and tooling. To me right, I consider us to be like master carpenters building beautiful cabinets. And these guys are having a massive debate about the lockup out the back where we keep the wood. Another problem is people just getting excited over every different bit of tech
grunt
WTF IS GRUNT?????????
gulp too
I’m sure some of these are being made up just to piss me off. I bet a lot of people can’t even remember how to code any more. All they can do now is manage Nuget packages”
Dean (Senior Developer)
I’m sure most developers wouldn’t actually care how their code is deployed. Just that it is deployed and is easy to sort when things go awry. Most teams were using GitHub Actions, but Liam demanded teams he worked with switch to Jenkins, and even convinced many managers that this should eventually be pushed out to all teams. However, as teams began to switch over, managers realised that Jenkin’s self-hosted nature was costly in resources, and comes with even more overhead of actually maintaining its use. So then they had a change of plan.
“The current Jenkins solution is estimated to cost $2,126.83 a month just in AWS resources.”
“(By not using Jenkins) we can become a leaner outfit that can deliver value to the business quicker by focusing on our own strengths which is delivering software, not CI/CD software”
After exploring different options, they realised that GitHub Actions made the most sense to use after all because our code is in GitHub so there’s no cross-account security issues to worry about, and we already had some free-build minutes in our subscription.
“So far we’ve been told to do ADO -> AWS CodePipeline -> Jenkins -> ADO. So we’re excited to try Github Actions next!” – Lead Developer
A month later, the manager who announced we should be using GitHub Actions then said his team had been exploring using Netlify for his next project. Facepalm.
When the problematic Developer Liam eventually did quit the business (or we think forced out), one manager seemed hell-bent on undoing everything he implemented. Another idea that Liam had was a Tech Radar. It was basically a decision log of sorts, listing all the software/tools we have tried, the pros and cons and why they were chosen/declined. If other teams looked at it and maintained it, then it should mean they don’t waste time exploring using tools that had already had a decision made.This was also binned off due to:
“The Tech Radar required a significant amount more administration and the rules around reviewing were not sustainable, we were not able to commit to the reviews when it was in full flow.”
Reason 4: Using other tools are expensive
If you asked me to come up with a plan to remake SystemNow, or similar existing large-scale complex software, I would try to limit the initial scope by reusing as much of it as possible. So you could just create a new user interface, but when it comes to saving the data, you could still call your current/old servers. So we could have replaced the UI to be a website using React, but still use our existing C# server code and still keep the SQL Server database.
I’d also look to basically outsource part of it too. If there is a company that specialises in something, it makes sense to pay them to do it, rather than making an inferior version yourself, and having the overhead of maintaining it.
You can always decide to implement these yourself later if you have no other projects to do.
If you try to replace the entire system yourself, it will extend the timescales further and you run the risk of failing to deliver at all.
To me, authentication is an ideal candidate for this. Originally we used Okta, but then a few months later, a Software Architect decided to create a project to make our own authentication. So that’s several developers spending months of their time making their own security solution, and none of them are security experts. What can go wrong?
The reason I heard for this quick switch is that Okta was far too expensive. It was projected to cost around £15k per month to use. This sounds mad. However, when I mentioned this to one of our Architects, he said “that equates to around 1p per user per month”. I suppose when you look at it like that, then it does sound cheap.
I don’t know how much we have truly saved when we have to pay several developers for the length of time it took to build the solution. It’s not that simple though because you have to then hope that it works, and hope we never get fined for any security issue. Also there is the “opportunity cost” that they could have been working on some actual functionality and not just allowing the user to log-in. Surely it wasn’t a priority at that moment because we had Okta working and only Developers were using it to log in as we developed.
UI Suite
Another thing we made in-house was the “UI Suite”. So this refers to the basic components like text boxes, combo boxes, buttons, icons, and the styling. Now, what is the cost of using a third-party library? Well most of them are free, and it took YEARS for us to create something decent. Every time I heard about a basic bug we introduced; I was just facepalming since we wouldn’t have had any problems if we just used MaterialUI.
As the UI Suite was being built, teams were reluctant to use it because it barely had any components. It really needed to be feature-complete by the time any teams actually started their projects. When components did exist, the bugs slowed down all development teams which caused some teams to use something else as a stop-gap. But without many teams using it, then that stifles adoption by other teams. Whose idea was the “UI Suite” anyway? Yeah it was Liam’s again!
Within a few days of me using it, I reported that the combo box did not allow you to select an item, and the text box didn’t allow you to change text programmatically. Another team reported that the Table component didn’t display unless you manually called the Resize method as a workaround. The Table also was a fixed size due to a hardcoded value. Then, once that was fixed, the column headers were not resizing correctly. Another team reported that the List component’s itemSelected property didn’t work when set programmatically.
To me, it’s inexcusable that a combo box won’t allow you to select an item. With severe bugs like that, it just slows down your development. Then it’s the opportunity cost that the team could be assigned to a meaningful project, and we could have been using a popular UX library like Material UI that we know works.
On a Development Department Meeting, one angry developer asked:
“Is having a UI Suite team a pragmatic allocation of an entire team’s knowledge and resources?”
This question then triggered a 30 min meeting the following week to try to justify why the UI Suite was important. It was full of blagging from the manager because no one really could think it was a good idea. In my opinion; if you have to create a presentation after 3 years into a project to convince people it is a good idea – it probably isn’t a good idea. He acknowledged there was “growing concern” across the department that people “didn’t think it was a productive use of our developers and there are already ready-made solutions available”.
I’m not even sure the team that was making it believed they could actually complete it. 2 members had left which meant they were down to: an experienced Developer, another Developer who had spent most of his career in UX design (drawing not coding), and a Junior Developer who had just began her year off for maternity leave. Then they had a Product Owner, Technical Manager, then a Manager overseeing it which is inflating the costs and bureaucracy.
His main slides stated the following:
Why UI Suite? Why not? We're not all the same. • There are several design systems out there already such as Bootstrap and Material - They all have their pros and cons • Someone else's idea of a design system may not always work for us; having our system gives us the flexibility to define our own style • Creative freedom to ensure our products stand-out from the rest, and are easy to use • Large organisations such as the NHS, Government, Atlassian and Uber have their own design systems because it is right for them.
“is that right for us? eeeeerm…………………..”
manager struggling to blag
My View: I think he is blagging justifications. MaterialUI has been around for years and you can apply your own theme so I don’t understand this “design system” nonsense. You could also make tweaks to it because it is open source so could deviate if there’s some things you don’t like.
He then implied they were having a reboot of sorts and changing direction, but I’m not sure what that entailed. But if the UI kit isn’t ready, then how can people develop their apps effectively?
As more teams used it, the backlog of requests grew, and other teams were asked to fix bugs themselves. The claim was that the project was always intended to be “open inner source” and all teams needed to contribute. In September 2024, the UI Suite team disbanded and now every single new feature or bug fix needs to be implemented by teams that desire it (or you could just abandon it and use Material UI). The messaging from the managers was that it was a ”lack of shared ownership” why UI Suite failed in its current form.
“This change is made with the best intentions… It’s also just the start of a journey. As we learn and identify challenges, we will adapt and improve the approach.”
More recently, I did notice that some of the components were now simple tweaks of another 3rd party UI library so I think they had binned off their original implementations in their last reboot. Now they are on a second reboot. “ It’s also just the start of a journey” What a waste of 5-6 years.
Reason 5: Deprecating unreleased functionality
Due to the idea of “microservices”, people went wild creating repositories for everything. It does make sense to have general shared functionality like “logging” for error logging which everyone can use. Some of the projects ended up consisting of multiple repositories because they took the idea too extreme. With the sheer volume of repositories under our organisation, it became difficult to see what was actually useful. Just like the UI Suite, we had rebooted projects multiple times so then there were a few repositories for “logging”. You’d see similar names like “logging-sdk”, “logging-sdk-typescript”, “logger”, “monitoring”. Did one replace the other? Are they for different scenarios? Are they poorly named?
Occasionally, someone would announce something like the following and you do wonder who was using it and why no one had deleted it earlier:
“Hello, the client-logging package exists within the logging-sdk-typescript. It hasn’t been updated in almost two years, and more importantly it offers no functionality to store logs so it’s not fit for purpose. This client-logging package was meant as a proof of concept. We have no more need of it and all it offers is a false sense of security, so we will be deleting this package at the end of the month”
Intermission: Q4 2021 – Q2 2022 – Hyping Up Basic Features: Powered By ProjectFutures (and the framework reboot)
“This week we activated <new feature> which is a new web based application, powered by ProjectFutures cloud technology, and integrated into SystemNow.”
“Powered by ProjectFutures” sounds like some jargon to sell to customers, but was repeated by the managers internally. It was like we were gaslit by what our current progress was. There was nothing noteworthy at this point. I got sick of hearing it and we all knew it didn’t mean anything. Even when they didn’t use that phrase, it was just the usual corporate buzzwords and pretentious tech jargon:
“The teams working in this Application Composition Platform space are doing some amazing, innovative work focused on future technology that will allow us to respond rapidly to a changing market. Keep coming back to see how this develops and please ask any questions you might have.”
Check out this guff:
“I’ve worked here for nearly 20 years and have played a part in, or witnessed, a number of momentous achievements during that time. I’ve seen us adapt to a constantly changing market, grow as a business and continuously offer new and exciting challenges for our people. However, we have often struggled to move at the pace our users demand and this becomes more of a competitive challenge as new players move into the market. We have to continue evolving and never allow ourselves to become complacent about our position in the market.
Technology is a major enabler in allowing us to achieve business agility, giving us the ability to rapidly respond to market changes and user demand. We have recently taken an important step forward in using modern tech to our advantage with the first release of the Application Composition Platform (ACP), powered by ProjectFutures.
The ACP is a suite of technology enablers that allow us to rapidly build high quality cloud hosted web applications in a consistent design system. It is essentially a lego kit that gives Product, UX and Development the tools to quickly go from idea to design to implementation and then getting it into our users’ hands. It allows us to provide apps that are standalone or integrated/embedded within our existing product suite
Our first release provides a simple view of the SystemNow news feed in a standalone web app. This has been released to two sites so far and the rollout will continue once we've had a bit of feedback. Although this feature isn’t ground breaking, it allows us to prove the technology and confidently move forward with rapid app development. There are a number of dependencies to overcome, so that apps created in the ACP can easily access data through consistent APIs and this work is going on alongside development of the ACP.
This is the beginning of a journey to modernise our technology stack and take us to the next level of business agility. I will be providing further details this month on the next plans for the ACP during Q4 and into 2022. I have an incredibly talented team working in the app development space and I’m excited about what we can achieve.
So what does all this jargon mean?
When I worked on ProjectFutures during 2019, I was working on what we called the Application Shell. It seemed that this was rebooted and renamed the Application Composition Platform (ACP), (powered by ProjectFutures, of course). All it was back then was basically a Home Page with some “Context” so it could access the User Token to see what modules the user was allowed to access, and would populate the menu with the apps they could use. So a simple explanation was: it was just the basic framework to embed other applications in.
The original idea was ProjectFutures was a separate application that only really would be used once all the major modules were available (what we were calling “the Big Bang”; one day the user would just completely switch over and stop using SystemNow). Now the plan is that ProjectFutures is a “Companion” app, so will run alongside SystemNow. We also have the option of embedding it inside SystemNow. Therefore if we actually make an amazing module, we can replace SystemNow’s version. So now it’s a gradual phasing out.
Note: In the intro, I said the core modules should be out by 2023 . At this point they have quickly pushed out an RSS news feed by January 2022.
Dean Did they scrap your framework and do it again?
Me: I think they scrapped everything we did. We called it Application Shell
Dean: If you put it to your ear you can hear the distant sounds of developers crying.
In Summer 2022, our CEO was hyping up ProjectFutures to our customers. She was really fixated on the concepts of Cloud, and that it’s not a “big bang” approach. So she announced there is no longer a brand new product, we will now just migrate the existing product “module by module”. The phrase “Powered By ProjectFutures” was going strong. It’s still just a meaningless buzzword because the “technology” is just AWS. We haven’t got any innovative proprietary technology at all, but we just have to pretend. We do have the RSS feed though.
“We’ve got an interesting and enjoyable journey with ProjectFutures which has evolved over the last 2-3 years. The Key to ProjectFutures strategy is moving systems into the cloud but we will avoid disruption by doing things in a gradual way.”
Our CEO made an announcement which was available to view on YouTube. The gist was that COVID had created an extra demand on certain services which required companies to increase innovation in technology and processes. This change had to happen rapidly. This is evidence that software changes in today’s world need to happen faster. So actual development time needs to come down, but also delivery time to get the change to the end user.
“Companies had seen time scales that would have previously been thought impossible”
Most of it was nonsense, like she claimed we had evolved our existing software to use ProjectFutures’s “Cloud Infrastructure”.
“So now we are “using the latest, trusted secure technology… we are building new modular components powered by ProjectFutures to enhance existing applications in the cloud that can support improved performance and enhancements….our development to release cycle is reduced so we can bring innovation to our customers faster. We no longer need to have a big bang approach. Instead we can build cloud modules that will interface with our existing systems and also with other supplier systems using industry standards retaining the familiar look and feel and the workflows for our users but at the same time being able to deliver additional functionality without impacting performance. We can reduce the impact of change on our customers releasing enhancements in an incremental way rather than building the entire new systems”
After that, customers will surely expect the Companion (ACP) to be populated with features pretty consistently, right? I mean, we are bringing innovation to our customers faster, and delivering in an incremental way.
Q4 – 2022
The Internationalisation project for SystemNow was a massive one, lasting a couple of years. They had already assigned more people to it, putting on hold other projects for it. Then around October, they had temporarily assigned developers to do code reviews and help out on various tasks to get it complete. However, a few months later, it was announced to be scrapped.
Instead ProjectFutures was the focus, and would initially target England only. Then the focus will be then on Internationalisation once more, but they would get ProjectFutures instead.
Since SystemNow was the system bringing in money for the company, I imagine cancelling the contract was a massive loss. Surely there are financial penalties for the cancellation, then the loss of any future sales in other regions, then it was costly in terms of the number of developers working across all those years. They have really put faith in ProjectFutures bringing in the money years down the line.
Reason 6: The Big Restart: X2
In addition to the cancellation of the Internationalisation Project, there was some shuffling around with managers and teams which was announced in a Development Department meeting. You’d think managers would be sacked rather than moved around because surely only having a News Feed after 4 years is a shambles.
I do wonder if managers just blag each other. On the Department meeting, the newly promoted ProjectFutures director said “subsequent difficult market challenges that have led to attrition globally, this has led to delays in delivering the solution”. What is he on about? ProjectFutures hasn’t been impacted by any outside influences at all.
He then explained a new plan. It sounded like all work so far would be rebooted under a new internal moniker “ProjectFutures2”.
On the roadmap, launching straight away is a ProjectFutures product which is actually from a company we bought out last year, but we are slapping our branding on it so we can say it is Powered by ProjectFutures. Then there will be 3 small features embedded into SystemNow which are also Powered by ProjectFutures.
In 2023, we will have 4 more inside SystemNow, as well as one that will actually run in the ProjectFutures framework alongside the News Feed; Instant Messaging.
In 2024, 3 massive core features will be delivered as well as some secondary modules.
By the end of 2025 we will have the remaining modules completed. So the start of 2026 will have the full system launch for new customers.
Why will we succeed this time? - Commercial driver to get it done - Resourcing appropriately - Focus on successful onboarding - Well defined roadmap and features - User research and design - Mature technology choices - Strong architecture input - Proven approach with ACP and Companion
He said that with the extra Developers from the Internationalisation project plus a few new hires, there will be 134 people assigned to ProjectFutures.
“We also continued to work on our core UI capability which gives teams a consistent, modern suite of components built in React. These form the lego blocks of every app we’ve developed, and the integration between our UX designers and the team who looks after UI has been phenomenal” (as previously described, this “phenomenal” team disbanded in September 2024).
Reason 7: LATENCY IS NOT A PROBLEM Q3 2023
The original plan was that ProjectFutures would have its own data storage, but the obvious problem is “how do we get users to switch over to the new system?” There will be a period of time when they have to run them side-by-side in a training period and data needs to be available in both.
Since we then had the philosophy of being able to migrate modules independently, we really needed ProjectFutures to write into the SystemNow database.
I don’t understand the complexities involved, because using the same database sounds like a simple solution. However, the Database Experts then came up with the idea that ProjectFutures will write to the Primary database, but then that data is then copied to a read-only duplicate called a “Secondary”.
When teams were developing and testing on internal development environments; it all seemed to work fine. They would update data and see it reflected straight away in the User Interface. However, when they tried it on a demo site, they found that the data didn’t update until you manually refreshed it. What was happening is that after the update (which goes into the Primary database), ProjectFutures was then requesting the new data from the readable Secondary database, but it hadn’t synced with the Primary database yet; so then retrieved the old data.
So the solution was to make sure that every page had a refresh button and the user had to click refresh after they saved any data. It should be available a second later, so there shouldn’t be the need to keep refreshing the same page.
What makes this situation funny is that ProjectFutures is supposed to be an improvement in every way, and not having the current data when the user has just changed it locally is a massive step backwards. Another reason it’s funny is that I was asking a Software Architect about this “readable Secondary” idea when they announced it because it sounded problematic to me. He said he was arguing with the other Architects about it because the latency would be an issue, and he was repeatedly told that the delay is only a few milliseconds and so wouldn’t be a problem.
Missing features and various quirks just keep adding up to make the new modules inferior to the current solutions.
Reason 8: Not prioritising the right projects
Due to the restarts, it means the basic prerequisites aren’t there ahead of time, so you end up needing teams to do work almost in parallel.
One significant module was released by August 2023. In the internal announcement, the Development Director said that 11 teams were involved, alongside auxiliary staff in UX, Product and Architecture. Changes were needed in the Users API, SystemNow, Tracking API, Person API, Product API, Documents API, ACP, and UI Suite.
The way I see it, the ACP changes should already be complete, and be linked with a working Users and Person API. The UI Suite controls should be available and working. The Tracking (monitoring and auditing) is another fundamental module that should already be available.
Due to delays, restarts, and prioritising modules that aren’t important, you then get chaotic development to deliver one module. Hopefully now that the work is done, then other modules should be able to be delivered without as many changes to other aspects.
We’d barely got a few modules out before managers were then talking about planning brand new functionality. A couple of teams had been assigned to research how AI could be used in our products. Speech to text is cool, right? How about predicting what tasks you need to complete next and drafting them out?
Why would we be working on brand new features rather than converting all the existing modules over? Because “AI” is the cool buzzword.
Isn’t it just “shiny object syndrome” again? “oooh Jenkins let’s use that”
Reason 9: The Load Q1 2024
One reason why SystemNow is criticised is the poor performance seen by many customers. There can be various reasons for this. Sometimes it is caused by any change that causes more server calls, and it’s quite noticeable when it happens.
Rather than architecting the Project Futures “Companion” to share data with SystemNow, Companion performs its own server calls. So if you log into SystemNow and select to view a User’s record, it makes a server call to get the data. The Companion then makes its own call to the server to get the same data so now the apps are in sync. If we enable the Companion to all users in England, then this is essentially going to essentially double the server load in most cases.
In 2022, the Companion was released with an RSS feed, but this was just to a few pilot users. Then Instant Messaging followed much later. At the start of 2024, the decision was made to release it nationally to all customers in England at once. There were a few other modules available, albeit in Read-Only mode.
“ProjectFutures is behaving extremely well, however, there is an incident currently opened against Identity Service in SystemNow as it isn’t handling the load from all the sites.”
Who would have predicted that?
It wasn’t the first issue like that.
As an aside, someone shared the AWS bill. It was $20k a day! Imagine the cost when everything goes live. There are modules that are finished but not enabled. Or are enabled but in Read-Only mode. When there’s more requests and more users, then that price is gonna jump significantly.
We hyped up the functionality to say that if you have two monitors, you can have SystemNow on one screen and the Companion on another screen to view information as you are working in SystemNow. What was even more amazing is that you can copy and paste information across! Wow!
“This is a hugely valuable milestone for the business – our customers love this new tech, this is what will allow us to retain our existing customers and go out to win new business across the UK. The Companion App is the proving ground for ProjectFutures2”
Reason 10: Cumbersome development set up
“for anyone wondering why ProjectFutures itself seems slow, this is our integration environment. It’s lightning fast in Production. Just thought I’d add that – can’t help being protective over it.” – Development Manager
Why don’t we get a good test system? Isn’t it costly to slow our developers and testers down?
I get frustrated that we have authentication enabled on our environments too. When I’m developing, I don’t want to constantly log in. I don’t want to get logged out if I leave it for a few minutes either.
Also, instead of having a set-up where we can run changes in isolation, we end up running most of our changes on a shared environment. Some weeks it has been a daily occurrence that the environment is broken in some way. You can’t log in. You can log in, but cannot select a customer. You can select a customer but the module won’t load.
We are constantly hindering ourselves.
Conclusion
In “The Big Restart” the Development Manager said: “the start of 2026 will have the full system launch for new customers”.
It’s now Q2 2026, and there hasn’t been much progress. There’s still a few modules Read-Only, and some that I heard are finished but were never released. Maybe they will be released. Maybe they will be scrapped. Time will tell.
There are many reasons that are related and tie into each other. I think they can be summarised by the following:
Skills in the wrong areas: too many juniors, not enough experts to drive decision making.
Wanting to use certain technology ie Cloud, AI, rather than choosing technology based on the requirements.
Developers taking the idea of “fail fast” too extreme. Spending time on tooling rather than making features.
Reinventing the wheel: not using out of the box features like Authentication, UI controls.
Restarting projects.
No manager accountability, so they can make mistakes and carry on making them.
Changing fundamental ideas of architecture: big bang vs incremental. Performance issues: latency, plus high server load.
Not prioritising the right projects, prerequisites blocking other projects, core modules not delivered to customers.
Cumbersome development set up so development of any feature is slower than it should be.
There was a time where our software was becoming infamous for being slow. Some managers wanted to actively attempt to address user’s concerns. Some changes were made; some with improvements to all users, and some that were situational – such as only affecting calls when the returned data was large.
Soon, managers were boasting about a graph they put together which showed the number of complaints made from users containing the word “slow”; it generally showed a negative trend.
I wasn’t sure I understood the graph too well. How many users call Support multiple times for the same complaint? because if you have complained about it, then you might not call back. So that means; after a week, all the complaints might have already come in so you expect a drop off.
So if no fixes were produced, I would expect a downward trend because everyone that was willing to complain about it will have done so.
There were some spikes in the graph, but managers did not explain the increases.
There have been times where figures have been manipulated like the times where we would log new bug tickets rather than re-open the closed one we knew had been incorrectly closed. There was even a time where bugs were closed then re-logged just to restart the SLA (Service Level Agreement) timer.
It would be funny if Support were told they would be monitored on the word “slow“, so they logged all new complaints under “not fast“.
“In other news, cases mentioning “snail’s pace” or “never loads” have risen by 300%”.
I’m going through some old twitter bookmarks again and found this gem from Troy Hunt. He has printer problems then has to go through some awful “user experience” with the Epson diagnostic program which seems a bit of a wind-up.
It features such delights as
“Is the printer turned on?” with the button “Ok”.
“Problems are found. Fix them.” with the button “Ok”.
The level of absolute absurdity with @EpsonAust's printer software is… let me just show you:
I’ve compiled a list of feedback from customers/external stakeholders. These were either from internal emails that were forwarded on, information from Support, or public posts on various social media platforms.
ACME is completely closing down. I advised to re-start ACME.
Customers often refer to our software as ACME when that’s our company name. It always sounds bizarre to us, and can sound like a completely different meaning. “ACME is closing down”“you heard it here first . we’re shutting shop”
The group’s first software, named ‘ACME’, had a character based user interface and was developed from 1990, with full commercial roll-out taking place in 1993.
Even the newspapers used the wrong name. No software was released simply under the company name without any subtitle
We have been speaking to our insurance company about the potential of a serious issue happening and they have advised us to keep them informed of any action or non-action from ACME in getting this resolved. “I can’t stress enough the risk associated with the poor performance of the ACME system as it currently stands, and saying that it’s being looked at and is with development is not acceptable. This has been with ACME for months now, and it remains unresolved. The issue needs to be a priority, and we need to have assurances that it will improve ASAP and not within a few months.”
Sometimes I have felt we have wrongly prioritised issues and it’s easy to understand how some users will be fed up if they perceive their issues haven’t been fixed promptly. Getting an insurer involved sounds like a serious escalation!
One of our employees, and it only does seem to be the one,(this has been going on for about a year now) when he is working his way through his tasklist, the blue link disappears and his task prints out. To make the link come back we have to go out of workflow into another section within ACME then back into workflow and the blue link re-appears. He is refusing to do any tasks at all now because it is taking him forever just to complete one. Is anyone else having this problem? What can be done to resolve this? We have tried a new smartcard, new keyboard, new computer, our local IT department have signed on and checked he has all the correct software and they can’t see any problems – it has to be an ACME problem
Occasionally, there can be obscure issues just affecting a small number of users. It’s always a pain trying to diagnose given limited people have seen the issue and might not be able to recreate on demand. I thought it was funny how the user is refusing to work, and how they replaced all hardware, even the keyboard!
I’ve had a customer ticket that became about 4 or 5 different ones and it still hasn’t been resolved – the workaround is a bit of a hoot as well. The 1st ticket is 9 years and counting, but I actually think it’s been in ACMEPro since conception… The mobile number displays in the work number field (and vise-versa) when printing ‘Full Export with Attachments’ and ‘Full Summary with Attachments’ WorkaroundBefore printing a full summary with attachments, change the order in which the telephone numbers are showing in the customer registration details.
This is a good example of a bug that would be so easy to fix but for whatever reason has been deprioritised, much to everyone’s frustration. Then some people are happy to use a stupid workaround of swapping the data before printing, then presumably swapping it back after.
“i get the wheel of mindfulness when it’s trying to locate me. i like the look of it though. currently a long way short of minimal viable product. ”
Users like coming up with creating names for a loading wheel. “Wheel of mindfulness” is a good one. I like how they claim the new feature looks good but way short of actually being usable.
“whose design? A moron’s?”
I’ve lost the exact quote but a customer once said this when they asked why a screen had been completely replaced. We had said it had been redesigned with new functionality and ease of use.
This time our approach was a little different as we decided to employ Guerrilla research in order to understand our users’ experiences. Despite the name, I can assure you that no animals (or users for that matter) were harmed during the research!
This one wasn’t from a customer but a colleague doing user research. I think they have convinced themselves that Gorilla is spelt Guerrilla and they made themselves look like a total idiot.
Another day, another crashed computer…wasting so much valuable time I have customers waiting and I’m running out of patience…
Some users claim to see crashes every day. I understand their frustration, if true.
“when it does work, it is actually amazing”.
This is similar to the “looks good” one. It’s like they know the feature is bad but want to say something good because we have asked them for feedback.
My list – some concerns are more serious … others just glitches that frustrate on a daily basis Maybe we can do the job of the people who are meant to be testing the systemACME Glitches1) Every letter that’s sent from word via email is sent as “new letter 1” – no system to track / individualise – UNSAFE2) When completing tasks, I cannot send electronically unless I go into the summary screen and send from there instead. Doesn’t happen all the time so clearly a glitch.3) Dancing word document – screen adjustment – every time you create a new word document.4) Tasks ribbon across middle – never accurate. does not refresh unless in the workflow (so what’s the point as I’m already in workflow!!)5) Task ribbon across middle – Doesn’t show what tasks for me or for others6) No functioning alert system – enough said (similar with template manager)7) Non-functioning messaging system. Will need to removed OR replaced with something that works8) In a task. you can select a cluster of text (ie using ctrl+shift in reverse (Ctrl+shift + <) but you can’t do it with ctrl+shift+>.9) Why does ACME forget my pin. frequently in the midst of digitally signing? An error box appears saying “pin incorrect” and I have to log off and back in to “re-connect”10) how many people have their details in this format “AHMED, Kamran (Mr)” – yet this is the chosen format of ACME when adding macro to letters11) calendar does not highlight bank holidays / public holidays on appointments screen12) Open any template – cursor never in the only box you’re going to type in to.. same for customer search function etc. if there is a box to type in – why nothave the cursor there on opening that search function?13) not able to order searches by clicking on the field bar – MS Excel and pretty much every other search function allows thisit works in some parts of ACME and not other… why!14) Appointment book refresh. i reported this myself 4 years ago and i was pacified. Then ACME brought out a “fix” – Keep clicking refresh!.Now its failing all over again15) ID number – the current “search” tab does not allow you to enter an ID number with spaces.YET when you “copy ID number” from selected bar you cannot paste that back into ACME’s own “search” tool because it has spaces. Therefore ACME does not recognise its own output
A rant from social media. Sometimes I think it would be good to target certain users and actually address their complaints. Most seem like quick wins.
Instead of reinventing the wheel, Software Developers like reusing code. When using Javascript, a common place to use such code is NPM; Node Package Manager.
The recent NPM incident caused malware to be shared via many NPM packages. As far as I understood, I believe Github security tokens were stolen which allowed impersonation to check in malware and propagate to more packages.
As a precaution, we were told to cease development so you had hundreds of developers sitting idle.
We knew our teams didn’t use these packages directly but I suppose investigation was needed for transitive dependencies, and there was always the risk of packages we did use suddenly being infected, but we could just stop upgrading to new versions.
We thought it would only take a day or two, so I took the day off and would come back over the weekend to normality.
However more investigation was needed, then we had to switch over to a differentinternal NPM server with only approved packages being available.
I had no idea what the criteria is for approved packages. How do you know if something is secure other than the currently known, published security issues? Typically, bugs and fixes are added all the time.
I think there was some kind lead time before new versions were accepted. I suppose it prevents this quick publication of malware if you just have a lead time of only taking packages more than a month old.
Since we had a new NPM server, we needed to publish packages to the new one, but we weren’t allowed to use the old ones. So new versions had to be published which then means you need to update all your software, and it’s a massive chain of dependencies involving all teams in the department.
I wasn’t personally involved but it sounded horrendous to coordinate and we were delayed by around 3.5 weeks.
We weren’t even affected by malware. We have loads of sub-companies in the overall group and no real incidents between them. Hundreds of developers were idle, and it was self-inflicted.
We had a form where the user can search for certain types of businesses in the area, and it displayed the distance from your location in miles.
One day, a user was posting all kinds of angry abuse because they said the distance was wildly inaccurate.
We were using a 3rd party API that was supposed to return the distances to the businesses in KM. It seemed that at some point, without us knowing, the API had changed to return the distance in miles, and our current code was expecting KM then we had code to convert it to miles. So now it was coming in as miles but we were manipulating the value to be wrong.
My reaction was that we should just inform the 3rd party to change it back. If their documentation says it is KM then they can’t change it without informing all the providers. If we changed our code, and the 3rd Party then reverted without informing us again, then the values would be wrong again.
A manager decided to go against my advice and told a team they needed to fix it. Soon, a Junior developer contacts me to say he is doing the fix and wants me to explain the situation and be available to review the code.
It’s a simple change, and he adds some unit tests. I pointed out a few more scenarios that he could add since our code was formatting to 2 decimal places. He could add tests for 3 or more decimal places in the data, and include larger values like >10 so you have 2 values before the decimal point.
So as far as I was concerned, if we HAVE TO make a change, then this is the simplest change and he has improved the codebase with the unit tests.
I approved the changes, and 2 other Senior Developers approved too.
When it was ready to go into the Main branch, another Senior flagged some duplicate code. He was correct, but it wasn’t a big deal because it’s one line of code. To “fix” it, you would need to create a new file for one method with one line of code which seemed overkill.
Then another Senior Developer questioned why one class called a method just to delegate to another method; when it could go direct. That scenario happens a lot, especially with design patterns where you want strict degrees of responsibility so the UI shouldn’t have logic. This was a very opinionated change, but since a Senior Developer had said it, then the Junior felt like they should do it.
So after the initial simple change, and 3 developers requesting some very simple changes, he was finally ready to commit the changes. Then a Principal Developer saw the change and said it was definitely the wrong thing to do since we need to get the 3rd party to revert their change.
Several years ago, my employer was constantly talking about Net Zero/Carbon Neutral so was talking about reducing energy costs and planting trees. I think part of it is just “smoke and mirrors” as they were shutting down some data centres but then moving it to the Cloud, so the servers are still there, it’s just someone else’s problem.
The other aspect of why it’s all nonsense is how they always talk about using AI for everything but this is notorious for increasing energy usage.
I think it’s just the usual virtue-signalling propaganda.
We should all be aware that sustainability is high on our agenda! Living in an increasingly digitised world and working in the technology industry, I feel we should all be mindful of how much of an impact our digital activity has on the world we live in.
Did you know that a typical year of incoming emails adds 136 kg of emissions to a person’s carbon footprint, or the equivalent of driving 320 kms in an average car. Digital pollution is the greenhouse gases that come from building, delivering, and using digital technology. It makes up 4 per cent of the world’s global greenhouse emissions – double that of the global aviation industry – and this number is growing exponentially as our way of working and living becomes increasingly digital.
Reduce energy consumption of devices – Energy is the dominant contributor to climate change, accounting for around 60 per cent of total global greenhouse gas emissions.
Do we all shut down our laptops when not in use for long periods of time?
Should we make sure we close programs that we aren’t using?
Could we consider reducing the screen brightness?
Do we always leave devices plugged in at full charge? It might be better instead to charge for short and regular intervals as this also increases the battery life.
Reduce our use of email – As the above quote highlights emails contribute massively to digital waste.
We shared tips of how to reduce emails –
Do we need to ‘reply all’?
Do we need to send an email at all? Could internal conversations be held on Teams instead?
Could we make use of emoji reactions for internal responses?
Does the email need an attachment, or could we use a link to a shared online file instead?
We looked at ways to reduce emails in our inbox and make it easier to tidy up.
Do we have lots of emails that could be deleted? It’s possible to set filters to sort specific types of emails into folders and use auto-archiving settings to delete them at specific time intervals. This is particularly useful for our team where we have lots of automated emails which we don’t need to store for long periods of time. Creating rules to automatically delete these would make it easier for us to manage.
If emails need to be kept, could these be archived? This may be useful if they don’t need to be accessed often. Storing them elsewhere may mean less energy is used when loading Outlook and searching through emails. There are auto-archiving features to make this simple and less time consuming too.
Do we always unsubscribe from any emails we don’t need or want? The safest way to do this is to log in and adjust notification settings on your account e.g. unwanted reminders and adjusting Teams settings. When discussing this topic, it is worth reminding everyone to always be vigilant of the potential for any email to be a phishing attempt and not to risk clicking on any links from unknown senders.
Clean up old files – Data that are stored online take space on servers that require energy to be active 24/7.
“Whether it’s meeting our net zero targets, creating an inclusive working environment, or having strong and ethical governance practices – sustainability in all its forms helps drive us forward as a business and forms a key part of our strategy.”
We were encouraged to set a personal objective for the year based on Sustainability. Suggestions include:
reducing your carbon footprint (through e.g. reducing your business travel or digital footprint)
volunteering with your local community using your paid volunteering days
championing equity and inclusion in your role, ensuring accessibility is considered in any output or practice
becoming an active member of an employee-led group or the Sustainability Community of Practice’
Even the Software Development process is sustainable. Really, it’s just more corporate buzzwords and meaningless jargon.
Sustainable Software Development lifecycle
There is a comprehensive reference architecture on Confluence covering account structures, principles, application architecture, data architecture, security architecture, standards & templates, sustainability, app launch, EDA and more.
The tech strategy and architectural runway is fully documented on Confluence covering all core technology and platform services, components and enablers. It is future proofed and covers all investment case technology needs, and product roadmaps.
Environmental Sustainability is close to my heart and is a critical strategy as we work towards Carbon Net Zero by 2040.
Closing Thoughts
I think the claim to be Carbon Neutral is mostly virtue-signalling and although they might come up with some schemes to reduce carbon emissions, it will mostly just be a box-ticking exercise and can just move the problems elsewhere. So the field staff may well have electric cars, and most people work from home. But since we aren’t just heating a single office, but hundreds of homes now; then we probably are using more energy overall. Then everyone is using AI for simple communication.
I’ve stated in many blogs that our head office is near a city with a large non-white population so we have a larger non-white workforce than most companies. As a Software Developer, the Development team is mostly male, but managerial positions are often held by women. I’ve never observed a need to change the natural status quo with forced diversity practices.
The “woke” movement talks about diversity and being welcoming to everyone. In practice, it is unachievable to be welcoming to literally everyone because people will naturally have different opinions and some of these can be opposing.
So a much quoted example; there can be religions that will be against homosexuality, so how can you be welcoming to both the LGBT community, and people from those religions?
I find it bizarre that you constantly get told that we need to “create safe spaces” for people, “all people are welcome”, but then at the same time there’s certain views that aren’t tolerated or frowned upon by the people that want such DEI practices. I find most people I meet claim to be left-leaning politically and they seem to have a hatred for right-leaning politicians.
It’s contradictory, but then the constant messaging and certain phrases are basically propaganda and gaslighting.
I’ve seen some people liken this behaviour to cults. Where there’s strict rules; and deviating from the opinion of the leader (and therefore the group) means you are cast out. The repetition of phrases means you are constantly aware of the belief and because you hear it so much, then you don’t question it because you just accept it as true. Anyone beginning to question things is discouraged.
There was one recent post about “Allyship” where an ally is defined:
“as someone who is not a member of a marginalised group but wants to support and take action to help others in that group’’
Then it was sold as:
“Being an ally, in both the workplace and your personal lives, broadens our understanding of all cultures and backgrounds. Removing boundaries to give way to respect and friendship creates security, a sense of belonging and allows everyone to be their authentic selves. We wholeheartedly believe in the importance of embracing and welcoming everyone and providing a place of equity and inclusion for everyone to thrive. To create a place of security and belonging”
Then the usual propaganda phrases were used
“are a safe space for individuals to express themselves”
How to be an ally Educate yourself and others. Be careful not to ask intrusive questions. Personal information is a privilege Everyone makes mistakes. Be accountable for your mistake, educate yourself to make an active change
This is quite culty isn’t it. Telling people they are wrong and need to conform to the belief. Don’t question it.
Safe Christmas
Another recent post talked about creating safe spaces for Christmas. Why would anyone feel unsafe at Christmas? absolute mental. We are just making up issues now.
In celebration of Christmas, we have issued our 2nd North and South Conversation. The North and South initiative creates a safe space for colleagues in the UK and Chennai to share stories and ask questions, building a sense of knowledge and togetherness through the art of video and conversation. It is important that everyone at work feels comfortable being their authentic selves. We have a clear goal dedicated to just this: creating a supportive, inclusive environment where everybody can thrive, both doing and being their best.
Safe space, authentic selves.
Stickers
When I have walked around in my neighbourhood I have occasionally seen stickers placed on pedestrian crossings, lamposts, or electrical boxes. Some have been political in nature, but mostly have been pro-trans. I thought it was somewhat ironic when one guy posts a blog at work about “dogwhistles”.
The claim was that he had seen “negative stickers that are currently in circulation in public spaces which may cause negative and unwanted feelings in the LGBTQ+ community. “
The reasons people can do this was:
To make the kinds of people they dislike know they are unwelcome and that the place is unsafe for them.
To send a positive message to people who believe in the same thing as them, through symbols the wider public might not know. This is sometimes called a “dog whistle”, named after whistles that dogs can hear but people can’t.
To shift people from a more general form of discomfort to more extreme reactionary views.
Could a reason why there are anti-trans stickers to counter the pro-trans stickers? The constant pushing of what the correct narrative to believe will naturally create counter action; which means these “dog-whistles” are necessary to show there are people with the opposite opinion.
Are both types of stickers “dog-whistles”, or is it just the ones he doesn’t like?
The offensive stickers he had seen were “against trans women using women’s toilets”, “single sex facility – women only”, and “Protect women-only spaces”.
These are mainly feminist slogans which was a relevant political movement when I was growing up. Why is feminism not a valid thing to support now? I find it strange that the biggest allyship these days is from young women, so it’s like they are fighting against what the previous generation of women fought for.
As expected, all the comments were agreeing to conform. You cannot have diverse views on any topic in the name of diversity.
“Thank you for sharing, I didn’t know about this… sending support to those who suffer through this “
Psychological safety
One manager suddenly started going on about “psychological safety”. The usual “safe space”, “inclusive”, “authentic selves” propaganda has been used:
“We believe that fostering a supportive and secure environment is essential for our collective growth and harmony. To ensure that everyone feels comfortable, valued, and heard, we are conducting a brief survey about psychological safety in our teams.
Your honest feedback is very important to us. By sharing your thoughts, you will help us understand how we can enhance our work culture and create an even better experience for all. The survey is anonymous, and your responses will be kept confidential. Your insights are invaluable in helping us build a stronger, more inclusive team.
This week, organisations up and down the UK will be celebrating National Inclusion Week. It is an opportunity to reflect and highlight inclusivity in workplaces.
We wholeheartedly believe in the importance of embracing all cultures, welcoming everyone and providing a safe place of equity, inclusion and belonging for people to thrive.”
At work, whenever we need to log into a website, it displays a custom login screen. The text box labelled “Sign in” has the following text
“Enter user name as instructed below in GREY Box”
At the bottom, there is a grey box:
“Enter the password associated with your username”
The text box actually wants your email address but tells you to enter your username but to read the grey box. The grey box tells you to enter your password.
Stranger Coding Tings 