Sandcastles are models of castles, built out of sand usually by children.

This is how Oxford dictionary defines them.

In the software industry, some software might be just like sandcastles, very beautiful on the outside, but extremely fragile on the inside, built by immature engineers.

The biggest intellectual plague that might infect an engineer’s mind in the software industry is when their goals and the quality of the software they build do not align together.

Building a project just for the purpose of getting a reward, attract an investor or earning a promotion to move on to the next role leaving behind sandcastles of software that requires a complete rewrite.

I have always promoted the idea that rewards, investors, promotions, and customer appreciation are side-effects of building high quality software, not the other way around.

Because when the reward becomes the goal, an engineer might develop the mindset to work just hard enough to earn that reward, regardless what happens after – it diminishes the integrity of the software being built and the effort being spent to engineer an industrial high quality product.

In the past, I have seen these sandcastles becoming the burden of the unlucky of the newcomers to the project to maintain a fragile structure, spending days and nights trying to make sense out of its unnecessary complexity – questioning their very skills and abilities to provide value, fearing being accused of inexperience and immaturity for not being able to hold a falling structure.

Any software that does not follow a consistent pattern, is doomed to be rewritten from scratch, regardless of how long it takes those who don’t have to maintain it to realize it doesn’t serve their high goals anymore, regardless of the suffering of those beneath them who sacrifice their time and efforts to maintain the sandcastle from falling.

Sandcastle software has obvious attributes that should be visible with the naked eye regardless of the years of experience an engineer might have, so here they are:

Clone, run … FAIL!

Some of the most obvious things I have seen through the years, is that sandcastle software never runs as soon as you pull it down and try to run it.

There is always this little configuration here, or permission there that takes from days to weeks to just get you to hit the play button and start dealing with the next nightmare.

An industrial software should have the proper documentation and guidance to get a newcomer started and to save some of their time from being wasted asking around trying to figure out how to get to run the software.

Documentation is important, but more importantly the team’s willingness and proactiveness in getting a newcomer started and comfortable by giving them a tour of the software so they know how to push features and resolve issues whenever they occur.

Testing

A sandcastle software also lacks testing, and if it does have some tests, they are a mesh mash of multiple concepts and ideas, with lesser code coverage and several blind spots that gives a false notion of quality, but then again just like a sandcastles, it couldn’t be more fragile on the inside.

When it comes to sandcastle software, you will notice the following issues with the testing:

1. It might not exist at all.

2. Half-baked tests with false positives.

3. A lot of commented or disabled tests because of whatever reason an engineer could come up with that day.

4. Blind spots, where a block of code could be completely changed, and no tests would raise any warnings or issues.

5. Test complexity, unorganized hard to understand tests that require their own on-boarding session just to realize they are nothing but bloated overly optimized tests for no good reason.

6. Running the test requires an entirely different set of skills and technologies just to get a proper status.

Mishmash of Patterns

In a sandcastle software, there is no cohesion between the components of the system.

It becomes a free for all zone where everyone coming in, using their own patterns to implement a given feature – in that case a software becomes a lot like a book written in multiple languages, talking about different topics with no cohesion or story-line.

You can see this very visibly when you see multiple methods doing the same thing (mainly helper methods) written by multiple engineers.

When the software being written and maintained lacks cohesion, readability immediately suffers immensely which inevitably leads the engineers working on the project to lose the willingness to read the code, and focus more on just getting a feature implemented regardless of whether some of the code being written already exists and can be leveraged or not.

These are three very prominent aspects that I have observed over the years in sandcastle software, but they are not the only ones.

Some software is simply a reflection of the culture and communication structure the team follows – a team of isolated engineers not pairing and not communicating should eventually produce an out of sync code that has multiple redundancies and inconsistencies across the board.

I have pointed out in multiple occasions in my articles and video sessions that software development is a social activity. It requires every engineer to communicate with the rest of their teams to solve problems and agree on the road-map and the road ahead.

When these communications become exclusive to stand-ups and planning meetings the quality of the software suffers, and the success of the project becomes more and more harder to achieve.

The Scope Triangle dictates that when it comes to cost, quality, and time you can only choose two of the three, and be willing to pay the cost of the third.

For instance, if you choose giving the engineers all the time, they need to build the highest quality they can possibly produce, the time aspect of the project will be longer.

 The same thing goes with time and cost, a project with the lowest costs and fastest delivery time will result in the quality of the produced product to be very poor and almost unusable.

But these three aspects are from the perspective of the stakeholders who think quality is a negotiable term. But from an engineering standpoint, quality is actually a none-negotiable aspect of any software being built, it insults the very integrity of true industrial engineers to negotiate the level of quality they want to build their software with, it’s not an option to talk about.

Which inevitably leaves the business non-engineering crew with one or two aspects, either they choose the time and bare the costs, or choose the low costs and wait longer to get the product delivered.

But when engineers agree to negotiate on quality, this is when sandcastle software is born, and while the business is happy to have “met their quarterly goals” – the reality is that what has been delivered is worse than delivering nothing at all.

Years ago I could see the look of disappointment, confusion and shame in the eyes of the engineers delivering software they know full well that it doesn’t live up to the level of celebrations and rewards being spread around over the product they know is doomed to fail.

True integrity dictates that one shall do the right thing even if no one is looking.

Even if you have the rights to push straight to the main branch, run your deployments and call it done.

True industrial engineers have their own internal code reviewers, the voice of integrity in their hearts that calls upon them to do their very best regardless of the pressures the stakeholders may enforce thinking it will make things go faster.

Those industrial engineers are the only ones to be entrusted with the future of this industry, simply because the more we head towards the future the more critical software becomes in our daily lives.

Software today is being used in some of the most critical situations to make the best decisions to save lives or prevent dangers. and if the engineers entrusted with building that software only cared about pleasing their business owners, delivering the fastest and seeking the rewards regardless of the quality of software then the future of humanity is doomed, and a serious revision is mandatory to the principles that run the industry.

These industrial engineers are our hope for a better tomorrow, their selflessness is observed the most when they willingly choose to spend the extra hour and go the extra mile to ensure everything is in good shape.

Without these engineers the entire industry would collapse, trailing tribes of sycophants who care more about their earnings, rewards or promotions than the true value of what they do and how they do it.

Some engineers build industrial software to seek quality, and they so happen to get rewarded for it as a side-effect.

And some others build sandcastles only to seek these very rewards.