Always felt like there’s something missing when it comes to modern engineering practices? Here’s the not-too-serious but absolutely foolproof missing manual: From understanding the problem to declaring success in eleven (not so) easy steps.

Solving Business Problems

If you’re reading this page and didn’t stumble across it by accident (feel free to stay anyways) then chances are that you have a business problem that needs a solution. Rapidly. Ideally, the day before yesterday. The. Latest.

Moreover, you probably consider yourself a problem solver, in general. And modern technology tends to be your tool of choice for solving problems. Including business problems.

By now, you’ve also read up on why sellotaping things together is apparently the way forward for modern software engineering practices as it unlocks rapid delivery by leveraging reuse as much as possible.

But you’re still unsure about how to put it into practice? How to get from descriptive to prescriptive? How to build software for the modern era.

Right. Let’s get to it! Let’s start building!

Or maybe not so fast.

Focusing on What Really Matters

While it’s nice to build things as an architect or an engineer, it’s important to remember what really matters. In most cases, it’s not the process of building itself but rather the end result. The product that solves the original business problem. And makes money. Remember, it’s a business after all.

Right. You’re all up for rapid delivery by leveraging reuse as much as possible but then the professional oppositionists will quickly counter with long time favourite classics such as

1. We can’t trust any foreign code!
2. We traditionally build everything ourselves!
3. We have very bespoke use cases that are unsuitable for reuse!

Now, hang on a minute. That to me, raises the following questions

1. Did you inspect and vet every single line of code of every system you’re using? Both on-premise and as SaaS solutions…?! — You must be busy!
2. Did you also build your own computers, hard drives, keyboards, appliances, offices, chairs, windows…?! — You must be very busy, indeed!
3. How special are your bespoke uses cases really? How much can be broken down into standard procedures that actually only require a very limited amount of bespoke specialisations (pun intended).

Note that the last point really unlocks the reuse of readily available products. Here, the trick is to work around the existing inherent limitations and only focus on the bespoke specialisations. While convincing the product owners to remove the limitations at the same time.

Also, there’s nothing stopping you from trying to integrate your bespoke specialisations into the readily available products and potentially make them better for everyone. After all, your bespoke use cases might actually be more common than you think!

Over time, you may as well find yourself in a situation where you’ve bridged the gaps from both sides. All initially existing inherent limitations were removed and your bespoke specialisations are by now part of the underlying products.

Congratulations! At this point, you’ve not only overcome but truly mastered the Maintenance Fallacy!

Overcoming the Maintenance Fallacy

The problem with building things in general is that

Whatever you’re building — you’re building maintenance right into it. And inevitably legacy, if you can’t keep maintaining it.

So, for a rule of thumb

Unless you’re building a core business functionality of yours — don’t build it!

Reuse something else and thereby make that functionality — and the inherent maintenance — someone else’s problem. Yes, even pay for it. It tends to be cheaper to pay the experts rather than to do it yourself, especially when it comes to security. Remember, it’s a business after all.

So, if you’re not in one of the following businesses, then reuse but don’t build

• dashboards
• blogging engines
• web frameworks
• UI frameworks
• …
• and all the other countless readily available products with a large industry wide penetration and solid reputation

It’s 2020. There are enough readily available round wheels out there.

If you reuse what’s already there then you don’t have to maintain it!

Ultimately, the choice is yours. But you have been warned.

Modern Architecture Components

Before actually building things, it really helps to have a solid architecture in place. Yes, even — or especially — “just sellotaping things together” requires a detailed plan of what to sellotape together and how. Get it wrong and you have a very sticky big ball of mud.

Now, you probably wouldn’t try to assemble a 1 million pieces Lego puzzle in the dark with only a hammer but no instructions either, would you?! So, why do the same with software then?! And you probably also don’t want to end up with an architecture whose main guiding principle is

I don’t know what the architecture will look like but it will definitely contain microservices!

The good news is that for most modern software engineering projects, the main key components for arriving at a modern architecture are

1. Google
2. GitHub
3. StackOverflow
4. Brain+Time

Feel free to extend the above list with vintage classics such as “Books”, “Colleagues”, “Whiteboard Sessions”, or “Reviews” if it helps. Oh, and never forget the persistent all-time classic: “Worx for Me!™”!

The application of the above architecture tools should give you a pretty good understanding of which components perform which actions and how they all interact to emerge as one elegant piece of software.

In short: We have a plan of what to build and how it all fits together!

The Missing Manual

With the architecture in place, it’s now time to fill in the blanks and finally start building! Hooray!

For that, just follow these ten simple steps — of which eleven (not so simple) steps have been written down — for a foolproof path to success!

0. Understand the problem you’re trying to solve — Backwards!
1. Google if someone has already solved your problem
   1. If there’s a readily available solution
      1. Use or purchase it
      2. Integrate it
      3. Go straight to step 10
   2. If there is no readily available solution proceed to step 2
2. Google the required frameworks
3. Clone the identified frameworks from GitHub
4. Google the integration of the cloned frameworks
5. Sellotape the frameworks together; go back to step 2 if frameworks turns out to be unsuitable
6. Google any error messages
7. Find the solutions on StackOverflow
8. Copy and paste the solutions from StackOverflow straight into your code base
9. Go back to step 6 as long as there are any errors or step 2 if frameworks eventually turn out to be unsuitable
10. Declare Success!

Note that all paths through the missing manual inevitably lead to step 10: Declare Success! No good manual should be complete without it! This is no exception.

Feel free to adjust or alter the paths through the missing manual as necessary. However, we strongly suggest to always terminate each path at step 10: Declare Success. Just as no good manual should be complete without it, so should no great project be complete without it! The sooner you can get there, the better usually.

Democratic Architecture

With all steps in the missing manual leading to declaring success, the trick is how to get there as quickly as possible. Note that one shortcut goes through the reuse of readily available products.

With most industry standard products now publicly available to everyone thanks to open source, this means that everybody now has access to the same products as the industry titans.

But this also means that we’re entering an era of democratic architecture! Just like IKEA gave the masses democratic design with its affordable physical designer products decades ago, publicly available software products now give us industry leading high quality products for the masses by the masses. Just take a look at your favourite app store.

Obviously, the challenge now becomes picking the right products to sellotape together in order to solve the right business problems — and deploy them onto the right infrastructure. But by automating away the groundworks, these readily available products free us from dull work and allow us to focus on adding business value from the outset.

And it doesn’t stop just there. Deploying the final products onto the cloud allows to run them on the same infrastructure as the biggest industry titans (as long as you can pay the bill that is).

So, the product is not just only rapidly built, it’s also rapidly deployed, using the same technology stack as the biggest industry titans. It seems that we’re on a quite level playing field. Now, isn’t that democratic?!

Now, go on and build something that makes a difference and eventually changes the world!

The manual is above.

So, How Do You Build Software?!

While the above is my view of modern engineering practices that Worx for Me!™, yours may differ.

Think this is all rubbish, massively overrated, or heading into the absolutely wrong direction in general?! Feel free to reach out to me on LinkedIn and teach me something new!

As always, prove me wrong and I’ll buy you a pint!