As I said in the part I we need to create a rock solid foundation on which to build digital things. And that foundation is made of … principles!
We’ll come to why principles are so important shortly.

The principles below are not even restricted to development. They might feel too basic and general, but don’t underestimate their value. I don’t know how many times I have had these verified in real world scenarios. Today like five times.

Unfortunately I am a slow learner…

But you are just stating the obvious!

That is the downside with reminding people about things they already know somewhere deep down. But here’s the thing:

If it was that obvious, then we would be doing it all the time, right?

And we know already that we don’t. Bugs are everywhere, digital things are not built to last, singularity is approaching and my cloud storage just got hacked.

So it is high time to get principled!

Best Practices suck, Principles rule!

Best practices, hands-on advice about the best way to do stuff, what’s not to love? More than you might think.

Best Practices are great but have their limitations. To generalize:

• they focus on what to do but not why
• they are often too specific and translate badly between contexts
• in many cases a more correct description is “personal taste” and they don’t have any effect that matters in the real world
• calling something the “best” tricks you into believing that that is the case, which it probably isn’t. It also suggests that other alternatives are “almost as good” so it doesn’t really matter anyhow.

Principles on the other hand

• focus on the why
• can be transferred between completely different contexts
• are easily falsifiable and therefore possible to trust
• and they function as a support and compass for decision making.

Skipping Oxford this time, here’s my personal definition of what a principle is:

A principle is a rule that forces us to think for ourselves.

Behind each best practice of any value there is a principle. Define it, verify it and, if it holds up, build on it and spread it. The increase of value is massive!

And just to be clear: “Best Practices suck, Principles rule!” is also a principle, don’t let the meta confuse you!

Escape Dependency Hell

Dependencies are BAD. Dependencies creates fragility. A failure or change in behavior in one part will affect the whole system or process. Since our goal is bug free code we need to kill dependencies whenever we encounter them.

I don’t think anyone disagrees with this. Still, are we living by this? Are we removing all dependencies that we can?

There are a lot of dependencies that seems impossible to get around, compilers, operating systems, browsers, hardware, and more, we’ll come to how to mitigate some of those in the next article.

But developers are willingly locking themselves into other people’s code and creating masssive dependencies. Nowhere is this so obvious as in the JavaScript eco system. There are libraries and frameworks for everything, many of them solving exactly the same problem in slightly different ways.
Just picking which to use for a project becomes a cost item in the budget.

People tend to stick to the ones they know, not because they are the best but because just staying up to date is a full time job. Constant updates of all dependencies guarantees that maintenance has to be ongoing forever.
Yay says finance!

I get it, there are reasons, and some are actually good. But if we want to get to bug free code, then we have to judge them differently. They are dependencies and should be handled accordingly. Exterminate!! 😜

In part III I scratch the surface of Dependency Hell!

Stop inventing the wheel!

Let’s say you solved a complex development problem, now the thing works as intended, that is great! Congratulations!

That was the goal, right? Mission accomplished? Well, actually, that is a pretty small part of the goal if we want to get to bug free software. We must extract the maximum value out of this achievement. So what is actually the value, except that it works?

Let’s assume you documented the solution then it should be possible for someone else to understand what you did and learn from it. What they probably don’t understand is WHY you solved it that way, and they don’t see all the ways you tried to solve it before you picked this path. THAT would have been pretty valuable, don’t you agree?

If anyone actually reads it…

Documentation is just one of many things that we have totally backwards.
To build value for the future we need to learn how to transfer information and knowledge to others, so that they don’t have to invent the wheel every time. Not only to other people, even the computer is on the receiving end, we are telling the computer what to do, i.e. information transfer.

There is so much great work done, so much knowledge created, that is totally wasted, no one knows about it. Even in the smallest team the challenge of information transfer is massive and developers are repeating the same mistakes.

Being able to capture all this knowledge is a necessary step to bug free software. This will be the topic for part IV, exciting!

Know where you’re going!

If the Cheshire Cat would have cared about bug free code it might have said (in a more literary way of course):

If you don’t know where you are going, then every step is most likely in the wrong direction.

That single line of code you are writing is a part of a component is a part of an application is a part of a system is a part of a product is a part of a strategy is a part of a company vision and mission. Don’t mess it up 😜.

In this context there are two distinctly different ways to make fools out of ourselves.

The first is being too smart too early. Implementing functionality that seems like great ideas that turns out they were not needed, or even worse, they created new problems. There is a silly hat for that.

So YAGNI is a great principle, You Ain’t Gonna Need That, don’t implement functionality until you actually need it.

But there is also the opposite, YAKYNT (?), You Actually Knew You’d Need That. You are not stupid, and the future is not a black box, just a little blurry. If you know that the goal is 100k concurrent users, then there are some design decisions that will make you both deserve the silly hat and a time out.

If you don’t see the bigger picture how can you make the right decisions about the details? So we must educate ourselves. Never start a task without understanding where the project is heading and how we fit in.

The next step is understanding the order that the tasks have to be performed. A final result can consist of a long chain of tasks where each task depends on the previous one. Doing things in the wrong order will sooner or later cause extra work or lower the quality of the final result.

I will describe an iterative process that actually works in part V.

If something feels complicated…

If you have read any of my articles about creativity there is one thing I repeat again and again:

If something feels complicated then we are probably doing it the wrong way.

There is no other context where this is more true than in coding. Some code challenges are complex, but it is when it feels complicated we should take a step back. Start here to get the full line of thought (there are elephants!)

This feeling that there must be a better way is a trigger for some great and innovative solutions. And reducing all complexity is a necessary part of getting to the goal, bug free software.

“Good enough” is not good enough

A digital challenge can be solved in a million ways. Of these a fraction are ok, meaning they work, and a fraction of that fraction might be considered “good”.

If you are going to write bug free code, then there is no such thing as good enough, it has to be perfect, no pressure!

There is a million reasons why things are not perfect. Deadlines, external dependencies, unforeseen events. But cutting corners is only a short term strategy (very short). Eventually someone has to update what you have done, a year later things will be blurry, even for you. All sloppiness will come back sooner or later to bite you or someone else.

And there is no future for a sloppy foundation, if you realize that you have solved the things in the wrong way, redo it and learn from it. Throwing things away might feel like a waste, but in the end it almost always saves time, creates a better result and reduces stress.

Turds and stuff will be described in detail in part VI!

To be continued…

…and there is a lot more to say. Don’t miss out, it will be fun! Make sure you follow me here on Medium or on any channel below to get a notification when they are published.

Next up is Part III: Escape dependency hell!

Until next time!