DEV Community: Hüseyin Polat Yürük

3 Coding Stages: Writing. Avoiding. Deleting.

Hüseyin Polat Yürük — Thu, 27 Jun 2019 09:46:56 +0000

Iceberg

This is how I see all the hidden facts that we developers usually forget or tend to ignore when we are excited about writing code or implementing something new.

In the form of an iceberg…

The iceberg looks small and beautiful from the outside, so people tend to forget its actual size and what hides beneath the peak. What people see from the outside is actually just the tip.

Writing code is the same thing.

When you start writing code, you are too focused on what you have to write, and you don't focus on how much it may cost you down the road. Or, you ignore it.

As the years pass, all your experience and the mistakes you make teach you that what you used to ignore is actually the most important thing you must consider.
So what are those important facts that, as a developer, you usually forget?

Every line of code you write is:

code that has to be read and understood by other programmers
code that has to be tested and debugged
code that will increase defects in your software
code that probably will introduce new bugs in the future

In the beginning, you just see the code. You think, what can go wrong? But actually, it's just the tip of the iceberg.

In a developer's programming life, it takes some time to develop the ability to see the whole of the iceberg. To see that, you have to pass through the three coding stages in your programming life.

Let's speed up time and check each of the stages together.

1. Writing code as much as possible

Remember this time? You had just started your programming career as a junior developer. You were hungry, foolish. You were always on the lookout to write some more code lines and for problems to solve. You said yes to every possibility that required you to write code. You were too excited. You spent hours and days on it. You forget about sleeping.

Being too excited and writing code as much as you can in that stage is good. This is how it should be. This is how we learn to program. This is how we practice being a better developer. In the meantime, while we are writing that bunch of code, we make a lot of mistakes too. And that is totally fine. They are just small mistakes. Nothing can stop you from writing code.

After some time, maybe four to five years, you start learning the new programming facts that you didn't know before. You face the reality beyond the code. You have just seen the tip of the iceberg with writing code, and now you are curious to see what is under the sea.

This is the stage where you see that every code has to be read, understood, tested, debugged. You've just understood how important future maintenance is for your software to last longer.

2. Learning when not to write code

After you experienced a few programming horror stories, you found yourself thinking about how you can avoid writing unnecessary code, because you knew how much it can cost you.

In this stage, you were learning when not to write code to avoid being a victim of another horror story. You were still excited about writing code, but you were wise enough to know that less code is better. Simplicity is your ultimate guide here. You understood that it's harder to read code than to write it. That's why you started focusing on more readable, understandable, and simpler code.

In this stage, you followed a few simple rules that transformed you into a better programmer.

Writing less code.
Keeping your codebase small
Saying yes to what is essential and saying no to rest of it

Knowing when not to code is possibly the most important skill a programmer can learn. - The Art Of Readable Code

3. Deleting code as much as possible

One of my most productive days was throwing away 1000 lines of code. - Ken Thompson

In this stage of coding, you understand exactly what Ken Thompson was trying to say with the above sentence.

You know that the more code you have, the more places there are for bugs to appear. It takes longer checkouts or compiles. It takes longer for a new employee to understand your system. There's more stuff to move around if you have to refactor.

Furthermore, more code often means less flexibility and functionality. You understand it based on your own experience. You know when not to code, but, at the same time, you know that by deleting the unnecessary codes or refactoring complex solutions with simpler, more elegant ones, you can decrease defects in your software.

In this stage, you discovered all parts of the iceberg. You know what is under the sea. The next time you see a new iceberg, you will be more careful, and you will not make the same mistake as the Titanic did.

The key idea of this piece is not that writing code is your enemy. You are a programmer. Writing code is your passion and it will always be. It will cover a big part of your life. I just want you to understand what is behind all of that code writing and that with each line of code you have written, you accept the burden that comes along.

Don't surround yourself with unnecessary codes.

The most important skill a programmer can learn

Hüseyin Polat Yürük — Sat, 18 May 2019 10:49:04 +0000

No, no, no, no, and no. And no.

A big NO. Clear as that.

All you have to do is to bring those two letters together and say the word.

Now, let’s say it together. NOOOOOOO!

Good start.

But wait a minute. Say NO to what and when?

Well, this is the important point where most of the programmers (even seniors) get easily confused.

As a programmer, writing code is the biggest part of your job. In your programming lifetime, you will have to deal with different kinds of code requests. Each request will force you to make difficult decisions. That all is OKAY. Nothing wrong with that. This is what everyone expects from you, as a programmer: Writing code. However, here is a question: Should you write all the code that is requested from you?

This question brings us to the most important skill a programmer can learn:

Knowing when not to code is possibly the most important skill a programmer can learn. — The Art Of Readable Code

I couldn’t agree more. Why is that?

Programming is the art of solving a problem. So naturally, programmers are problem solvers. As programmers, when we have a new problem in front of us ready to be solved or any other reason that needs from us to write code lines, we get excited.

And that is okay because we are programmers. We love writing code.

However, getting too excited about writing code makes us blind. It causes us to ignore some important facts that can cause bigger problems we will have to deal with in the future.

So, what are those important facts that we tend to ignore?

Every line of code you write is:

code that has to be read and understood by other programmers
code that has to be tested and debugged
code that will increase defects in your software
code that probably will introduce new bugs in the future

As Rich Skrenta wrote, code is our enemy:

Code is bad. It rots. It requires periodic maintenance. It has bugs that need to be found. New features mean the old code has to be adapted.

The more code you have, the more places there are for bugs to hide. The longer checkouts or compiles take. The longer it takes a new employee to make sense of your system. If you have to refactor there’s more stuff to move around.

Furthermore, more code often means less flexibility and functionality. This is counter-intuitive, but a lot of times a simple, elegant solution is faster and more general than the plodding mess of code produced by a programmer of lesser talent.

Code is produced by engineers. To make more code requires more engineers. Engineers have n² communication costs, and all that code they add to the system, while expanding its capability, also increases a whole basket of costs.

It’s so true, isn’t it? The programmers who inspire you with their productivity and coding mentality are those who know when to say no and when not to code. The software that is easy to maintain, that lasts long and keeps helping their users is the one that doesn’t contain any unnecessary code lines.

The best code is no code at all, and the most effective programmer is the one who knows when not to code.

How can you know when not to code?

It’s natural to get excited when you’re working on a project and think about all the cool features you’d love to implement. But programmers tend to overestimate how many features their project needs. Many features go unfinished or unused or simply make the application overcomplicated. You should know what is essential for your project to avoid making this mistake.

Understanding the purpose of your software and its core definition is the first step to know when not to code.

Let me give you an example. Let’s say you have software that has only one purpose: managing emails. And for that purpose, sending and receiving emails are two essential features to your project. You can’t expect that software to manage your to-do list as well, can you?

So you should say NO to any possible feature requests that are irrelevant to this definition. This is the moment you can be exactly sure that you know when not to write code.

Never expand your software’s purpose.

Once you know what is essential for your project, you will be conscious next time when you evaluate possible code requests. You will exactly know your requirements to write code. Which feature should be implemented? Which code is worth to write? You will question everything because you will know exactly how unnecessary code can kill your project.

Knowing when not to code keeps your codebase small.

There are only two or three source files when you start your project. All looks so simple. It takes just a few seconds to compile and run the code. You know where to find exactly what you’re looking for.

Then, as the project grows, more and more source files fill your directory. Each code file contains hundreds of code lines. To organize them all, you will need multiple directories soon. Remembering which functions call other functions is more difficult, and tracking bugs requires a bit more work. Managing your project becomes difficult, and you need more programmers to help. Communication overheads increase as the number of programmers increases. You get slower and slower.

In the end, the project becomes huge. Adding new features is painful. Even making small changes takes hours. Fixing present bugs always introduces new bugs. You start missing deadlines.

Now, life is a struggle for you. Why?

Because you didn’t know when not to code, you said YES to every possible feature request. You were blind. Coding something new caused you to ignore essential facts.

It’s like a horror movie, right?

This is what will happen if you keep saying YES to everything. Know exactly when not to code. Eliminate all unnecessary code from your project. This will make your life easier and make your software last longer.

One of my most productive days was throwing away 1000 lines of code. — Ken Thompson

I know that knowing when not to code is so hard. Even for senior programmers. Perhaps what I wrote in this article is hard to understand for junior programmers, and that is okay and understandable.

I know you have just started your programming journey and you want to write code. You are so excited about that. This is good. Never lose this excitement but also never ignore the important facts. We learned them by making our own mistakes. You will make mistakes as well, and you will learn from them as well. But at least you can be more conscious if you can learn from our experience.

Keep coding but know when to say no to coding.

How to make peace with deadlines in software development

Hüseyin Polat Yürük — Fri, 10 May 2019 13:11:30 +0000

D E A D L I N E…

As a developer, this is one of your biggest nightmares or should I say your enemy? Name it whatever you want.

Admit it. It scares you a lot. Even now, while you are reading these sentences, it makes your hair stand on the end.

Wondering how I know that?

I know because I've felt the same. But now the fear is in the past. I've made peace with deadlines. I've embraced them.

So I suggest you do the same thing. Embrace them, make peace with them. This is the only way that you can defeat them.

Ok but, how you can do that?

There are some facts that we all tend to ignore when it comes to setting a deadline. My aim here is to show them to you so you can see that it takes so little to bury the fear and start enjoying life while you are working on your project without worrying about dates.

Work in a calm environment

Don't rush. Don't force anything.

The first thing first you should know is that you can't find your peace by setting unrealistic dates and forcing your team to work in a rush. There are companies that throw out big words and show unrealistic things to motivate their team to move forward. But while there are some facts obvious to everyone in the team, how can you expect them to believe in what you are saying if it is far away from reality?

Without a fixed - and most importantly believable - deadline, you can't work calmly. Yes, keeping the calm is the key here. When you don't trust the date, or when someone tells you to do everything within a limited period of time, or someone adds more tasks to the project without giving you more time, you start working maniacally. This is not work anymore. This is hell.

When you are under stress and pressure, you can't be productive. When you are calm, you are also conscious which means that you can make better decisions.

Our estimates suck

Windows users will remember that window dialog. The estimation in the dialog is exactly like our estimations, isn’t it?

Let’s admit it. Our estimates suck. We think we can guess how much time something will take. We have a tendency to believe that whatever we guess will come true.

However, generally, when we are guessing, we ignore some important factors that can affect our assumptions. Why? Because we are too optimistic.

To me, the first step in making peace with the deadline and getting better at setting deadlines is to admit that we are terrible estimators. When you embrace this fact, you will be conscious next time and it will prevent you from underestimating the requirements. And here is a solution for you to get better at estimating:

Divide the big things into smaller things. The smaller it is, the easier it is to estimate. This will increase your chances of having more accurate estimations.

Good enough is fine

“Perfect is the enemy of good.” — Voltaire

People like big challenges. We are best at finding a complicated solution for a simple problem. But here is a fact:

Every problem has its own simple solution that you probably ignore.

Don’t chase a perfect solution. Your first version doesn’t have to be perfect. Build a half product that can work. If you wait too much, you will waste your limited resources and precious time, or you will miss the deadline and even worse do nothing at all because you are chasing perfection. The solution is:

Find the solution that will bring you a lot of value and requires little effort. And don’t forget, good can be turned into great later.

Don’t be too optimistic. Be realistic.

I see managers that are too optimistic which makes them set optimistic deadlines to motivate the team. This is so wrong. I’m not telling you that you should be pessimistic about the future. On the contrary, I am telling you that you should be able to see every possibility that can create a bottleneck. Once you can see them, you can consider them and have a more accurate estimation.

There are different teams in the company. Engineering, business development, marketing, etc. When the business development team forces you to give them a deadline in the very near future, you shouldn’t get affected by them. They want their job to be done as soon as possible.

Remember that every team thinks about their own side.

Differentiate between “you have to do”, “you could do” and “you want to do”

Understanding is the key here. What are the core requirements for releasing your product? Usually, the product team has a hard time differentiating them.

When you have a meeting, one of the team members will say, “we could implement it, it will bring us that much value” or another one will say “We should put this into release.” They are looking from their own perspective. Ok, we can implement this and it can bring us some value, but the important question is that “do we need it now? In the first version?”

The answer is NO in most cases.

The things that you have to do are what you should focus on. Eliminate things you could do and you want to do. They are not even negotiable in most cases.

Say no by default

There is one important fact that we usually forget when we say “Yes” to something. We are saying no to the things we already need to complete.

When you say yes to something new, you’re not thinking about the impact it will have on your existing to do’s.

“Let’s add more tasks to the project after we’ve set the deadline. (Your project should get smaller over time, not larger.)”NO.

“We focused on what matters, ok. But what about the details? Let’s consider what kind of details we have that can make problems in the future.” NO. Ignore every detail for the first version. Don’t try to predict the future.

Finding more time for things isn’t the problem here. Too much stuff to do is the problem. Differentiate between “must-haves” and “nice-to-haves”.

The only way to get more done is to have less to do.

Never change the deadline

I see development teams with a bad habit that can affect their product development badly: deadline rescheduling.

When they miss the deadline, they set a new one. If they can’t meet this one, they set another one. When they do this repeatedly, it becomes a habit. Then this bad habit turns into their culture. Other teams in the company lose trust and question the developers’ work. Even worse, the developer team itself can lose trust in each other. In themselves as well.

Changing the deadline is essentially an admission of failure. It is making statements like, “We failed to plan requirements, we didn’t say no enough, we didn’t focus on what matters, we pushed our teams to do unreasonable things in an unreasonable time.”

Be aware that there will be always some problems

Being too optimistic causes you to ignore the fact that there may be some problems. Be aware. Probably something will go wrong. And this will cause you to lose some time on fixing things. So better to be prepared for bad scenarios. I am not saying that you should be pessimistic and you should try to predict the future and prepare yourself and your team for the unknown. Just find a balance between optimism and pessimism. Be realistic.

My experience showed me that, in software development, some things always go wrong. My advice to you is:

Add some time to your deadline before you set it by considering that something may go wrong.

Don’t add more people to a project

A lot of people think that they can speed up the process if they add more people to the project. However, they miss a very important point. Let’s remember Brooks’s law:

Adding human resources to a late software project makes it later. — Freed Brooks

According to Brooks on Wikipedia, there is an incremental person who, when added to a project, makes it take more, not less time. So why does it work this way?

It takes some time for the people added to a project to become productive. You will have to educate them first. You have already limited human resources and you will have to dedicate those resources to educate new member. Also since they are new, they will introduce new bugs that move the project further away from completion.
Communication overheads increase as the number of people increases.
Adding more people to a highly divisible task, such as cleaning rooms in a hotel, decreases the overall task duration. However, other tasks including many specialties in software projects are less divisible. Another great example of this by Brooks is: while it takes one woman nine months to make one baby, “nine women can’t make a baby in one month”.

Another bit of evidence from Richard Dalton to understand why adding more people is wrong is:

“Teams are immutable. Every time someone leaves or joins, you have a new team, not a changed team.” — Richard Dalton

Don’t procrastinate

Let me help you to understand what I mean. Last week, we had a meeting about defining the deadline for a new feature of our product. We were talking about which tasks are our priority and how we should implement them in an effective way.

There was a task on which we have heavily wasted our time. There were three ways to implement that task but somehow we were stuck. We couldn’t choose because developers were trying to predict the future. They were starting each sentence with “What if”.

You can’t predict what the future will bring you. Don’t over-prepare yourself for the unknown.

I am not talking about big technical decisions here. Of course, if you have to decide on your core technology, you should sleep on it to find the right solution. But don’t spend your time on small things. Uncertain things increase meetings and block your progress because your backend process is continuously working on them.

Don’t procrastinate it, decide on it and move forward.

Change your mentality from “Let’s think about it” to “Let’s decide now”. Decisions will speed up your progress. When something is decided, it will be clear to everyone in the team. Everyone will exactly know what to do.

Communicate: See where is the bottleneck?

You planned everything. You defined what to focus on and what to do. You know exactly how much time it will take (probably you will be wrong). So, the deadline has been settled. Is it enough?

NO.

As I mentioned above, there is always a possibility that something can go wrong. While your team members are working on their tasks, something can block them. Something can stop them to finish their tasks on time. You have to see where is the bottleneck and what it is.

Communication is the key here. You have to keep teams synced. Sometimes team members can go into a box and it can be very hard for them to see what is happening out of it. This is where you should enter the scene. Once you have identified the bottleneck, remove it so your team members can continue from where they were stuck.

I wish you to meet all deadlines:)

Thanks for reading.

Lessons Learned About Rewriting Code As 10+ Years Experienced Developer

Hüseyin Polat Yürük — Tue, 19 Mar 2019 13:39:23 +0000

12 months.

That's the time we wasted while rewriting our software from scratch.
Twelve long months in the software market.
Without innovation.
Without moving forward.
Really, I cannot stop asking this question to myself.

What could we achieve in this fast-moving world in 12 months?

"Tuesday, January 20, 2015, 5:10 PM, AntiMalware product is finally going its first public beta."

After hours without sleeping, the first release note that would give a start to our new journey was published on the website.
I was working for one of the small cybersecurity companies which provides security software for end users and enterprise companies. Our software protects users against malware. It cleans their computer if they get infected. Our AntiMalware was one of them.
The first beta version's feedbacks and impressions were promising. We were four developers, working on that product and constantly fixing bugs, iterating new versions by improving the product.

First stable version

After two months working on bug fixing, improving and coding, we released the first stable version of AntiMalware.

What were users saying?

Most of our users' feedbacks were great, and they liked the product. This was keeping our team motivated. We were actively working on the product to improve our core features.

The airplane is taking off.

2016–2017.

Our golden years before the big storm.

AntiMalware was living its best times. It was becoming our flagship product. Users were recommending it to their friends. Every blog and forums related to security were recommending our software. It was the first option when it comes to rescuing infected users.

Downloads, installations, sales.

Every metric was going up, the user base was growing quickly over months. Founders were happy, the team as well. This was the big success the company was looking for. Everyone thought: "We did it! Like other big companies, we thought we created our own success story."

New opportunities (at least we thought like that): Entering the enterprise market

The company decided to enter the enterprise arena. We were building a new team for the corporate product. The product owner of AntiMalware was leaving the team. Our CTO was taking responsibility and becoming the new owner. (Big mistake. I will explain why).

Some developers were leaving the company, but it was OK. We were handling everything well and AntiMalware was still the best option in the market.

Good days were behind. Let's face reality.

As I told you, our CTO was handling everything about AntiMalware. He was the main developer, constantly releasing new updates and improving the product's capability. However, because of his position, he had to handle other company stuff also.

Sure, in the beginning, everything was going well. As in every development process, in our case also, we had to keep maintaining and improving our software.

As we should have expected (clearly we didn't), somehow, the development process started slowing down.

The days when we were releasing new updates were behind. At that moment we were living the reality of late updates and soon no updates at all. This bugged me a lot and one day I asked our CTO:

"What is wrong with this product?
Why do updates take too much time and development is slowing down?"

He took a deep breath and started talking:

_"The code base is really complicated. It is not structured well and it is not loosely coupled. The architecture was designed in a totally wrong way. The UI and core logic interfere with each other. Whenever I fix a bug or change something, this affects other parts of the software. Even small changes are hard to be done. With every new update, something new comes up.

There are some methods that take 20 parameters, they are two pages long! Can you imagine? There are many things that were supposed not to be implemented but they were implemented anyway.

That's why every update takes too long and I cannot implement a new feature. If we release a new update, I am scared that we might introduce new bugs and break the program's core functionality that works well now. That's why it is too risky for us to release a new update. We can lose our users. We can lose our product as well."_

A burst of reality came out from his end and all of us knew it. Actually, we were expecting this answer from him.

But there was one more thing to be asked. He was leading the previous main developer who led the product for one year, so how could the code be that messed up?

"I didn't want to break his motivation. We had to enter the anti-malware market as fastest as possible and he was good at this. That's why I didn't want to stop him."

Basically, we sacrificed the code base to enter the market in the fastest way, but this destroyed our product's future.

Lesson learned: Don't hesitate to say "this is sh*t" if something is really sh*t. The future of your product is more important than your spaghetti code. Focus on to have a sustainable product.

How can we fix this terrible code?

"We're programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We're not excited by incremental renovation: tinkering, improving, planting flower beds."
- Joel Spolsky, CEO of Stackoverflow

Developers always have a tendency to throw away the code and start over. There's a reason for that. The reason is that they think the old code is useless and a mess. But again we just think! However, when we try to find out what is the real reason behind that, we can face the fact:

We are probably wrong!

The reason that the old code might look messy to us and that it has to be rewritten from scratch isn't actually because of the code but rather because of a cardinal, fundamental law of programming:

It's harder to read code than to write it.

This is why it is so hard to reuse code. This is why we think "It's a big hair mess". This is why our subconscious mind whispers to our ears "Throw it away and start over" when we read another developer's code.

Like every developer, we fall into this trap. Just checking our messy code one time was enough to think about rewriting it from scratch.

After a series of meetings, even though our CTO was resistant to code rewriting (right behavior), he was convinced in the end and we started the rewrite.

**However, this decision didn't last too long…

It was a weekend. Sunday. I was drinking my morning coffee and reading some articles. Like my feed knew what to show me, I came across the most known article about rewriting the code. It was Netscape's rewriting story written by Joel Spolsky.

Sharing this article with the rest of the AntiMalware team, including our CTO, was my immediate action after I finished reading it.

Another discussion started.

It was already hard to convince our CTO to rewrite the code but after reading that article, he changed his mind again. He did not want to execute this decision. Other team members were yelling at me:

"Why did you send this article? We already convinced him. This product must be rewritten from scratch. This is the only way."

Hereby, our first attempt was finalized and we closed that rewrite topic. Our CTO believed that he could manage this crappy code and that he could release a new update. This topic was closed until harsh reality knocked us down.

One year without any update…

Really, this is not a joke. This happened!

"Why no update?"

"It has been months since the last update."

These negative comments from our users become our reality. As a small company, we had too many products to manage, and on top of it, we entered the enterprise market which caused us to come to that point actually.

Mix all of that and you get one point: we forgot about our users.

So, imagine. We didn't want to release a new update because we didn't want to lose our users.

Actually, it should've been opposite: if we don't release a new update we will definitely lose our users because hey we didn't give them an update for over a year and a half.

After the reality slapped us in the face, we decided to reach back and for us, rewriting software was the only option so we did it.

Today.

"Monday, 17 December 2018, 21:40. The email was prepared to be sent to our private beta group."

After 12 exhausting months, we completed our rewriting process. We prepared the first beta release note, just like the first day our product met the market.

Here we are again…

The rewritten version of the product is still in Beta. It has been almost one month. We are fixing bugs, listening to our users, reviewing feedbacks… As we did 4 years ago…

What have we missed during these 12 long months? Who knows what else we could have done instead of rewriting?!

Many questions can be asked at this point. All I know is that rewriting was the only option for us or we couldn't see any other solution.

If you fall into this trap too and start thinking "I should rewrite the software from scratch", consider asking these questions that I believe every developer should ask before taking the first step to code rewriting.

1. Are you ready to throw away all that knowledge?

I am asking seriously! Please be honest with yourself and answer this question: Are you really ready to throw away all that knowledge, all those collected bug fixes, years of programming. This is what you expect when you throw away the code and start from scratch. When you look at code rewriting from this perspective, it's painful, isn't it? All those sleepless nights trying to fix bugs go through your eyes. Believe me, I know.

You had to talk to a lot of users to find the issue that caused your software not to work properly. Then you had to find this bug in your software. Then you had to reproduce the issue then find the fix, then… and so on and so on.

2. Can you guarantee that you are going to do a better job than you did the first time?

It's important to keep in mind that when you start from scratch there is no guarantee that you are going to do a better job than you did the first time.

Since you chose to throw away all that knowledge, collected bug fixes, there is a high possibility that same bugs might again come up.

Probably, the rewriting team is going to be different than the team worked on the first version. So you don't actually have "more experience". You're just going to make most of the old mistakes again and introduce some new problems that weren't in the original version.

If you don't plan well the rewriting process, there is a big risk that a new version might be worse than the original version at solving your customer's problem. With this rewriting decision, you're going to take this risk that can cause you to lose your customers.

3. Are you ready to give a gift of months/ years to your competitors?

Do you know exactly how much time do you need to rewrite your software?

It takes a lot of effort, planning, preparations. You will plan each task and sprint one by one and you will exactly know your deadline to finish this painful process. Or you will miss the deadline. Who knows? There is a high possibility that you won't finish this process on time.

You will be in an extremely dangerous position where you will have to ship an old version of the code for months or years, completely unable to make any strategic changes or react to new features that the market demands because you don't have shippable code.

Your customers might as well just abandon you because you don't give anything new and you keep shipping your old product without any changes.

Did you think about this?!

Lessons learned in rewriting software

Rewriting a system from the ground up is essentially an admission of failure as a designer. It is making the statement, "We failed to design a maintainable system and so must start over." - Max Kanat-Alexander, Code Simplicity

So as other designers, we admitted that we failed to design our software and we learned a lot from that exhausting process. Here I am sharing lessons that stuck to me.

Rewriting code is a developer illusion, not the solution in most cases.

When you are in trouble with your code, it is important to diagnose what is the issue exactly. As every developer will do, your initial thought shouldn't be rewriting. This is just an illusion. It is illusion because you are struggling to read someone else's code and you think you would do a better job if you rewrote it from scratch. In this case, always remember the fundamental law of programming.

Consider refactoring before taking a step to code rewriting

Targeted rewrites are useful to deal with the worst offenses in your code base. Don't do a whole rewrite if you can limit the scope and address the majority of your problems. For example, the loading of your software is so slow. But this only affects a small part of the project. These problems can be solved, one at a time, by carefully moving code, refactoring, changing interfaces. You don't have to rewrite the whole thing.

Beware. This is a longer, harder, more failure-prone path than you expect.

There is a fact that developers usually realize it after they miss the deadline: everything takes longer than you think. Be very pessimistic in your estimates about the cost of a rewrite. It almost always costs more and takes longer than you would think. There will be always a lot of complexity that will make the rewriting process harder and more painful. In the end, the possibility of failure is hard to miss.

Make sure the new product is better at solving user's problem (or at least the same). Worse cannot be acceptable.

Rewrites have no direct effects/benefits for the customer. Your users don't care about your code. They just want to solve their own problem. That's all. In their eyes, you are successful if your product fits in solving their problem. Otherwise, they are not using the product. They don't care about your rewriting decision, so the rewritten version must at least work as efficiently as the old one.

Keep maintaining and supporting the existing product.

In our case, we didn't give any update to users for one year. This is too long in the world we live in today. Our product was still good enough, but users were complaining about no updates. Never stop maintaining a system that is currently in use so that the programmers can rewrite it. During the rewriting process, the old code still needs to be maintained. Small updates and bug fixing should be given to users while you are rewriting the old code. Otherwise, you will face losing your customers.

Involve users in the design process as soon as possible..

Always show your current progress to your end users at regular intervals so that they can help you catch the worst offenses. It is important to meet your users as soon as possible. Their feedback will help you design a new product based on their needs. Don't implement any unnecessary features. This will save you from having a complicated code base.

Keep the teams working on the product synced.

The product is not only about the programming team. Marketing, support, programming, design… Many teams work on it. Keep them synced by giving them regular updates about the rewriting process.

In our case, we have dealt with many problems. For example, the marketing team was preparing our product beta campaign and they had to know exactly what was going on the product side so that they could prepare customers for upcoming product changes. Sometimes we made some changes without informing them. And this caused them to prepare their campaign all over from scratch. Don't spend anyone's time inefficiently.

Don't make dramatic changes to the product.

It is important to know your product's weak and strong sides. Don't change the strong sides, the ones loved by users. If users are satisfied with your UI, don't change it. Do minimal changes and small UX improvements. When you replace your existing software with the new one, your users shouldn't be confused with the new dramatic changes. There are many cases where users abandoned new products because they didn't find the same functionality as the previous product provided. Don't let the same thing happen to you.

Don't make your product depend on only one developer.

In our case, our CTO was the responsible developer for our software. Due to his position, our product development was going slowly. Even small changes were taking several weeks, sometimes months. The point is to always keep moving. Never stop.

Migrations should be slow and steady.

Replace your original software with the new one when you are sure that the new one is ready. Do it step by step.

First, start with a small private beta group and ship your product into that group. Continuously collect feedbacks and crash reports, fix the bugs, iterate new versions and again the same thing. Follow this cycle until you ensure that your product is ready to go public beta.

When you go public beta, feedbacks are going to be your best friend again. Your first goal here should be to ensure that your product solves the users' problems. When you are sure that you are providing the same or better functionality as old software did, replacement can take place. Release the new software for new users, and migrate your existing users to the new one.

Those are the key lessons that I learned from our rewriting process. Rewriting is almost never the answer. More often than not, refactoring is a better bet. I strongly advise the slow approach of using refactoring. It's less risky and you keep your customers happy.

When to rewrite the code

There are times when it is appropriate to do a rewrite. If I could have made a list about when to rewrite the code, this would be my list:

Switching to another language or platform (as in our case):The language is so old. It is hard to find a developer or you have to pay a lot of money to get one. In both cases too much effort.

The existing codebase is not maintainable anymore (as in our case):How do you decide your code is not maintainable? It is hard to determine but if even small changes are hard to be done, if new updates take longer than usual, if any new change affects other parts of the software and introduces new bugs, your software is unmaintainable.

You have the resources available to both maintain the existing system and design a new system at the same time:Never stop maintaining a system that is currently in use so that the programmers can rewrite it. Systems must always be maintained if they are in use. And remember that your personal attention is also a resource that must be taken into account here - do you have enough time available in each day to be a designer on both the new system and the old system simultaneously, if you are going to work on both?

The developers in the team are a bottleneck for software (as in our case):This shouldn't be a reason to rewrite the code from scratch. You can always switch developers within the team or you can hire new developers to eliminate the bottleneck situation.

However, sometimes, as in our case, there might be times where you have to choose the rewriting option. Our software was written with old technology and our CTO was the only responsible person to develop it. We tried to find a new developer but it was hard because of the age of this coding platform. Even if we could have found a new one, it would be very expensive for us. So together with other conditions, this was in our list to decide to rewrite code.

The software is long-lived (I'm talking like 10–20 years or more):Maintenance becomes more and more expensive over time. This is due to the fact that the code is becoming more and more spaghetti-ish as the original architecture is sacrificed for quick maintenance patches. Also, developers for older technologies become rarer and more expensive. Finally, hardware begins to age and it gets harder and harder to find new hardware, operating systems, frameworks, etc. to run the old application on top of it. Also, businesses evolve, and most likely an older system will not be meeting the business needs of the organization.

So you have to weigh all of the ongoing maintenance cost, as well as the potential benefits of a new system, against the cost of rewriting it from scratch.

If your case fits in one or more of the above points, you may be in a situation where it is acceptable to rewrite. Otherwise, the correct thing to do is to handle the complexity of the existing system without a rewrite, by improving the system's design in a series of simple steps.

Rewriting your code from scratch could be the single biggest mistake you make, but equally so, not-rewriting your code could lead to the same result. Here is a piece of advice. Refactoring should be the first option.

Some developers will keep believing that all systems must eventually be rewritten. Always keep in mind that this is not true. It is possible to design a system that never needs to be thrown away. There will be always a software designer around you saying "We'll have to throw the whole thing away someday anyway". But if software is built right to start with and then properly maintained, why would it be thrown away?

How an entrepreneur’s mindset can help programmers design better software

Hüseyin Polat Yürük — Wed, 16 Jan 2019 15:35:20 +0000

Originally published at blog.huseyinpolatyuruk.com.

Hey there!

You clicked on this article (which is a big success for me because this is my first story) — but the point here is not about my writing endeavors, but rather about programmers. And, more specifically, how an entrepreneur’s mindset can change their approach to solving problems and focusing on the big picture.

Since you are reading this article, most probably you are a programmer just like I am. We have probably gone through some similar programming situations and made the same mistakes in our programming life that would make us completely understand each other even though we have never even met.

How do I know this?

Let me try something out. I will list some common mistakes that I have made throughout my programming days. While you are reading this list, if you occasionally nod your head or have your mind blown saying: Hell yeah. I have done the same! then we are not strangers but rather two programmers who have gone through the same stuff. Let’s start.

Have you ever:

Acted before actually thinking and understanding the problem?
Assumed a feature was needed?
Thought that this new feature implementation would be a piece of cake?
Created imaginary problems and tried to solve them?
Published code without testing?
Spent too much time on unnecessary things within an overall project?
Done everything by yourself (hero programmer)?
Applied the wrong task separation and management?
Tried to make the first version perfect?
Underestimated the scope of the project and the amount of time that would be required to complete it (Deadline nightmare)?

Are you still nodding?

The point is that it does not matter which programming language you know or use, what kind of programmer you are, and how vast your experience is. The point is that you are a programmer, and like all of us you can be easily trapped in one behavior pattern which looks efficient at the beginning and makes you feel smart but that eventually turns into a mess.

Been there. Done that.

As every programmer has, I made the same mistakes in my early programming life while working on many different software projects with various other programmers.

Once I reached a certain point where, instead of repeating the same mistakes, I started recognizing behavior patterns, I realized that the majority of programmers were working by the same pattern.

It was a breakthrough for me.

Can you imagine? Instead of spending quality time building great software, we are actually trapped in our own behavior patterns that lead us to lose time day by day and code by line of code.

I decided to try to change this pattern and learn from my mistakes. With the power of will and a bit of luck, I somehow managed to do so.

Start small. Think big.

What was my first action?

I started learning from the best.

I spent every day spending every free minute reading articles, books, watching videos and following best practices on how to improve my coding style and not make the same mistakes again.

I noticed a pattern: having great programming skills (even though they are super duper important to have) is not enough when it comes to minimizing these mistakes. Rather it’s something outside of the code.

To avoid the most common programming mistakes that lead to nightmare deadlines, unnecessary code lines and losing time, you need to expand your perspective and point of view. Instead of just thinking about the software you code only from your perspective, as a programmer, you should look at the software you design from a much bigger perspective.

This bigger perspective means to focus on the main idea, the purpose of the software, and not only on the core functionality.

I realized that we should never forget to ask ourselves: Why are we coding this software in the first place?

What does this mean?

Programmers tend to lock themselves inside the software they build, which usually leads to shrinking their focus only to the lines of code.

When this happens, you tend to miss the main point which is the purpose of the software. You are building this software to help your users by solving their problems and making their lives easier. When you keep this purpose in your mind while you are coding, you will be able to reorganize your development process in a more efficient way. Instead of being trapped inside the code, you are now being guided by the main idea of the software which will give you the ability to cut unnecessary things and focus on the core concepts.

When you put things this way, suddenly coding style isn’t the only important thing.

Beyond the code

While working in a company and leading a team of developers, I also started building the side project that eventually taught me some major lessons on how to reorganize my development process. I went from a code-only perspective to a software purpose perspective.

How I started was very simple. It is maybe ironic, but to improve my code, the first thing I did was to escape my code. I had to see beyond the code.

Maybe it sounds weird but it actually works. While working as a programmer, I also had the tendency to focus on the code functionality until I started building my own project.

While designing my own software, I started reading many articles about how entrepreneurs should approach problems in order to solve them and how they can grow their business with limited resources and limited time.

I saw that the strategies entrepreneurs follow can help programmers change their mindset and help them develop better and bug-free software.

I went and applied the same concept at work and it showed great results.

Let's take a closer look at each common mistake made by programmers and see how entrepreneur mindset can help us avoid them.

1. Acting before thinking about the problem

Have you ever jumped straight into coding instead of thinking about the problem you are trying to solve? Without considering all the requirements of the software? Yeah, I have, too. Then we realize in the end that we chose the wrong tools and wrong architecture to code the software.

As a result, we face even bigger problems than the problem that we tried to fix in the first place. These problems come in the form of complex design, which makes the solution unmanageable and results in hard to maintain program structures.

So now, let’s try to approach this problem from an entrepreneur’s perspective.

An entrepreneur would do deep research to understand the market and problems that the customers experience. They would know that without exactly understanding the problem and analyzing it from each perspective, eventually, it would lead to bigger problems like wasting time and resources. After all, with already limited time and resources, wasting time on unnecessary things is definitely not part of their plan.

Main point: Don’t act before understanding the problem.

2. Assuming a feature is needed

If you don’t understand the exact expectations and features that are required by the software you need to build, you might misunderstand the concept and invent an unnecessary feature which is totally irrelevant to the overall software’s purpose. So what happens is that you waste your time on that unnecessary feature while missing the core feature’s implementation.

From an entrepreneur’s point of view, this is not acceptable.

While building software you should first focus on the feature that solves the customer’s problems. By listening to the customer’s voice and analyzing their needs, you can then build software from essentially required features while others come later on.

Main idea: Don’t assume. Question everything.

3. Assuming new features will be easy to implement

As programmers, we have a keen ability to underestimate the feature implementation process. Sometimes we believe that we know how to solve the problem without even thinking about it.

Again — wrong.

This kind of behavior leads to missing deadlines because nothing is easy and everything has to be planned carefully. An entrepreneur would know that without having a clear implementation plan, invisible problems may appear which can eventually lead to many other troubles.

Main idea: Never underestimate the problem. Think, plan and then act.

4. Creating imaginary problems and trying to solve them

As programmers, we like challenges :) (you know what I mean).

Sometimes we like to implement code that has no other purpose but to satisfy ourselves and prove to everyone that we could overcome this challenge.

There are moments when we even try to predict features that will solve imaginary problems that we created.

Crazy, huh?

While programmers are inventing imaginary problems, entrepreneurs are avoiding them. Simple enough.

They would focus on the problems that actually already exist and try to solve them as soon as possible. In that way, they gain the ability to invest their time in things which are essential for their business.

Main idea: Don’t predict future problems. Focus on the ones you already have.

5. Publishing code without testing

Do you remember the last time you pushed some code to production without testing it?

Sometimes we make this mistake because we are excited about our code. Sometimes even senior programmers can make this mistake. Many programmers see testing as a burden, and after coding, it’s easy to skip it. But what they are not aware of is that skipping this step will create troubles for them in the future: instead of being productive, they will become bug hunters with sleep deprivation.

When we look at entrepreneurs, they tend to verify and test everything before execution. This is because they don’t want to ship a product that is not wanted or needed by their potential customers. Before shipping, they always test whether the problem they are trying to solve really exists and if there is a market for that product or not. In this way, they will minimize the possibility of failure.

Main idea: All code lines must be executed at least once.

6. Spending too much time on unnecessary things

Generally, this happens when programmers are obsessive about a certain issue. Doesn’t matter if this issue is important or not. They try to overcome this issue again and again because — as mentioned above — they like challenges. In the end, maybe they will succeed, but at what cost?

The problem? Determining whether the issue really needs to be solved. If they stop to question it and see the big picture, they would never waste their time fixing an issue that is not important.

On the other hand, entrepreneurs know that they don’t have the luxury to waste their time on unnecessary things. Basically, they question everything and make their priorities straight.

Main idea: Don’t waste your time. Use it wisely.

7. Doing everything by themselves

In this paragraph, I am not talking about programmers who work in well-organized companies. If you have a good team leader who knows how to delegate jobs, it’s not an issue. But in some companies — especially small ones or startups — programmers have a tendency to do every task by themselves. They believe that if they delegate their tasks to other team members they will make mistakes. Basically, they don’t trust them.

Eventually, they become overloaded with work and the development process starts to become very slow.

Entrepreneurs are typically well aware that they can’t do everything by themselves. They tend to create an environment based on trust where everyone can ask for help. Task delegation and working in teams can lead to an increase in work efficiency.

Main idea: Trust your team. Don’t forget that everyone needs help.

8. Wrong task separation and management

I believe that the task creation process is one of the most important steps in designing better software. Instead of separating a certain project into smaller tasks, programmers or team leaders sometimes group all tasks into a single project.

In this way, when they start with task implementation, the task itself can look bigger than it really is and they don’t know how to approach it or where to even start.

On the other hand, if you separate one big task into smaller tasks, you can always choose to start with small steps. Going step by step and completing each subtask will lead to completing the big picture and solving the task fully in the end.

Separating a task into subtasks helps in solving complex problems and allows you to manage tasks in a more efficient and simple way.

I believe that every entrepreneur has a “start small” mindset.

Main idea: Start small than extend.

9. Trying to make the first version perfect

Programmers often try to implement everything in the first software version. They believe that without giving everything to customers in the first version, those customers will be disappointed and they will not like the product.

This approach leads to a deadline nightmare and delay of the first release.

However, entrepreneurs tend to strongly believe in the feedback cycle. They follow the principle of “Build it, ship it, iterate it.” They know that they have to ship their product into the market as soon as possible. Once they release the first version, they will listen carefully to their customers and analyze their feedback. In this way, they will make their product better and avoid the implementation of unnecessary features.

Main idea: Build it, ship it, iterate it.

10. Underestimating the scope of the project and time required to complete it (Deadline nightmare)

How many times have you felt pressure and stress because of a missed deadline?

Did you ever ask yourself why you missed this deadline?

I believe, as a programmer, deadlines have always been a nightmare for us. Generally, we tend to underestimate the scope of the requirements which brings us to a point where we can’t accurately estimate the required amount of time needed to complete the project.

I believe that 80% of the development process should be dedicated to establishing software requirements and designing a feature list and appropriate architecture to build the project. The other 20% percent should be dedicated to coding.

However, this is easier said than done. In practice, this is always a challenge for a team of developers.

To a person with an entrepreneur mindset, time is the most valuable resource. Therefore, they define their business scope carefully and estimate their project time in a more accurate way.

Main idea: Everything takes longer than you think.

Conclusion

I’ve seen many programmers who had to rewrite their software from scratch because of mistakes made in the early stages of the development process.

Re-coding software that was created by bad development processes is a waste of time.

Imagine a scenario where the development process has been planned and organized in a better way from the start. Now instead of rewriting the software, programmers could dedicate their time to developing new products or improving existing ones.

I always believe that if we can focus on the purpose of what we are doing and why we are doing it, everything will be much clearer for us. I,f we always keep the big picture in our mind we will develop better and higher quality software that will be designed to fulfill a certain purpose.

Don’t waste your time. It’s precious and your most valuable resource.