I work at a large healthcare organization as a mid-level software developer. I have over 10 years experience in the IT industry using Microsoft technologies (ASP.NET & SQL Server).

When I go to conferences, code camps, .net user group meetings, I hear of all kinds of new tools and technologies: MVC, LINQ, Entity Framework, WCF Web Services, etc. I guess you could say I'm in my comfort zone using the same old stuff from asp.net 2.0. I use typed datasets for my data access layer. I use web forms and feature rich server controls with master pages. I know how to use plain old SQL and create queries in my typed datasets to get at data my applications need.

Throughout my career, I'm always sensitive to not become obsolete with my skill set. What I currently use works fine and my development time is fast. But I'm concerned that if I were to be laid off, I would be asked in interviews how many MVC apps I've written. Or how I am with LINQ or WCF web services.

I know that it doesn't matter how many conferences, books, or videos I watch on some new technology...I have to implement/use it or it simply won't sink in. Also, managers who interview don't care how much someone reads up on something, only real use and experience with a technology.

I have a new project to write. I've gone to my manager and have asked for additional time for the project for learning/implementing technology I may not be familiar with. Our organization encourages its employees to "learn and grow" and to continue are education. But I always get resistance when I ask for more time to ramp up on something new to implement. My manager is asking for concrete business reasons for implementing these new technologies. I don't have business reasons. My reasons are because I don't want to become obsolete. I could say it would make the project more maintainable in the future by other developers since at some point people could stop using these older technologies, but that' about all I can think of. Does Linq/Entity Framework/MCV apps perform better? So much so that the customers (users in departments I'm creating this app for) need? I doubt it.

I'm interested in you guy's thoughts on this. Do many of you have similar plights with trying to use newer upcoming technologies? I doubt I'm on the bleeding edge of technology, either. Are there "business reasons" that you would bring to light for using these technologies?

Thanks in advance! Sorry for the long wall of text.

  • 16
    If you think LINQ is "new", you're already getting out of date. Commented Apr 5, 2012 at 19:32
  • 2
    FrustratedWithFormsDesigner is correct, LINQ is pretty "old" by now. Of all the things you mentioned, you should definitely start using LINQ. It's not difficult to get into and it can really clean up a lot of your code. Commented Apr 6, 2012 at 0:18
  • 1
    Joel's still relevant article is joelonsoftware.com/articles/fog0000000339.html even after 10 years (mainly the bottom part) Commented Apr 6, 2012 at 7:56
  • 1
    But I always get resistance when I ask for more time to ramp up on something new to implement.: How much time are you asking for? I'm not sure if you knew this, but companies need to make a profit to stay alive.
    – Jim G.
    Commented Apr 6, 2012 at 12:13
  • 1
    @JimG. I told my manager I could do the project in 6 weeks, but asked for 8-12 weeks with using new technologies. We are a non-profit hospital organization. And I've done 4-5 apps using old technologies I outlined above which I'm very familiar with.
    – Darren
    Commented Apr 6, 2012 at 16:25

8 Answers 8


Not becoming obsolete sounds like a pretty good business reason for using new technology. It flows both ways. You don't want your skill set to become outdated, but your boss should also be concerned that he might not be able to find employees willing or able to work on outdated technology. If the majority of developers and employers leave an old technology for a new one that might be reason enough for your company to do so too.

To specifically answer your question you should evaluate each one of those technologies individually to see if they meet your needs. I'll give you my take, but you really need to spend at least half a day to research and evaluate each one them as they apply to your specific business needs.

LINQ: This is something you can use, even without entity framework. LINQ is a technology used to work with collections of data, and you can use it in your applications even if you don't use it for loading that data from the database. Do yourself a favor and learn how to use lambda expressions and LINQ extension methods. It will save you time, make your life as a developer easier, and reduce the amount of code you need to write.

Entity Framework: This seems to be the future for data access in the Microsoft world. Most of the new frameworks, technologies, and tools from Microsoft are designed to work with entity framework. It's not perfect, but it's a lot nicer than using datasets, especially if you use LINQ to entities. One big business reason for using entity framework is that it reduces the amount of SQL code you need to write, as the framework will generate it for you. In my experience, most developers aren't very good at writing SQL anyway (and most companies don't have a dedicated DBA), so for most applications entity framework should make things faster and more efficient. Entity framework will also let you work with POCOs which have less overhead and are easier to work with than datasets.

MVC: This one might be hard to justify, as most applications might not benefit much from it. Based on the latest job postings I've seen, MVC is still in the minority (although it is gaining ground fast). For a most business applications MVC might be overkill, and dragging a few controls onto an aspx page will suffice. MVC has a learning curve to it, and to be productive and get the most out of it you really have to understand HTTP, HTML, CSS and JavaScript. MVC works well when you need to have a really customized web application where performance is a big priority. If that is not the case, and the employees don't have much experience with it, there probably isn't a strong business case for using it.

WCF Web Services: Do you have to provide data to remote client applications? WCF is probably the way to go. Are you just writing a web application that will run on the same server or local network as your database? Don't use WCF, you don't need it and it will only serve to complicate things with needless abstractions.

In short, use a new technology when it makes sense, and take the time to find out when that is. It takes a lot of time to learn new technologies, but it shouldn't take much time to evaluate them and learn if they will benefit your specific situation. This is something the higher ups in your company should already be doing, but if they aren't then you need to do it and then take the time to educate them on what you have learned.

EDIT: After reading your comments above I had some more thoughts. It might help if you are able to take an agile approach to developing this app and break it up into different components that can each be fully completed before moving on to the next one. Your manager may be more likely to approve of you taking the extra time for new technology if he's able to see that you're making steady progress along the way. Also, you don't have to choose between writing the entire app in MVC and Entity Framework or ASPX pages and datasets. It's possible to use both in the same app using a hybrid approach. You could start out using MVC and entity framework for a few of the components. If things are going well and your boss is happy then you could continue, but if he feels that it's taking too much time you could develop the rest of the app with ASPX pages and datasets.


While you should definitely learn some of the new MS technologies, my recent experience learning about things like WPF and WCF has made me a bit more cautious about learning the newest MS APIs.

Now, LINQ is a major boon to productivity that you should definitely be using; the nice thing is that you can introduce LINQ-to-objects piecemeal in all sorts of random situations, with or without the actual query syntax (I commonly call Where() without the from-select syntax, as it is often shorter.) The mathematical dual of LINQ, Reactive Extensions, is something you should be aware of, although I am still struggling to find a really good use case. Likewise, all features of C# 3/4/5 are useful so you should study them and watch for places where they will be useful, even as you continue using the "old" BCL stuff.

However, I'm going to take devil's advocate and suggest that the very newest big MS libraries, such as WCF and WPF are not necessarily worth learning at all.

The primary reason is that they are huge, and not especially well-designed (the former being a symptom of the latter). I briefly blogged recently about why WPF sucks. As for WCF, the whitepaper makes it sound like it will easily interoperate nicely with "Java EE server running on a non-Windows system" and "Partner applications running on a variety of platforms", but the truth is that WCF APIs are very specifically SOAP-oriented and have very limited support for non-SOAP protocols. MS could have easily designed a general system that allows pluggable protocols, and maybe the capability is hidden (undocumented) in there somewhere, but as far as I can tell they chose to design a much more limited system that can only do SOAP and limited HTTP (as long as your message body is a serialized .NET object, IIRC). I researched Entity Framework more briefly, but noticed some complaints that it was incapable of supporting some scenarios that the (much simpler) LINQ-to-SQL can handle out-of-the-box.

IMO the design of all of these libraries are fundamentally flawed because they use a lot of components that are tightly coupled to each other, a dependency graph of the classes in each framework would probably be huge and look like a jumbled mess of scribbly lines. And even if the design were good, we would not be able to tell because there aren't public architectural documents that delve into the lower-level details, and the MSDN docs for the most part aren't very good (they tend to get less and less helpful as you look at lower and lower-level classes.)

The sheer size of the libraries also seems like a flaw; I have learned over 20 years of programming that simplicity is a virtue, one that Microsoft has never valued.

But you might ask, "so what"? Well, with such big libraries you might never feel like you really understand them. That means that when you want to do something outside the use cases for which Microsoft specifically designed WCF/WPF/EF, you're not going to know how, and it is possible that no one outside Redmond will know how, either. And when something goes wrong, you will have a hard time figuring out what went wrong. And 15 years from now when Microsoft has moved on to their next next-generation API, no one is going to enjoy maintaining software built on a foundation that is so poorly-understood.

Also because of the largeness and complexity of these new APIs, the cross-platform alternative to .NET, Mono, has poor support or no support for them. You'll probably have little difficulty using your typed data tables on Linux or Mac, but Entity Framework? Forget about it. I wouldn't be surprised if Mono never supports it.

I have used LINQ-to-SQL in a new project and it's not bad. In some ways it could be better, but I think the developer experience is substantially better than ADO.NET. One significant limitation: L2S is easiest by far if you modify tables in "connected" mode, unlike the old ADO.NET which was specifically designed to work without an active database connection. Anyway, since LINQ-to-SQL is (according to Mono people) a quarter the size of Entity Framework, it's a shame that MS decided to quit working on it.


I have developed Microsoft Windows based software for more than ten years before I switched completely to free and open source software and gave up MS development. I am writing this from long personal experience.

Apart from other reasons due to which I switched to FOSS, the reason related to programming is that there is hardly ever any justification for learning/implementing proprietary technologies. The crux of the matter is that Microsoft is not committed to supporting each and every piece of technology it has ever distributed. All too often MS introduces deprecating changes to its APIs and frameworks. This renders much of the existing APIs as well as their knowledge obsolete. Indeed, they even do this with their end user software. For example, MS Office 2007/2010 is not similar to MS Office 2003, and more importantly, Windows 8 is a radical departure from existing platforms. In particular, there are bound to be all new APIs and frameworks for Windows 8, and you will not be able to support Windows 8 (in the future, if not now) without implementing those. This trend of constantly rendering existing technologies and knowledge obsolete and more importantly, unsupported, is one of the core business reasons for going on implementing any new technology that MS releases. If MS stops supporting the old technology tomorrow, where do you go with the legacy code? Where do you get updates for it?

Please also note that I am not asking you to drop MS development and switch to FOSS. I only wanted to help you here, having had a long experience in MS technology.

  • 2
    While there are certainly things that Microsoft doesn't do well, you can't say they don't support their stuff. They're still supporting MFC, which they released in 1992. In fact, they released a major update to it in 2008. That's a pretty amazing level of support. Also, old technologies still run on the newer operating systems. They may not look as good as newer apps, but they still work.
    – 17 of 26
    Commented Apr 5, 2012 at 20:16
  • 1
    Oh, and Microsoft also created an entire new language (C++/CLI) to enable developers to re-use decades of C++ code with newer technologies (C#/WPF).
    – 17 of 26
    Commented Apr 5, 2012 at 20:18
  • 2
    Problem is, those old technologies are not updated by MS to provide new features. You remain stuck with them. If you want all the new features, you have to move on to their newer APIs.
    – user51292
    Commented Apr 5, 2012 at 20:23
  • 1
    That's not true. The MFC feature pack from 2008 added modern UI controls such as the Ribbon from Office 2007/2010. Also, C++/CLI gives C++ code a way to call .NET libraries.
    – 17 of 26
    Commented Apr 5, 2012 at 20:33
  • 2
    Is MS going to provide Windows 8 features in MFC? And what about the type of things asked in the original post here?
    – user51292
    Commented Apr 5, 2012 at 20:41

I think the main thing to do is figure out what the concrete benefits of adopting a newer technology are and present those as justification for doing so, rather than your own desire not to become obsolete. You say that you don't have "business reasons", but surely you can find some with research...

Maybe moving to a newer framework/technology allows you to design apps that run with a smaller memory footprint, are more responsive, are faster to deploy, etc. Those would all be concrete business reasons. So, I guess I would suggest pulling back a little and investigating "why did people start using MVC, LINQ, Entity Framework, WCF Web Services, etc in the first place?" Answer that question, and you'll probably find some business justification to offer. Whether or not it's sufficient to drop the "go with what works" philosophy is another matter and may be a function of your salesmanship.

  • I suppose you could ask "why did people use Silverlight", and you can also ask "why do people no longer use Silverlight". Answer both those questions to get an insight into the state of play in software today.
    – gbjbaanb
    Commented Apr 6, 2012 at 1:21

What I currently use works fine and my development time is fast

Unfortunately, Microsoft doesn't give a fig for this, what matters to them is to sell you more tools. That means creating new technologies, which means you have to buy more training too! Win-win, for them.

For you, it means a constant battle to learn new things, and once you've started to get good at them and your development productivity is as fast as it used to be.... there's something else to learn and you have to start all over again. There's a reason software is generally poor quality, its because its not treated like the 'professional' services like engineering or architecture, they keep the things that work. We throw them away and start from scratch all the time.

But, this poor state of the world doesn't help you. So my advice is to use a combination of "keeping up with technology" and "don't want to fall behind". Your boss should be concerned with recruitment, if you only did VB6 dev, then you'll find it quite hard to recruit new staff (well actually you'd probably find it really easy, all the guys who liked VB6 will flock to you, but that's another matter).

I'd say that you need to check whether new technology x would help you do future development even faster - then it stops being a personal or simply wasteful task, and becomes a business-improvement task, companies are always going on about how R&D "innovation" helps them stay competitive.


As a developer, you have to push management to use newer technologies and justify it by demonstrating the benefits and value it will bring to the company (e.g. performance, features, ease of use, maintenance). Management is usually averse to change and won't justify changing anything unless it brings some added benefits over what is currently in use.

Using some new, "bleeding edge" technology is also good for the marketing team so that they can market the company as being on top of current technology trends and not stuck in the past using legacy technologies and platforms.

  • +1 for mentioning the marketing angle as well. That can certainly help sell managers on adoption of something. Commented Apr 5, 2012 at 21:34

You are going to need to do some smaller projects in your spare time if your company will not let you learn on theirs. The learning you do in your private time should give you the business case to make to your boss about the improvements in the newer technologies. If you are currently feeling too burnt out from your daily work to learn new stuff, you may need to take a few weeks' leave, rest for a few days, then do an intensive training session for yourself.

Say what you will about Microsoft, one thing you cant fault them on is making developer tools and training available at no cost. Install the latest Microsoft Web Platform installer on your PC, then fire it up and wait to see all the free development tools and platforms you can try out. Visit the MSDN, ASP.Net and Channel9 web sites and check out their tutorials.

I am still developing in ASP Classic if you can believe it, but with a few hours of persuasion have convinced my boss that .Net is the way to go, by making a business case for it. Next year we begin transitioning our legacy code.

  • you're kidding, MS makes a ton of money on its dev tools and training. Last reports, Server & Tools provides $4.25 billion to the business. Watch your boss buy Visual Studio Professional or Team Edition, and go ask how much it cost. Its good, but expensive.
    – gbjbaanb
    Commented Apr 6, 2012 at 1:19
  • @gbjbaanb - My point was not that MS makes no money off development tools, go read again carefully. I was just saying that they offer many free tools (e.g. Visual Studio Express edition, WebMatrix, IIS 7.5 express, SQL Server Express and Compact) and lots of free training (MSDN, Asp.Net site etc), especially compared to other platforms. Try and find some free tools or training on how to make a program integrate with ACCPAC - go on, I dare ya. Also compare the price of Visual Studio Professional with Borland RAD Studio Professional.
    – Bork Blatt
    Commented Apr 9, 2012 at 14:20

The best way to justify the use of newer technologies is when you can show that they improve developer productivity. This means more work done at a lower cost. That's the only thing that matters from a business perspective.

Some examples:

  1. Tools that make it easier for the developer to work
  2. Libraries that provide features which would otherwise have to be developed in house
  3. More powerful languages that can result in code that is easier to read or fewer lines of code that need to be written/debugged

Not the answer you're looking for? Browse other questions tagged or ask your own question.