Bit of a rambly story, but I swear it is relevant.

So previously I worked as a consultant for a company that manufactured a relatively small number of high value (tens of thousands of dollars each) Gizmos in a lightly regulated industry - the requirements weren’t too crazy, basically that everything has a serial number and they can prove that any given serial passed the full range of tests before it left the factory. Pretty much the sort of thing you’d want to have if you gave a crap about quality products anyway.

Initially they were using Excel to keep track of this - they manufactured 10 units a week, it worked well enough. Eventually, they got more successful and needed to scale up to 50 units a week, and it was decided that they needed A System to keep track of testing and manufacturing. Their head of manufacturing “looked around and couldn’t find anything off the shelf that was suitable” (ie, cost $0, and perfectly matched his aesthetic tastes; mistake #1), so they decided to build their own system.

They had a few in house developers, but they were focused on building new features (things that drive sales, unlike maintaining their reputation for delivering reliable products), so head of manufacturing decided to get one of the production line techs (who was “good with computers” by virtue of having built the Excel system, but was not a software developer mistake #2) to do it.

Eventually, they decided to use Microsoft PowerApps to build the new system - for those with the good fortune never to have seen PowerApps, it’s essentially a “no code required” drag and drop UI tool that you script using Excel formulas. Think Visual BASIC or Scratch, but Cloudy.

On the surface this made sense - the developer was proficient in Excel, so use what you know. Unfortunately, PowerApps is designed to rapidly build throwaway UIs over simple data models and lacks some of the things that actual software developers would have thought to ask about:

• It lacks real version control - you can “undo” a deploy, but there is no way to discover what changed between versions, or do branches, or code review
• Because you can’t effectively manage changes to the system, you can’t do pre-production releases
• Its native database system doesn’t do referential integrity
• There is no straightforward way to do any kind of locking - and because there is no referential integrity, it’s really easy for concurrent users to really mess up the data
• There is no way to do automated testing
• The development group could have actually documented how stuff worked, requirements, specs etc but didn’t, so any time there was any issue you had to play the game of “is this a bug or bad design?”

Eventually, these chickens came home to roost in the form of a defect that slipped through testing that they then couldn’t isolate to a particular batch because none of their testing data could be trusted. I was brought in to try and unpick this mess and advise on a replacement system, but between the cost to fix the issue and the lost sales from it they ended up in a pretty bad spot financially and ended up being acquired by an investment group.

Anyway, the takeaway from this is that you disregard experience and judgement at your own peril, up front savings generally don’t manifest in the long term and I expect there is going to be a thriving market of consultants brought in to point and laugh at companies that decided that a bunch of cheap, inexperienced developers and a magic talking parrot would build better software than cheap, inexperienced developers being guided and upskilled by an experienced senior developer