Life was great for Microsoft developers 10 years ago. Companies were happy with going 100 percent Microsoft for their development projects. With ASP.NET on the frontend, .NET middle-tier and SQL Server on the backend, things worked very well for the most part. When they didn’t, developers just accepted that as something that came with territory. Microsoft was all but running the show. Then, at the end of the last decade, Microsoft’s 800-pound gorilla status started to unravel. Maybe it was due to the introduction of the iPhone and Microsoft missing the shift to mobile, or maybe it was because of the proliferation of open source projects, but things changed, and today those same companies need to be persuaded that going with Microsoft Stack is a good idea. This article presents eight reasons in favor of sticking with the Microsoft software stack.

Reason #1: .NET is Still One of the Best

Introduced more than 10 years ago, .NET Framework is feature-rich and thoroughly battle-tested. While it was commonplace to have to combine native development with managed code in the early days of .NET, the vast majority of development tasks are supported out of the box today. Even companies such as Oracle released components that are 100 percent .NET managed code (i.e. ODP.NET managed driver) to interface with their products. .NET API is consistent, well documented and used by millions.

The knowledge-base available via MSDN, StackOverflow and thousands of forums and blogs is massive. In my years of developing in .NET, I cannot recall an instance where I would get stuck for long on a framework bug; each time, someone had already experienced, researched and posted an answer, not always the answer I was hoping for, but still something that moved me forward. With the upcoming 2015 release, .NET Core will be open-source and available on non-Windows systems.

Reason #2: ASP.NET has Evolved

microsoft stack

Looking back at the traditional web-to-database Microsoft stack from 10 years ago, it’s interesting to see which parts survived the test of time and which parts faded away. While the back-end of the Microsoft stack remained pretty much unchanged (we still use the same set of patterns and components, such as Dependency Injection, Tasks, Linq, EF or ADO) the front-end, the ASP.NET piece, saw a fundamental shift from “do it the Microsoft way “ (i.e. Web Forms) to “do it your way and use ASP.NET as a platform.” Today, ASP.NET is an MVC-based framework featuring robust infrastructure for authentication, bundling and routing that integrates with many non-Microsoft technologies such as Bootstrap and AngularJS. ASP.NET sites look nice on a wide range of form-factors, from phones to desktops, and its Web API capabilities make exposing web services a breeze. The framework has been open-source for a number of years, so if you get stuck on a problem, the source is available on GitHub. ASP.NET has changed, and changed for the better.

Reason #3: Simplicity of Web API and Power of WCF

web and microsoft stack

My all-time favorite quote is from Alan Kay who said, “Simple things should be simple; complex things should be possible”. When Windows Communication Foundation (WCF) first came out in 2006, it was anything but simple; behaviors, endpoints, and bindings were overwhelming. So, Microsoft released Web API, an easy-to-use framework that makes exposing HTTP web services a piece of cake. With a few lines of configuration, your API turns into a secure, “industry-standard” web service.

If your use case does not fit the “standard” mold, and you need full control over how your API is exposed over the wire, you can always fall back on WCF. With the myriad of configuration options and hooks, WCF lets you custom-serialize your data, log, intercept, route message, use peer-to-peer and queuing, and much-much more. Web API, together with WCF, delivers on both tenets of Kay’s quote: if you need a simple web service, you are done in minutes with Web API; if your service requirements are complex, “all” is possible with WCF. These two technologies provide a comprehensive coverage of service scenarios and come prepackaged with the .NET framework.

Reason #4: SQL Server is as Solid as Ever

For many years, it seemed like the tidal wave of new development languages, frameworks and patterns came through the front and middle tiers and spared the database back-end. After all, the good old “SELECT” is still as much in use today as it was 20 years ago. I suppose this is due to the fact that many companies view their data as the core of their business, and keeping the integrity of that core far outweighs the excitement of trying “something new” at the database layer.

SQL Server excels at its primary role of a data keeper with a myriad of features for transactions, referential integrity, backups, mirroring and replication, but what sets SQL Server apart from competition is how well it integrates with the rest of the Microsoft stack. For rapid development, there is the Entity Framework, currently in version 6, passed adolescence and delivering well on its promise of streamlining data access. If you need computing power, the .NET Framework is loaded in-process with SQL Server, meaning you can embed .NET code as stored procedures, functions or aggregates without sacrificing performance. Pair that with the fact that SQL Server 2014 comes with in-memory tables, and you can come up with some pretty slick real-time solutions that could not be made fast enough solely with SQL and regular tables. After years in the industry, SQL Server is still on top of my list of RDBMSs.

Reason #5: It’s Easily Testable

So many times, working in corporate IT, I saw software turning into these untouchable black boxes because there were no tests, and nobody wanted to mess with the code for fear of “breaking something else”. Then, I worked on systems that had thousands of tests, and it was a great feeling to be able to tell business that, “yes, we can make these changes,” years after software had been released. The Microsoft stack is designed with testability in mind. ASP.NET MVC has hooks for dependency injection, and in version 5, dependency injection will be included in the framework itself. In the middle tier, it’s a similar story: we use dependency injection to disassociate implementation from the interface, which lets us swap production types with mocks at test time. Even on the database side, there are SQL Server Data Tools that come with templates for testing against the stored procedure layer. Testing is an inseparable part of the software development process today, and the Microsoft stack comes well equipped for this new reality.

Reason #6: Elaborate Support Ecosystem

When it comes to support, it’s nice to have a range of options, starting with community forums and ending with an actual live human being working on-site on your server. The online ecosystem for Microsoft products is one of the largest in the industry. After all, Microsoft was started by Bill Gates, a software developer himself, who saw the wide adoption by developers as the key to proliferation of Microsoft products. That meant providing these developers with lots and lots of support.

Microsoft was among the first to encourage its employees to blog about the technology they were working on, and while the rest of the industry has certainly caught up, the amount and the quality of instructional videos, guides and articles coming directly from Microsoft today is still very impressive. That layer of quality online content is supplemented by a large number of community-based support ecosystems such as StackOverflow, which are not as consistent when it comes to content quality, but are, nevertheless, far more helpful than not.

Lastly, there is always an option to pick up the phone and call Microsoft support. I rarely had to use it, but there were a handful of production emergencies when having Microsoft devs analyze core dumps saved the day. The range of support options is clearly a factor in favor for going with the Microsoft stack.

Reason #7: Microsoft Sticks to their Products

A few years back, choosing Microsoft Silverlight as the front-end for an application seemed like a valid choice, but that’s no longer the case. With the mobile trend in full swing and JavaScript frameworks dominating the front-end space, Silverlight is no longer a feasible option; nevertheless, it’s still supported by Microsoft through 2021. Microsoft sticks to its guns, which is good for those of us who have to make technology choices without having a magic eight ball to tell us what technology trend will dominate the software landscape in the future. Going with the Microsoft stack ensures that time and money is invested into technology that will be supported even if it falls out of favor with the industry.

Reason #8: Visual Studio Umbrella

A decade ago, I was spending about 50 percent of my time working in Visual Studio and about 50 percent in other tools. Today, the split is overwhelmingly in favor of Visual Studio. Microsoft’s vision for Visual Studio to be a one-stop solution for hosting IDEs is coming to fruition with many Microsoft and non-Microsoft products offering some level of integration with Visual Studio. From database development with SQL Server Data Tools to writing iPad and Android apps with Xamarin, Visual Studio provides a familiar developer experience with a consistent user interface. The same can be said about working with Microsoft Azure, a cloud platform encompassing a variety of services from database hosting to mobile services.

Visual Studio obfuscated the complexities of distributed cloud infrastructure making the experience of developing cloud applications consistent with that of developing applications not hosted in the cloud. All the pieces seem to fit together nicely under the umbrella of Visual Studio, making the overall development process very efficient.

Microsoft Stack - The Best of Both Worlds

Today, there are far more choices for writing quality software compared to 10 years ago. That is certainly a good thing because competition forces big players, such as Google, Apple, Amazon and Microsoft, to continue to innovate and not get complacent. While Microsoft has been pushed from the top of the mountain by the tech evolution of the past decade, the company has shown that it’s willing to adapt and is attuned to realities of the current technological trends. ASP.NET embraced other technologies and methodologies, many of them open source, with the original Web Forms fading into history. The .NET framework continues to evolve, breaking new frontiers with libraries for multi-threading and many-core computing. With the imminent 2015 release, the core of the framework will be open-source and portable to non-Windows platforms, which is a step in the direction of inclusiveness and transparency.

These welcomed improvements come from a company that has long-established processes for releasing software that’s tested, documented and supported. Going with the Microsoft stack brings the excitement of working with modern languages and frameworks plus the stability of being backed by a software giant with decades of experience in the development industry. This is why I am recommending the Microsoft stack today.

About the author

Eugene Tsygankov, United States
member since November 11, 2013
Eugene is a US-based software engineer with a proven ability for developing scalable and fault-tolerant solutions. A passionate developer, he uses his free time to code or learn about new technologies. Eugene has been creating successful web solutions for over a decade. [click to continue...]
Hiring? Meet the Top 10 Freelance Microsoft Developers for Hire in October 2016


Seán Fitzgerald
Good post. However, even though Microsoft may still be supporting Silverlight, it has to be accepted that its days are numbered:
Visar Elmazi
From many years of working with Microsoft tools and platforms, I can sum it up in the following line: with Microsoft, easy things are easier, but hard things are harder and often impossible.
Agree overall but MS did mention to developers to stop using Silverlight, aka killing it. I remember reading it somewhere but I believe Silverlight won't be supported in their new Edge browser either... "The commercial media industry is undergoing a major transition as content providers move away from proprietary web plug-in based delivery mechanisms (such as Flash or Silverlight), and replace them with unified plug-in free video players that are based on HTML5 specifications and commercial media encoding capabilities," the software giant said in a Thursday
As a Java developer, I had a chance recently to work with Microsoft products. I was impressed with the quality of the developer tools. However, I see caveats where you still need to pay to get quality tools (Visual Studio, Resharper) that in the Java realm, are readily available (Eclipse, Netbeans). It will be interesting to see how .NET will run on a Linux box...
Diego Caravana
Nothing to question, well written and on spot. I used to be a .NET developer for more almost 10 years (also Visual Basic/C++ before that) and I must admit that it has been a (positive) revolution for Microsoft. Now I completely abandoned any Microsoft product and I've got a reason for this: culture. I had a discussion with a friend of mine about culture vs productivity and I give you the same advice I gave to him: enjoy the "new" Microsoft, more open and more keen to serve its customers than in the past, enjoy the complete and integrated development stack that covers practically everything you can think of, but always and constantly, keep an eye on what happens out of Microsoft world, keep an eye on trends, tools, movements, try them, read about them, chat with your colleagues and friends about them, don't give away your curiosity and freedom in the long term for "bare" productivity in the short term. Don't be fooled by the comfort zone Microsoft is building around you because it will make you lazy and passive, and with time you risk to loose your ability to see the bigger picture, look at things from a different standpoint, and basically bring innovation into your work autonomously and independently from "mother" Microsoft.
Alan Williams
Wrote and article (pro .NET) comparing to Java. CAme about due to .NET going open source
Mario Vernari
I agree mostly, but also I'd add that it depends on what you want to do. My goal is develop: quickly create apps, starting from an idea, throughout the prototype, up to the final (end-user) product. Under this perspective, I wouldn't mind the "possible laziness" introduced by MS (or any other), because the productivity is much greater. I'd also add that I'm a .Net/C#/WPF desktop developer since 10+ years, and I began to develop a small site using Node+Angular+Bootstrap. It's a nightmare: chaotic yet undocumented libraries, few standardization (read as "browsers war") and AGES behind a very well designed UI framework as WPF (Silverlight) is. Still love .Net and whereas possible I use it.
The MS stack was always a viable choice, just an overly expensive one - both directly and indirectly. And it's IMO increasingly so. Many products that just work on other platforms need adaptations to work on Windows. When they do, they're often a few minor or even one major version behind the latest release. Open source which is native to Windows is scarce. You need to pay for most SW infrastructure components, even if those are free on other platforms - and the MS version is usually somewhat short on features. However, IMO one of your statements is blatantly false - that Microsoft sticks to its products - and another one is at least misleading - the one about the elaborate support system. VB6, COM, DCOM, Silverlight are just a few of the technologies which MS effectively killed, after the whole development ecosystem around the MS stack had invested tons into them - and did so without providing a cheap and convenient conversion/migration path. As for support in the MS ecosystem, as long as most software is closed source, it's worthless. I had to deal with paid MS support, and after weeks of trying to fix a problem I didn't get anywhere - dumped the technology, eventually. In the rare cases that you are clearly able to identify your problem as being a software bug, you sometimes (in rare cases) have to wait years until it gets fixed - wait periods of weeks or months are common. In contrast, I never had to deal with such situations with open source software - if a bug I found was serious enough it got fixed within days, and answers to support questions on forums get answered - pertinently - within days at most. The MS stack always looked good for end users and point and click administrators. However, point and click administrators are becoming extinct, as the world moves to an increasingly connected and integrated structure, where (scripted) automation becomes ever more important, and the MS stack, in spite of Visual Studio, never was that attractive for developers, given it's opacity caused by closed source. MS has surely worked a lot towards adapting its technology to this new world, but it is still years behind other systems, for which the philosophy of building complex systems by scripting simple, specialized and small components is a core architectural principle. In the end, it's all about the end user. Whatever stack allows you to give your users what they want, without imposing restrictions on them, is what's best. Ease of administration, ease of development, software and hardware costs all need to be added up to reach a correct conclusion. The way the industry goes says it all, IMO: OSX is increasingly present on the desktop, none of the major public cloud providers, except MS with Azure, runs their infrastructure on Windows, there's practically no push whatsoever behind MS technology except MS. Unless we consider the whole industry but MS being stupid, there must be a rational justification for this - and it's probably not that the MS stack is a good choice.
#7 is super funny. Sure when they release something they support it, the problem is there are too many guns being created as they never fully embraced open source culture and what the Internet was trending. They've always played catchup in that space. I mean seriously, how long did .NET developers have to wait for MVC? WCF was another gun that just shouldn't have ever been created honestly. Let's see, oh, the whole AppFabric Cache thing... gone. Yet another example where the open source community solved the problem better with Redis and now MSFT is adopting it. #4 Sql server? Realy? I can't move away from it fast enough. RDBMS is the wrong choice when building for scale, plain and simple. #2 - Sure it evolved but it evolved way to slowly. Any mindshare MSFT would have had to convert others it lost with web forms. #5 - Any and every language and stack has testing, there is nothing special about .NET that makes it oooooooh so much better. #6 - Having an elaborate ecosystem is not all roses. What it really means to a business is they have to spend more and more money on the shortcomings of the platform to make it do things that it should do. MSDN license for engineers, + Resharper or CodeRush + production server licenses for Windows Server and OMG the mother load, a SQL Server license. At the end of all of that licensing, a business could have hired another one or two developers for the year if they were using open source stacks. And this is why many many many many businesses, startups, and companies don't use the MSFT stack and never will. #8 - From the open source developer community the problem with Visual Studio is VIsual Studio. It A) requires running Windows. That alleviates a wide berth of developers. B) It is 4-6GBs of OMG why is a text editor with intellisense so large! These type of articles don't do anything at the end of days to win any mindshare over anyone. Why? Because at the end of it all there is going to be a bill that *someone* is going to have to pay. So until that is addressed, and the stack is fully open sourced and works on multiple platforms in an idiomatic way nothing is going to change. Now don't get me wrong, I love C# as a language, I really do. If you were going to put anything in your list you should have done that and listed its merits. Here is the thing, if you just LOOK AROUND you'll find awesome ways to solve complex problems that don't cost a dime. So why would anyone *really* want to use the Microsoft stack? Now answer that *honestly* and you'd have a good article. Cheers.
This view is a bit outdated. .NET Core is open source, Visual Studio Community is free and very powerful, 4GB databases are free using SQL Server Express, and you are definitely free to use alternatives, like MongoDB. You can now run .NET apps on Linux and Mac systems (using Mono, or with the newest version, Docker containers), so you don't need server investment. You can also use Visual Studio Code as a cross platform IDE. As an alternative to MVC, you can use open source frameworks such as NancyFX (c# web framework inspired by Sinatra). You can even run .NET on embedded devices. You can, in fact, get up and running on the Microsoft stack without a penny of software investment. In my opinion, the tooling and cohesiveness of the language combined with the newly platform agnostic deploy story is pretty hard to beat.
Mani Gandham
What exactly is an example of a "hard thing" that is so much harder in .NET?
Mani Gandham
Agree with this article - .NET is stronger than ever today and is getting better with VS2015 and the new framework and ASP.NET releases. As someone who founded a startup in 2014 with a massive application that's completely built on the .NET stack, I don't really understand all the complaining about cost. The BizSpark program offers startups 3 years of full licenses of pretty much everything in the Microsoft catalog. If a company can't make money in 3 years to pay for software licenses, that's a different problem. Even the licenses themselves are cheap. The best software and hardware is marginal in cost compared to developer salaries so it's much more productive to use a strong framework, tools and ecosystem to get things done for the business. Visual Studio is the best IDE out there and C# is arguably one of the best languages to develop in. Arguments about SQL server are silly as the enterprise license isn't needed for 99% of the companies out there. Express is free and will do fine and the mid-tier options are pretty cheap (again, especially when compared to developer time). SQL Server is also very powerful but it's not the only database that can be used so it's easy to switch that out if necessary. The .NET stack provides some great tools and cohesiveness that can really improve productivity when putting aside silly ideological debates and decades-old arguments and focusing on what really matters: getting stuff done.
Visar Elmazi
The list is long. Since author mentioned WCF as a viable option. I'm going to give you 2 very simple but hard/impossible task in WCF: - Create endpoint which supports both SOAP 1.1/1.2 (impossible), - Create endpoint which supports 2 or more types of credentials (impossible). - Create endpoint which supports custom enterprise token (very hard) * When I say impossible, I mean finding solution within WCF recommendations, not completely avoiding it to solve it (it doesn't count as solution). And the list goes on. Remember: this was terribly easy in legacy WSE, as easy as adding configuration item. I don't even want to start about the testability of WCF services and components. The same situation is all over .NET and Microsoft stack. With ASP.NET MVC/Web Api, Owin/Katana things have slightly improved at least in terms of testability.
Visar Elmazi
The only reason why Microsoft development community is still alive is the inherent MS tools developer laziness and corporate inertia. Don't get me wrong, I earn my living working as MS tools developer for the past 12+ years, but what I said above is 99% true. All hail to the few exceptions. C# is cool but it's ship (.NET) is slowly sinking.
It is about spending money wisely. Why spend it when you do not have to? Spend it on something important. Look at the companies doing big business a low cost to their customers and see what they use (i.e. Netflix, etc). Is .NET and the surrounding tech horrible? No. Is it the best at improving productivity? Well that depends on a lot. For me, not even close. YMMV
VS is only free if ... well look a the license. What about next year when they change the license? Mono is not .NET Why limit yourself to 4GB of data? What happens when you need to store JSON and query it but still use an RDMBS. VS Code is a text editor. And it is based on non-MS tech. Take a look at what MS Azure supports - all the things that are not MS/Windows based. I wonder why? :) (well, i don't wonder at all). MS is looking outside their box. Maybe it is time for MS devs to too.
I don't see any comparison in the article. Also, J2EE has been replace by Java EE years ago and no, .NET does not compare to it. Well, EF is much like EJB 1/2 (heavy weight and does all the wrong things). Those were killed off in favor of something like Hibernate.
Node? Yes ugh. But AngularJS and Bootstrap? They are awesome - except they are JS. Ugh. They are very well documented and i can find examples very easily. Laziness is not bad, as a programmer. It depends on the form of the laziness. Do i build on the shoulders of "giants"? Good! Do i ignore maintainability and testablilty and etc? Bad.
Mani Gandham
What's more important than productivity? The MS stack provides great languages, a solid framework and the best IDE/development experiences, and the associated license costs are nothing compared to developer time, especially when all the workstations and servers have to be paid for anyway... and it's all free for 3 years if you're a startup. Sure if the tech isn't a fit or if the team is more comfortable with something else then save the time and money and go with the right stack for the job. By the way, Netflix used SilverLight for their streaming until HTML5 media extensions finally got to a stable release.
It depends on how you define productivity. But I do agree - it is very important. I was not saying it was not. I was "saying" people "think" it (Microsoft tools) is (are) the most productive. It might for them. But that being said - you must weight ALL the pros and cons. "The best IDE/development experiences,". This is purely opinion and/or base on how you work. I have used VS since the early 90's. I can show you how it is not true - not for me. For instance, I can download and install the same IDE (install really means "extract zip") on either Windows/Mac/Linux, and have a functioning (UI to Database) application working before someone could even download VS (ok, i have not downloaded it in years as i don't have access to MSDN - sigh another issue - but it is big). Yeah, I know they used Silverlight - but that was a "sucks less" thing. Other than that, of the myriad of tech they have, only one thing is .NET - based that they have open-sourced.
I believe that keepingin the confort zone is more a matter of how the person decides to be than what environment does. If microsoft wants to make everything easy to you, just enjoy it and not get caught in thinking everything is solved. Life still goes on and changes will happen. Then you will be prepared, with or withour Microsofts.
This is so very subjective - everything is somehow "one of the best". MS did wrong for many years - and the iphone has nothing to do with it.
What you're saying is that besides being a viable technical option, the MS stack, at least entry-level, is now completely free. Agreed. But does this make it the best choice? Do you benefit from the richest ecosystem (of free libraries), from the most diverse deployment ecosystem, from the least resource-intensive and most feature-rich platforms? Repeating myself: it's all about the end user. You _can_ charge your customer for building on the MS stack (because entry level isn't what you use for building enterprise systems), but it won't make him happier than not having to pay for third party technology at all, the more so if this also means less work for you as a developer, and consequently lower charges for the customer too. .Net core being open source is not enough. .Net is a beast similar (I'd say richer) to JEE. There are several independent and more recently interoperable JEE implementations - and what's even more important, it _is_ standardized. There's nothing like the most used .Net APIs besides core being implemented alternatively and consistently behaving like the reference implementation coming from MS - ask any Mono user, anything not standardized by ECMA is bug-ridden and behaves differently in Mono when compared to MS's implementation in .Net. This means that programming to .Net effectively locks you in.
I agree with all except #7 (Silverlight). I agree with the facts presented on #7, but not the conclusion. I saw a few technological shifts from Microsoft and I mostly embraced them for two reasons. First, because the new thing was always better than the previous one. Second, there was always a migration path or at least a coexistence path. ASP.Net was very different from ASP, but until today some of my old customers are still running ASP (this is more that 15 years later). VB6 is no longer supported, but COM+ plus components still run. EF with Code First and Migrations is absolutely wonderful, but I'm still able to load DataTables and even use ODBC if I want to. .Net itself was amazing, but I was able to leverage old VB6 / C++ / COM+ components via interop. The new thing never meant throwing away the old thing. Then came Silverlight. I didn't care about Silverlight as a Flash killer, but when it started being promoted as a LOB UI solution, it caught my attention and it made sense. There was a push from Microsoft to bring developers to Silverlight one year and the other year they decided to discontinue it. All this without presenting a viable exit strategy. This meant products developed over Silverlight lost much of their value overnight. Having a deadline in 2021 is not really a good enough thing. What's happening then? Will IE still be around and be able to run it? Will new Windows versions stop shipping IE? It means that probably Silverlight LOB applications cannot simply continue evolving but have to be rewritten, as far as we can tell. Never have Microsoft mismanaged their relationship with developers as badly as they did on the Silverlight fiasco. It felt like a huge betrayal. I understand Satya Nadella represents a way better Microsoft that reminds us the developer oriented one that existed before Windows 8. I'm also aware that open sourcing their stack goes a very long way to recover the trust that had been lost. Nevertheless, from where I'm standing it will take time to ever trust Microsoft to really stick to their products like they did before. Maybe a few years down the road it will be safe to say again that nobody ever lost his job for choosing Microsoft. Until then I'm keeping an eye on the alternatives and I like what I'm seeing on the JVM front with Scala and the Play 2 framework.
Hakim Shabir
defining webHttpBinding multiple times can easily make it possible to have endpoint with multiple version support. what is problem in using SOAP 1.1 (basicHttpBinding) SAOP 1.2 (wshttpBinding)
Rick O'Shea
#1 There is no advantage to .NET over competing technologies in terms of getting community support, examples, etc... in fact the noise is worse for .NET. Clearly "one of the best" is not an objective criteria. #2 MVC? Really? You didn't get the memo that server-side templates are essentially dead technology? So, they "came out with Web-API"? Is that a joke? How many years before this me-too offering got to see the light of day? This was Microsoft's typical 5 year lag of introducing me-too technology. #3... #4...#5... #7... enough. I'm sorry to say this reads like a marketing puff piece and it's of zero practical value in terms of making decisions about platform choices. It's desperate, woefully inaccurate, and as usual there's no attribution to the actual innovators behind Microsoft's me-too adaptations.
comments powered by Disqus
The #1 Blog for Engineers
Get the latest content first.
No spam. Just great engineering and design posts.
The #1 Blog for Engineers
Get the latest content first.
Thank you for subscribing!
You can edit your subscription preferences here.
Trending articles
Relevant technologies
About the author
Eugene Tsygankov
C# Developer
Eugene is a US-based software engineer with a proven ability for developing scalable and fault-tolerant solutions. A passionate developer, he uses his free time to code or learn about new technologies. Eugene has been creating successful web solutions for over a decade.