Simple to implement strategies

Petr Jahoda

Feb 1·6 min read

Ten years ago, there were two of us. With experiences from previous 10 years, with passion and energy, to change the world.

We decided to create a manufacturing software for small and middle factories. Complete system, from scratch, that will help those factories produce better and faster.

At the end, we achieved our goal, but the work could have been smoother. The goal could have been achieved faster and there could been more smiles over the time.

If we knew what to do differently.

If you are standing at the beginning of your project, with passion and endless energy, start immediatelly. But don’t forget to learn from others.

Here are few ideas, that should help you achieve your goals faster.

Always start with an end, but surely distinct between must-have and nice-to-have

When we started our work, those ten years ago, we surely knew, what will our final product look like. But our problem was, we thought, we need to create that final product as soon as possible. So we spent enormous time working and working. And we achieved that end result.

But reality showed us, that a lot of our work was useless. There were functionalities, no one needed and no one never used. There were things, that could be done differently. There were processes, that should be done differently.

So we immediately absorbed different strategy. We re-evaluate our final goal, so we knew, what is our nice-to-have. But then we created a list of must-to-have features and worked only on them.

Nice-to-have was (and is) always changing and we will never reach it. But must-to-have was reached every time with almost no effort. Nice-to-have is that final version we are still trying to achieve and must-to-have is the actual version we are working on.

At the end, we still know where we are heading, but the work is done only on those things, we see as the most important at present time.

Always have next iteration in your head

Let’s say we have our nice-to-have, that is our final goal. So everybody know, where we are heading. Then we have our must-have, and that is our actual goal, our present work. We added one additional step to our planning strategy and that was the next iteration of our present must-have. What will be our next work after our actual work is done.

The reason was simple. We didn’t want to end up creating something, we will discard in the next iteration. So while our bodies were working on actual must-have iteration, our minds were working on next iteration.

To sum those first two things up: we have three different versions in our minds. Ideal version, actual version (we were working on) and next version. And all three had to be aligned.

Use less languages

Over the time we made three major versions (and many minor versions). Those three versions differ not as much in functionality, but in maintainability.

Our first major version was coded in Java, C#, Delphi, SQL, PHP, Javascript, HTML and CSS.

Our second major version was coded in C#, SQL, PHP, Javascript, HTML and CSS.

Out third major version was coded in Go, SQL, Javascript, HTML and CSS.

It should be obvious, which version was worst to maintain. Of course, the first one with 8 different languages. You have to understand all languages you use or you have to have other people that understand those languages. More languages, more possible bugs, because you have to jump from one language to another.

Less used languages will simply give you less headaches.

To put it another way: do you think it is better to have 5 programmers and use 5 languages or 5 programmers and use 1 language?

Use less third party *things*

The problem with using more languages also apply to frameworks, modules and libraries. The more you use, the more the code is unreadable for others, who don’t know them. The more you use them, the more you depend on work of others. If there is a bug in the framework and there is no ETA, when it will be fixed, you have a problem.

At the end, we tried to use as less of third party anything, as we could possibly do. We had to do more work in the beginning, but at the end we better understood our own work, develop additional feature faster and kill bugs in no time.

Write dumb code

If you are a developer yourself, you surely once wrote a piece of code, you were extremely proud of. Chances are, that code was smart. Chances are the code was hard to understand (even for you), after few weeks, months, or years. I did it. My colleagues did it.

The problem with smart code is it’s smartness. When you (or anybody else) are reading that smart code in the future, you have to be in no worse mind-state, you were, while writing the code. Chances are, you wrote that smart code in you best possible mind-state. But chances are, you won’t be in that state every time you are working with this code in the future.

Instead of this, we like to write dumb code. Code, you will understand even while in your worst mood possible. If you post this code to Reddit, you will get reactions like “Are you kidding me, why are you posting this obvious and stupid code here, are you a beginner or what?”

We always preferred dumb code over smart code. In the end, it gave us less headaches and we saved an enormous time while hunting bugs and recreating content.

Have a “think day”

This was something, that emerges over time, and will be better explained with an example.

We had a piece of code, that re-calculated 365 days of data every day. Every night, to be precise. This recalculation took about 7 minutes. That means this: when you look at the results at, say, 01:00AM and then at 01:08AM, there were slight differences in results. Over time, we shorten this to 3 minutes. But we wanted to give our user a possibility to recalculate those data on demand, so user can click on a button and get actual recalculated data. But no one will be waiting for seven or three minutes.
Because we were better and better in managing our time, we declared Friday as our “think day”. That was a day, no one was allowed to work on “standard work problems”, but instead was allowed to think about anything. And at the afternoon we sat down and have a conversation about that anything. Mostly ideas, crazy ideas.
Once, we were astonished, when we were presented with a piece of code, that did that recalculation in less than two seconds. But the code was so smart, that few of us, including me, had problems to understand it. No use for us. But you can be sure, everyone was thinking about that piece of code, over the weekend. And on Monday, we get three different versions of that Friday code. All those were written in dumb way.

I have to say, the best things were made this way.

Engage non-programmers

I knew, from my previous work, that we needed to engage everybody to the project. Even accountant. Everybody had to know, what the project is about, how it looks, what it is doing, why it is doing it and so on.

The reason for this was simple. You, as a developer, or system architect, or designer, or … can simply overlook things that are no important for you. Something like “those colours remind me an advertisement for a washing powder”. And you surely don’t want to associate your product for factories with an advertisement for washing powder.

Engage everybody. Show them, explain them, ask them, listen to them. Engage them.

Have a list of “we know we should make this better”

This is a final advice and maybe you already know, what we will be talking about.

When I was smoking, I knew I should quit. When I was overweight, I knew I should start to exercise. I knew I should learn this and that. I knew.

And while developing a software, you know there are things, that should be better. They are working, sure, but somehow you know, they are not in their optimal state. You know something, and others know different things.

Make a list of those “we know we should make this better” things and look at this list from time to time. Let your unconsciousness work at the background. I guarantee you, those things will appear on those Fridays.

Having this list will make your product better, over time.