It’s ok to throw away your code. You will write it even better next time.


Being a software developer is not easy. When I say it’s not easy, I do not only mean its technically challenging, but its also emotionally challenging.

We as a developer can get attached to our code. We write it while our mind thought of creative ways to solve complex problems. The solutions we have are like our brainchild. However we work in a world that is constantly changing. Change happens around us and its inevitable. You can do scrum, mocks, freeze the product specification but a change will always happen and it can happen to an extent that the code you have written for a problem would not be applicable anymore. As far as that product is concerned, you may as well trash that code.

Despite of all that, I am here to tell you that its okay. It’s okay to throw your code and write it again. Yes it requires time and it’s not always justified but every creative challenge you have solved while writing that code has made you a better developer already. It may not do the product any good anymore, but it has already done good to you.

Every time you discover a new or a better way to do something it makes the previous method obsolete. Developers would often create something and keep throwing away/updating their code until they are satisfied with its performance, neatness and efficiency. The earlier in your developing career you learn, that its okay to throw the code and write it again, the more happy you will be working as a developer.

I have had plenty of encounters where I had to throw away the code and write it again, but every time you come back to a problem after a while, you have a fresh point of view and possibly a different approach, which can be efficient and better than the previous approach. Even if its not efficient than the previous one, its definitely neat and organized than previous one. It’s because you have already solved the problem once.

Therefore my friends, if you find yourself in a situation where you probably have to trash your code – archive it, and if you happen to write it again, compare the archive with the newly written code. You will probably find that you have gotten better.

Share your thoughts in comments.

If you work in javascript, these results shouldn’t be surprising

photo credit: /doh via photopin (license)
photo credit: /doh via photopin (license)

Hey Folks,

Javascript has some weird stuff built into it and sometimes when used in conjunction with other languages, it is easier to forget the corner cases that can come with javascript coding.

Here I compile the list checks, that every developer working in javascript should know, so that there are no accidental bugs and also sometimes these can be use to our advantage

Equal operator comparison

Double Equals

Comparison Result
null == null true
null == undefined true
null == 0 false
null == ” (empty string) false
null == NaN false
null == ‘2’ false
null == 2 false
undefined == null true
undefined == undefined true
undefined == 0 false
undefined == ” (empty string) false
undefined == NaN false
undefined == ‘2’ false
undefined == 2 false
0 == null false
0 == undefined false
0 == 0 true
0 == ” (empty string) true
0 == NaN false
0 == ‘2’ false
0 == 2 false
” (empty string) == null false
” (empty string) == undefined false
” (empty string) == 0 true
” (empty string) == ” (empty string) true
” (empty string) == NaN false
” (empty string) == ‘2’ false
” (empty string) == 2 false
NaN == null false
NaN == undefined false
NaN == 0 false
NaN == ” (empty string) false
NaN == NaN false
NaN == ‘2’ false
NaN == 2 false
‘2’ == null false
‘2’ == undefined false
‘2’ == 0 false
‘2’ == ” (empty string) false
‘2’ == NaN false
‘2’ == ‘2’ true
‘2’ == 2 true
2 == null false
2 == undefined false
2 == 0 false
2 == ” (empty string) false
2 == NaN false
2 == ‘2’ true
2 == 2 true

Double equals is not the same as triple equals when it comes to javascript. Notice that some things are unexpectedly true example 0 == “” is true when only compared with double equals vs its false when compared with triple equals. Double equals can somehow be helpful when you want to check if the value is either null or undefined you can quickly just do if(val == null) instead of if(val == null || val == undefined). Also notice that double equals does not check for the data type behind the comparator, example 2 == ‘2’ is true but not true in triple equals.

Triple Equals

Comparison Result
null === null true
null === undefined false
null === 0 false
null === ” (empty string) false
null === NaN false
null === ‘2’ false
null === 2 false
undefined === null false
undefined === undefined true
undefined === 0 false
undefined === ” (empty string) false
undefined === NaN false
undefined === ‘2’ false
undefined === 2 false
0 === null false
0 === undefined false
0 === 0 true
0 === ” (empty string) false
0 === NaN false
0 === ‘2’ false
0 === 2 false
” (empty string) === null false
” (empty string) === undefined false
” (empty string) === 0 false
” (empty string) === ” (empty string) true
” (empty string) === NaN false
” (empty string) === ‘2’ false
” (empty string) === 2 false
NaN === null false
NaN === undefined false
NaN === 0 false
NaN === ” (empty string) false
NaN === NaN false
NaN === ‘2’ false
NaN === 2 false
‘2’ === null false
‘2’ === undefined false
‘2’ === 0 false
‘2’ === ” (empty string) false
‘2’ === NaN false
‘2’ === ‘2’ true
‘2’ === 2 false
2 === null false
2 === undefined false
2 === 0 false
2 === ” (empty string) false
2 === NaN false
2 === ‘2’ false
2 === 2 true

Triple equals is much tighter comparison in javascript, it also checks the data type example see that 2 === ‘2’ is false while its true in double equals

Or (||) operator comparison

Comparison Result
null || null null
null || undefined undefined
null || 0 0
null || ” (empty string) ” (empty string)
null || NaN NaN
null || ‘2’ 2
null || 2 2
undefined || null null
undefined || undefined undefined
undefined || 0 0
undefined || ” (empty string) ” (empty string)
undefined || NaN NaN
undefined || ‘2’ 2
undefined || 2 2
0 || null null
0 || undefined undefined
0 || 0 0
0 || ” (empty string) ” (empty string)
0 || NaN NaN
0 || ‘2’ 2
0 || 2 2
” (empty string) || null null
” (empty string) || undefined undefined
” (empty string) || 0 0
” (empty string) || ” (empty string) ” (empty string)
” (empty string) || NaN NaN
” (empty string) || ‘2’ 2
” (empty string) || 2 2
NaN || null null
NaN || undefined undefined
NaN || 0 0
NaN || ” (empty string) ” (empty string)
NaN || NaN NaN
NaN || ‘2’ ‘2’
NaN || 2 2
‘2’ || null ‘2’
‘2’ || undefined ‘2’
‘2’ || 0 ‘2’
‘2’ || ” (empty string) ‘2’
‘2’ || NaN ‘2’
‘2’ || ‘2’ ‘2’
‘2’ || 2 ‘2’
2 || null 2
2 || undefined 2
2 || 0 2
2 || ” (empty string) 2
2 || NaN 2
2 || ‘2’ 2
2 || 2 2

This works like standard || or operator, if the value of the first comparator does not equals to true it will select the other value. See section truthy value for which values return false when asked for boolean value.

Truthy value

Comparision Result
if ( null ) false
if ( undefined ) false
if ( 0 ) false
if ( ” (empty string) ) false
if ( NaN ) false
if ( ‘2’ ) true
if ( 2 ) true

Hopefully this can help someone have a reference check on what javascript does on == , === and || operators.

Let me know in comments..

  PS: I originally created this post in jsfiddle here (

Migrating Legacy Applications to the Modern World? What you need to know.

photo credit: Nanagyei via photopin cc
photo credit: Nanagyei via photopin cc

Every machine evolves over time and gets to a point where it needs to be replaced or enhanced to fit new and changing needs. There are very less things that are sustainable to change. Software Applications are no different.

As time progresses, as new technology arrives, new ways of doing things become the “norm”, things that were developed years ago start to age, appear old and tacky and calls for migration to the new system.

However migration is not always easy, not always necessary. Biting the bullet of migration is also a challenging task and there are certain things that need to be carefully determined before we jump in migration.

Still reading? Lets take a look at what things we should consider before jumping to migration.

Current System

Life of a software as it is

As we just discussed, software application have an expiry date and though they are kind of working and get some work done, they tend to be replaced with a newer better version of it, specially when new technology comes often. Applications that are end user exposed example, website, mobile and desktop apps tend to expire more early then those backend applications, just because as new user experience techniques comes in to market, the old and not upgraded systems look outdated and are prone to loose business and are not appealing to the user.

So how do we determine if an application is aged and needs to be replaced?

Here are the hints

  • Team spends more time patching things rather than building on it
  • The underlying technology is so old, that we have limited support for it.
  • User complains / User experience becomes unpleasant
  • The application does things inefficiently than the competitor just because of its underlying technology.
  • etc.

Obviously this is not a complete list but should give us the idea that we should start thinking about migrating our system to a better one.

Development to Usability Ratio

While all of the above still holds true, we should not rush to migration. One of they key point is development to usability ratio. The complexity of migration of an application is directly proportional to its usability. The higher the usability, the longer, complex and difficult the migration. Why? Because there is less window of error, more user adaptability etc. Getting back to the point, example if an application is developed for something that is only used by a certain people, its working fine, there are no scalability chances, and the audience (the end user) are perfectly happy, applications like those do not need to be migrated versus an application that is used by thousands or millions of people then chances are over time we will start to see the above mentioned issues (in life of software as it is) and at that time migration becomes inevitable.

Understanding the system. Deeply

Among other things, we also need to understand the existing system deeply. No migration can be successful without understanding what the current system does and how. Only after once we understand the current application properly, then only successful migration can be planned. This plays similar role as requirements play in new software development, improper requirements lead to improper development and similarly not understanding what we are migrating and why, may lead to incorrect choices and inefficient migration

Benefits of the old system. Yes there are benefits

You might say that, when we are thinking about the migration, how can that application still deliver benefits. Yes it can and it does. The application was developed for a reason and chances are it is still doing some things correctly which are crucial to the system those things are the reason that application lasted till today. One should highly recognize it, understand it and should be ready to enhance or at least equate those things after migration.

Value of trained clients.

This goes back to development to usability ratio and this mostly falls under end user exposed applications. Since the application is used for a long time and the fact that it still exists probably means that you have some people that are using and know their way around the application well. No matter you don’t like the experience that they get when they navigate around, but they can and they still get some work done because of existing application. When we plan to undergo migration, those people should be highly valuable. The application is for your clients and should revolve around how its best for them to use it, changing it drastically will impact lot of people, example, Bad examples: Microsoft Windows, Evernote, Good examples: Gmail, slick deals etc.

New system

Motivation evaluation

Migration is a high impact change. However before migration we should analyze the correct reasons behind it. What persuades us to do the migration? One must answer this question before planning a new system. Is because we are doing more support then development? Is it because we look and appear outdated in front of our competitors? Is it because there is a better technology out there that can do the work we do currently, efficiently? Is it because we have a team that is more profound in a different tech/way of doing things? There can be numerous motivations behind migration and we should examine and identify those carefully so we can take right decisions when performing the migration.

Proposals and what does it solve?

After we have evaluated the motivation, its time about proposals, we should evaluate various proposals on migrations, explore different things and ways to do it. Time spent there can be long or short but one should definitely give it enough thought so that when you are in mid-way of the migration, there should be no moments like “Oh we should have done it this way.” Brainstorm, sleep over the solutions, and more importantly, should answer what does it solve? Does it stand behind the motivation that started this whole thing? Does it do anything extra? Does it take away anything? These are key questions and one should definitely think about it.

Try and foresee life

This one is the toughest and not always correct. However, sometimes there is a lot of effort going into this and there is probably a business model around the application, when we try and foresee life of an application, we should consider market trends, consider support life for the technology we plan to use in our proposals, foresee business requirement, product landscape, changing that might lead to migration. The reason we want to have some hint about it is because we want to compare our effort versus benefit.

Effort versus Benefit

Migration of a system to a new one is a big effort not to mention its a high impact change. Migration is not always the best solution and after we have recognized the problems, the motivation behind it, the proposals and have decent idea about the new systems life, we should always also compare the effort related to it with benefits. Are the efforts to be done justified? And we should hear it from more than one team example, something that may be more effort and less value to development team but can be of a high value to finance and accounts team etc. Overall for a product, are the efforts put up together to migrate to a new system should be well justified and well known. One can also not expect the migrated system to replace the old system which has been running for 25 years, point blank perfect the first time nor its going to be built in 3 months. Only when this is well known and established one should think about going forward with migration.

Client training versus user experience

One thing that is easy to miss is effort vs benefit is value of trained client as we discussed above and there change to the user experience. This also applies only to end user exposed applications but, one can be surprised how upset the new users can be when one changes / or take it away peoples favorite thing, remember the start button in windows 8? It can take a lot of effort when we try to find the right balance between our trained clients and perspective new users (who will probably expect the application to have the latest and greatest user experience). Be wise to consider and include those effort when do our comparison of effort and benefits.

Product Vision

photo credit: DaveLawler via photopin cc
photo credit: DaveLawler via photopin cc

Product Vision plays a crucial role when we make any changes to our application and when we develop any features in our application. We have said enough that migration is a pretty big and high impact change. It’s going to use a lot of resources and will take time. While we do this, we should make sure we do not divert from our product vision, the end goal mission and future features that are supposed to come in our application at a later stage. A good way to evaluate this, is to think about a product some years from now from company’s/product managers point of view and make sure that the new proposed system will fit in just fine. As a matter of fact it should be even more supportive of upcoming features.

We should evaluate and make sure that the vision the stake owners have for the entire product will not be disturbed by this new high impact change. We should evaluate the benefits of old system and benefits of new system and rank them against the product vision and make sure the change we are making is for the better.

Example if a product vision is to go native apps for desktop and mobile devices it might worth the effort to migrate the website but we should definitely consider migrating the back-end to a more restful architecture to support multiple clients.


photo credit: 'PixelPlacebo' via photopin cc
photo credit: ‘PixelPlacebo’ via photopin cc

Team is as important as product. Whether you are a one-man army or a group of incredible people, team evaluation is must when going such a crucial change. Evaluation of the team against current system and new system is a must do. Chances are that your team is highly skilled in current technology stack and therefore can provide great support and quick development, but not so adept in new proposed technology stack. This is not bad but it may take team members to adapt /learn and go get better in it as they are in any other technology. This is added effort and should be known across the team. You do not want to end up in a system where one or two person know the most about it and others are clueless.

Decision Factors

photo credit: Jeff Belmonte via photopin cc

So we have spent time and resources to evaluate the need for migration, the proposal of how to do the migration, the product vision, the team. We should be all set for migration right? Wrong. We still have some things to decide before we get to the migration. Cost is always an important point in every application. Does the migration in any way have more costs then previous? Are those costs justified? The answers to this may be quick but one should at least have it covered before jumping in the migration. The other factor is support to the current system. This is most challenging in small teams and migration is tough since the support for current system is dependent on the same team that is working on migration. These should be carefully examined before starting any migration project.

 After deciding, “Yes” to migration.

Ok now you have carefully considered all the factors that we need to for a migration we need to decide how we are going to do it, is it something that needs to be done in full or in parts, they both have some things to worry about, If we go with full fledged migration, the correct time estimation is hard. If we go with partial than we should think about will our clients be able to accept the partial system? User acceptance is not easy with a partial system, no matter how great that partial system is.

One way to ease this is to apply the 80-20 rule when going in partial system, so we get done 20% of functionality that is used 80% of the time. If we are going full development, we should make sure, everyone understands that the deadline needs to be realistically flexible.

After Effect

So what happens after migration, or even in process of migration when we decided yes to migration? Team training happens, each team player who is playing significant role in migration is bound to find something new, that is interesting or scary. Team players are bound to undergo adaption of new technology, software, means of coding etc.. Continuous refactoring happens, when we develop something with new technology, its not always “the best” at the first time, as people learn about it, they find new and interesting ways to do it, but its important to go back and refactor the old code to new beautiful, easy, simple to understand code.


So overall, migration is hard, but doable, we should think about all of this when undergoing or planning migration so that we can take well informed decisions. It should not be scary; it’s nothing less than a project in itself. Share away your thoughts in comments…