How to fail at your software project

Instead of buying a market product for its business needs, a company may improvise itself as a software publisher and will develop its own solutions. But they quickly forget that software publisher, software developer, or software project manager are actual professions.

Sometimes, it would be a success, and they consider to take profits from this development by commercialize it or enhance it by publishing the software with an open source license. And more often in my experience, it’s just a piece of crap that nobody likes but the product owner refuses to see the reality.

The origin of these cursed software developments are, still according to my experience, always the same. Companies think their business processes are very specific to them and no market solution will answer their needs. So instead of studying some market solutions and possibly adapt their processes to match the ones modeled into the ERP, they sign a contract with a software development company and start coding.

Basically, this assessment is almost always wrong. The market softwares can cover most of their business processes, and maybe all of them. But they don’t want to change or adapt their organization and they will prefer two choices : taking a market software and bend it in every way to force it match their processes. Or developing their own solution.

Actually, that’s the moment when the company discover they don’t know how they’re working … ! So instead of writing their business processes and ensure that’s what is applied on the field, they write something that could barely be representative because they think the staff is working like this. And then, they send this to the development company with a specification similar to this one :

They don’t really know what are their business processes, they have no knowledge of software architecture and development workflows ("that’s technical things, that’s not our business", “that’s the developer responsibility, not ours”, etc), the contract with the developer has no informations regarding the workflow, the deadlines, and the potential penalties in case of failure, but they want it, fast, and cheap. What could possibly go wrong ?

Almost everything.

The result will be a non-working piece of junk, not adapted for the users, full bugs, unstable, crisis cells, unplanned costs, outages, tears and blood.

With this article, I will share you some examples I’ve seen in my career as advice explaining how to suck at your software development. Please note that I’ve almost always worked for Retail companies, so most of my examples will come from this business activity.

Ignore the Enterprise Architecture (if exists)

That’s the first typical example that comes in my mind : when you don’t know how your company is working, just continue like this.

Usually, a big company will have what we call an Enterprise Architecture definition. The purpose of this definition is to put the principles of how do the company treat its business processes into the Information Technologies system. For example in the Retail sector, the Enterprise Architecture will define which system is the master of the Suppliers data, of the Products data, of the Stocks, the Orders, etc. These systems communicate with various protocoles that are specified and normalized by the Enterprise Architecture conventions to avoid a big mess and data loss or corruption.

The example for this topic will be a software that was expected to calculate orders propositions according to various inputs : sales, stocks status, store size, etc. The application receive these data and send back a data flow proposing products to order and quantities. The stock data is usually mastered by the store back-office system, which is most of the time an ERP that handles the supply of the store, the inputs and the outputs of products from the stocks. Also, these back-office system can themselves handle the supply order proposition, because they’re also feed by the cash system of the daily sales and have the history of the stock movements. But maybe the internal feature wasn’t trusted enough, that’s sometimes a possibility. So let’s accept this idea.

So, the orders proposition calculator receives the inputs : stocks, sales, etc, OK. But, they had a good idea : this system would also recalculate the stock status for the store based on … Well, even the business process owner couldn’t explain the calculation formula. So this system updates the stocks status in the store back-office system who is supposed to be the master of this data. As the written software is different from the specification which is itself different from the idea of the business process team, let’s be clear : the stocks recalculation were almost always wrong.

To summarize : if you want to corrupt you data integrity, just create a system that as absolutely no knowledge of its origin, recalculate according to a weird formula, and send this data to your global IT applications as if you were its master and producer.

The technical requirements are not important

When a company develop a specific software for its business needs, it will almost always ignore or give a very low priority to the technical requirements.

Every requests to the developers will be business features or bug fixes, and the improvised product owner won’t care about the technical debt. Dependencies ? Libraries ? “Bleh, that’s technical things, that’s not our problem”.

This topic example will be a software developed for the sales staff in a store that was expected to create customer orders and propose side products and so on. Basically, it’s just a NodeJS front and a Java back. But, as the product owner ignored the technical base in the product roadmap (and of course, never paid the developers to treat this point), the developers ended up to freeze their development environment with all the dependencies preinstalled and cached.

So, they were building the application with obsolete libraries (support ended in 2018 mostly when you are in 2021) and had to use workarounds to ensure they can build and deliver the new versions. The technical debt has been estimated to almost 200 days of development just to fix the various dependencies issues, security flaws, and other horrors.

And one day, their development environment crashed and could not be reconstructed, they were unable to build the application without refactoring the code.

Security is always complaining, just pretend you’ve heard them

In the continuity of the previous topic, the security is always ignored in the cursed software developments.

If the technical requirements are ignored and you enjoy to perform an archeo-compilation with a software written in Ancient hieroglyphs, you will love to ignore every security basics !

Keep some passwords hard coded or in the configuration files, keep displaying debug stack traces in a production environment, write the users and passwords in the logs when the users are login into the system, display the database password in GET requests (yes, I’ve really seen that)…

Or, as in the example I’ll take for this topic, just expose the application data with non-secured APIs.

The application is a smartphone software used for checking products informations, updating inventories and stocks, sending a resupply order, or validating that the product’s position in the linear is the expected one. Back in the origin, the specification was quite simple : a system using APIs to request data from the store back-office system and update the data if required, to compensate the fact that the back-office ERP had no mobility features. So, the client asked the publisher to create and expose the data with API. The mobility application was not supposed to store anything, just consulting and maybe caching some queries.

But, after several developments from the ERP publisher (with almost no specs, wouldn’t be fun) and the mobility application, what did we had at the end ?

Well, the ERP was exposing its API without any authentication. Nothing, just send in the payload a username known in the system and you would have your answer. “You didn’t asked for an authentication” they answered after this was discovered. Facepalm, how is it possible to hear that in 2022 (yup, that’s recent !) ? And on the other side, the business hijacked the mobility application, that wasn’t expected to store any data, to trace the store staff activity and setup their sales objectives in the application. So, the initial need has completely drifted and the application mutated to something completely different.

Don’t validate the user inputs, trust them

This one will be quick shot : the software wasn’t validating the users inputs. The only data validation was performed in the database, when the field was something else than a varchar (sometimes it happened). You can input “d” as a quantity, get a SQL error because you typed more characters than the database column could accept, and the funniest for the last one.

Here is a transcription of a discussion I had with the product owner when he didn’t agreed about the bug report I’ve sent.

– Why did you opened a bug for the date field ? It’s working well when you input a date.

– But I’ve typed : “my ass” in the date input and it has been accepted and the value is now in the database. That’s not a date, so it’s a bug.

– Why did you input this ?

– Because I’m a moron and you’re too confident about your users.

Forgot your company field of activities

I’ve kept the funniest one for the end. You can’t imagine how we laughed at the office when we heard this one (but the boss didn’t, I can’t tell why).

So, instead of buying a store management software, the company developed its own one with the usual specifications and requirement (if you’ve correctly followed this article, you’ll understand their nature). The application was mostly based on an Oracle Database and all the business processes were PL/SQL procedures.

They opened in production the first store, and to be honest, it was quite successful this time. The software worked as expected and the store staff was satisfied, just some minor bugs to fix and some missing features. So, the project was green lit for its deployment.

The second store installed, they discovered a problem. The data flows were containing informations about the first store. So, the other systems received duplicated entries without the same values for stocks status and sales. The configuration was correct but it was still throwing data regarding the first store. What’s happening ?

The store number has been hard coded into every PL/SQL procedures.

So, the deployment procedure was : duplicate the database schema, change the store number in every tables and procedures, and apply it. Yes, the business forgot they had more than one store.

That’s all for my life examples in the “how to suck at your software development” domain. There are more, but they would be redundant. Sometimes, a company developing its own software can create a very good product and get some profits from it. But in my experience, they should just don’t.