Lessons learned from rewriting code in my 10+ years as a developer

12 months.

That’s the time we wasted for rewriting our software from scratch.

12 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 will give a start to our new journey was published on the website.

I was working for one of the small cybersecurity company which provides security software for end users and enterprise companies. Those are the software that basically protects users against malware and 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 2 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.


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 metrics were going up, user base was growing fastly 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, product owner of AntiMalware was leaving the team, our CTO was taking the 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 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 developing 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 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 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 interfered. 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 much wrong?

“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 code base to be sh*t to enter the market in the fastest way, but this destroyed our product’s future.

Don’t hesitate to say “this is sh*t” if something is really sh*t. The future of product is more important than your spaghetti code. Focus on to have a sustainable product.

How can we fix this f*cking bad 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 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 resisting 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 sh*tty code and that he can 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. We did this!

“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 be 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.


“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 meet 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 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 to ask these questions 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 expects you when you throw away the code and start from scratch. When you look at code rewriting from this perspective, it’s hurting, 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, than… 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 choose 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 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 not to 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 a shippable code. 

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

Did you think about this?!

Lessons learned.

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 stick to me.

Lessons learned in rewriting software

  • 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 rewrite 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 time 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. 
  • Ensure new product is better than the old one 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 give a sh*t about your rewriting decision, so rewritten version must at least work as efficient 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 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 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 can prepare customers for upcoming product changes. Sometimes we made some changes without informing them. And this caused them to prepare their campaign from scratch. Don’t spend anyone's time inefficiently. 
  • Don’t make dramatic changes in 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 ensure 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 users’ problem. 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 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 the 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 were built right to start with and then properly maintained, why would it be thrown away?

Next garage startup idea: Artificial Intelligence

Just a few decades ago, Steve Jobs and Bill Gates started revolutionizing the technology world by making the impossible — possible. 

They gave us all the chance to enjoy technology as we do it now. Every day.

Their discovery changed all our lives into better.

And it’s not only them. There were many great minds in human history, so when we look back we can remember them easily:

Bill Gates, Steve Jobs, Jeff Bezos, Elon Musk, Sergey Brin, Larry Page, Mark Zuckerberg and so many others…

Their discoveries changed the world and our lives.

While they saw a different future and carried a breakthrough vision of a new world in their minds other people were unaware of it.

So now, let me ask you something.

Are you actually aware of what is happening in the world at this very moment? 
Do you know what is the next big thing that will have a huge impact on our future? 

Like one of my friends said: “New electricity has been discovered”. 

To me, it is even beyond that. It is much more important than electricity. All things that we see now as impossible will be possible sooner than we think and all because of one phenomenon.

Artificial Intelligence. 

I won't tell you AI’s development history here, this is not the topic of this article but I would like to show you the immensely fast development of this phenomena in the past couple of years. 

Let me show you one image that explains everything. 

As you see, the plane is already taking off:)

So the question here is not about the history, importance, development or good and bad traits of AI. The question here is:

Are you ready to fly on this plane?

Today’s investments will have a massive impact in 10 years

Just like other technological discoveries that caused today’s big companies to be founded, AI will cause future’s companies to redesign the world we know now in a much better place for us.

If you read the history of the digital revolution, you can see that every invention had a massive impact on humanity in a way that they made our life easier and better. 

On lead to another.

The developments in the hardware industry caused computer companies like Apple to exist. 

With the rise of the Internet, companies like Google and Amazon entered our lives. 

Web 2.0 transformed the Internet into a better and more interactive place. 

The static websites were replaced by dynamic ones giving the ability to everyone to contribute and actively participate in the evergrowing Online world. 

So there you go, Facebook and Twitter were born.

As you can see, one developed on another. So, what’s next?

Why this headline “Next garage startup idea: Artificial Intelligence”?

All big ideas started small. The garage idea is a symbolic representation of this concept. Now, garage stories stay behind today’s biggest technology companies and inventions. 

Revolution begins now

We are just at the beginning of a major revolution. 

You can be the next Bill Gates or Steve Jobs of the future… Who knows?

The point is that AI brought many opportunities to all of us. To be able to change the future we have to wake up and adopt this technology. We need to invest our time to learn it and embrace it. As compared to before where just a few people were changing the world now we can build the future together.

There is an important fact that you should never miss. This is the fact that we live in an age where what you do today can have a massive global impact in 10 years. I don't know who will be the next big giant companies in 10 years, but I do know that artificial intelligence will be in the core of those companies.

Take action and be part of the transformation 

Doesn’t matter who you are. This is a call for everyone, including me who wants to be in that AI plane and design a new future. I don’t know what you are working on right now and I don’t know what your goals are but I am asking you again.

Are you ready to fly on this plane?

This is a call for:

  • Governments, bring AI in every field of your country. Transform every field to catch the future. Put AI to your education system and educate people about AI from now on.

  • Students, AI will lead our future so don't miss it. Start from today to catch the wave. When you finish school, companies will be looking for data scientist and AI specialist. So be ready.

  • CEOs, thinking about what is next big innovation for your company? The answer is clear, AI. Start now and invest in it. If you want your company to be alive in the future, embrace AI.

  • Investors, asking yourself where to invest your money? In case you don’t know, please read the article again:)

  • Product managers, thinking about how you can level up your product? Use the beauties that AI offers you and make your product raise up even the market itself. 

  • Developers, what is next big thing you can learn and which skills you can acquire? Data, machine learning, deep learning etc. Don't stop. Go for it. Software development as you know now will be changed sooner than you think. 

  • Doctors and researchers, what do you think about having an extra super smart brain and help millions of people worldwide? AI should be one of the top priorities in the health industry.

  • Academicians, empower young minds to enter this field as soon as possible and together become pioneers of your field by using the power of AI. 

  • Entrepreneurs, looking for the next brilliant startup? I don't know what you are passionate about and what you are trying to accomplish but I do know if you don’t apply AI on your next project, you will miss the flight and you will not go far. 

  • Marketers, you know that marketing is a science. There is something new happening in that area. You can leverage AI for your area. Don't stop, go for it.

and so on and so on…

This list can be long but I believe you got the point. Everyone can take advantage of AI for better purposes. 

This is something that you can apply almost everywhere and it just started transforming our future. 

So, wake up and take action. Be part of the transformation and let’s change the future together. 

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

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 than 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.


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.

If you are looking for a startup idea, please stop!

Don’t focus on the solution, focus on the problem.

Are you looking for a startup idea but you don’t know how to get a great one?

Here is my answer to you:

Stop my friend!

You are going in the wrong direction. Don’t make the same mistake as everyone usually does. Don’t wait for a startup idea to find you.

Trust me on this one. You don’t need it.

You don’t have to look for ideas, just look for problems around you.

Instead of spending time wondering in your mind to find that hidden and unlocked idea, open your mind and start noticing problems you or people around you have. As Paul Graham said:

The way to get startup ideas is not to try to think of startup ideas. It’s to look for problems, preferably problems you have yourself.
-Paul Graham

Most of the people that aspire to build companies, become entrepreneurs and active players on the startup scene start first with a hunch that tells them: Go! Look for an idea!

They think this is the ultimate truth and path in order to reach their final aspirations. Day by day, they spend their time wondering what a great idea would be perfect for their startup.

Let’s take a look at a real example.

Airbnb is one of the most successful startups in the past couple of years. Before Airbnb people had limited choices when it comes to booking and renting but now with Airbnb, they have unlimited choices when it comes to this matter. Founders of Airbnb created a simple and user-oriented platform where every individual can easily rent and book a place.

As you can see the main idea behind a startup is to solve a problem that people have. It has always been like that. But most of us tend to miss that point.

So maybe a good exercise and a starting point for all of us would be to ask these questions to ourselves:
  • What problems do I have?
  • What problem do people have?
  • Which problems can be solved?

Why is it so important to work on problems that people have?

It is so important because it ensures that the problem really exists. And when you have a problem, you can start to think about how to solve it.

Somehow, nowadays the most common mistake we make is to solve problems no one has and somehow in this process we lose ourselves in the belief that this idea will be loved by everyone.

Sounds good. Doesn’t work.

Is it important what you think is good or what market needs?

Don’t think that your idea or product is original just because you and your friends think it’s amazing.

Ok, it can be a good idea but is there a market that waits for this innovation of yours?

Focusing only on the idea and not questioning what kind of problem we solve generally causes us to create products no one wants. These type of product we call vitamin products which are “nice to have” but actually there is no need for them.

What we really want to build is a product that solves a real problem. These products are called painkiller products which are in the“need to have” category.

Not having a painkiller product is what brings most of the startups to failure.

So, why do startups fail?

Quake Capital shared cbinsights' research about why startups fail and it’s great. Please take a closer look at why you should stop looking for ideas and start focusing on problems. As you can see in below image the number one reason startups fail is that there is no market for their offering.

Source: https://www.statista.com/chart/11690/the-top-reasons-startups-fail/

Let’s say you have an idea that solves an existing problem. Is this enough?

It’s not enough. There are other things you have to consider as well.

First thing first. Don’t check if your idea is good with your family members or friends. Probably they will say it’s a really good one and that they would use it.

Seriously. Don’t check your idea like that. Every mother believes her child is the best and prettiest.

So let’s see what you can do to avoid this.

Do lots of research before you start investing your time and money. Check first if someone else thought about the same idea you did. So, open google or your preferred search engine and start researching.

During your research you should keep in mind two things:

  • Does this problem really exist?
  • If yes, has someone already find a solution?

Answer these questions with your research.

If your research confirms that this problem already exists and people are talking about it and search for it, it means that you are on a good path.

Now, if there are already solutions on the market for your idea don’t be sad or scared because of that. Don’t give up just because someone else acted before you. Actually, you should be jumping in your room because your idea has been verified by the market since you have competitors already. This is always a good sign and it brings me to a very important point:

You should avoid creating a market that doesn't exist.

By trying to create your own market you will be the only one that solves a problem. This is certain. But is there any gain? Are people interested to be part of that market? I believe no. So your gain will be equal to zero in the end.

When you confirm with your research that the problem exists and that there is an already existing market for it, you also start noticing companies that already pursuit with this idea. These are your competitors.

Again I repeat don’t be disappointed. At this point, you should start analyzing each one of them. Check how they solve this problem, do they have a similar approach as you envisioned, their customer's feedback and the overall success of the company.

You should also analyze companies that were part of this market but they failed for some reason. Their story can help you a lot in learning from their mistakes. Remember you should check both sides of the coin. The success stories and failure stories and craft your concept.

Now, once you gather all the needed info at the end you should ask yourself:

What is the unique thing that differentiates me from the rest in solving this problem?

As usual, there are always alternative ways for everything. This concept is not an exception. There is one particular alternative to this method that I liked a lot. It has been confirmed by buffer CEO Joel Gascoigne. You can read more about his approach in “How to validate your startup idea”. An amazingly creative and simple approach that helped him verify his idea and eventually run a successful startup on it.

Now, at the end what should I say?

Time is our most precious thing. Before we spend it, we should think through and try to use it wisely. Don’t spend your days or years executing an idea that either doesn't solve anything or that doesn't have a market that needs it.

Before execution, check if it’s worth it and always remember:

Create a product people want.