Lessons learned about 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?

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.