Take the 2-minute tour ×

I am a software developer having an experience of 3 yrs. I want to play with latest technologies always. But this is not practical. Because say, I developed a web application in .Net 3.5, now its 30% done. After the release of .Net 4.0, my mind is always goes with .Net 4.0. I think like this, lot of features are in new version, so why shouln't I implement those versions in my application.

When I worked with IT companies, most of them code with very old versions, some body use VB.NET, C, even Classic ASP.

So what might be the points should I consider if I revamp an application?

share|improve this question

closed as not a real question by Walter, gnat, GlenH7, World Engineer, ChrisF Sep 23 '12 at 11:32


If it is just play and no work, then do whatever you want. If you have a deadline, you should most likely stay on the current track. –  user1249 Sep 10 '12 at 7:59
Technologies get updated all the time. So if our app takes more than a year to develop, you'll never finish it if you update it with every technology update. –  superM Sep 10 '12 at 13:46

2 Answers 2

Remember, legacy code is still legacy code for a reason. It works, and it's too complicated and large scale to correctly replace. Sometimes a new shiny version is not the best option. For example, python 3 caused a bit of a stir over compatibility.

In practice, some things to remember :

  • Replace deprecated methods
  • New language optimisations may provide better ways to do something, check the chagelogs
  • Dependecies/Compatabilty, what is your application interacting with?
share|improve this answer
I agree with your answer. As another example, I might add the issues Java 7 had when it was first launched. True, they were corrected quickly, but they were still a pain for those who tried to migrate to it right away (like Apache's Lucene and Solr projects). –  Shivan Dragon Sep 10 '12 at 10:49

I do the following to make my applications more flexible for future adaption of new technologies.

(1) Divide larger applications into multiple components with well defined interfaces. For example if I developed a Windows Form + basic ADO.net application on .net 2.0, later I want to convert the UI to WPF without affecting data persistence, or use entity framework for data persistence without affecting UI, having them in different projects with well defined interfaces will definitely help.

(2) If I know I will want to adapt new technologies some time down the track with a long dragging projects, I allow some tech debts budget, and have comprehensive unit tests. For example, if I want to convert a component's data searching routines to LINQ but cannot be bothered converting them all at once, I'd allow some extra time each time I touch the component, so I can convert a little each time, and gradually complete the change. Unit tests will make sure I have not broken the logic.

In summary, if you feel you absolutely want the new technologies when they become available, making sure components are well decoupled and a good unit test coverage from day 1 will definitely help.

share|improve this answer
