I almost always choose the Microsoft stack over anything else because of Visual Studio, the available tools and how easily I can get started programming with a particular new framework.

Please, that was only an example; it may be other stacks for other people.

I am not building real time, mission critical apps where a nuclear power plant would explode if my app didn't perform well... More like small business apps.

But when I tell this to other programmers, even before they react, I feel I might have embarrassed myself - choosing a stack because of the IDE?!.. ease of setup?! I feel the "pros" choose the stack by other "important" things I am not aware of and in the grand scheme of things, IDE and ease of setting up dev env don't matter much. I feel it is a little immature to do what I am doing.

Is it really a bad thing?

Note that I also choose the Microsoft stack because of a lot of other reasons (C# is an amazing language and .Net is an awesome platform).. but IDE, tools and dev env setup play a big part for me.

Also note that I am a 1 man dev shop, very occasionally 2 or max 3.

  • 1
    I do it all time for Netbeans – rgksugan May 3 '11 at 8:23
  • "Lazy and impatient" - lmao! An old boss of mine once asked a candidate the old chestnut of "What would you say is your greatest weakness"... lame right? You should have a stock answer that really makes you look good right? The answer..... "Well, sometimes I am a little bit lazy". He didn't get the job. It wasn't you was it? :-) – ozz May 3 '11 at 12:19
  • No it wasn't me :)... Maybe... I should remove that line! – user19224 May 3 '11 at 12:21

Tooling support is a major factor in the adoption of a language based technology stack. It shouldn't be the only factor that you consider, it's always a case of 'Horses for Courses'.

But sure, I've seen cases where it's been more sensible to choose the language with the tooling support (Java) over the language that might be natively better at the task at hand (Scala). This was for a large team doing lots of XML processing on the JVM. Scala would've been the better native language to choose, but at the time it's tooling support wasn't great, so Java was chosen.

Are you productive? Then don't feel bad :)

  • I wouldn't go as far as choosing a language because of the tools. The best tools may not be available for a particular language, but good-enough ones will if the language is mature enough to be considered for a project. – Apalala May 3 '11 at 13:46

Choosing the right tool is a combination of your effectiveness with it and its suitability for the job at hand. If the tool you are most efficient with can handle your current problems, then it doesn't make sense not to pick it. I would question your wisdom if the customer wanted you to develop something like real time control code for a robot/car and you chose .NET + VisualStudio.

On a side note, I think you will find developers on other platforms prefer their platforms for the some of same reasons you prefer yours. For example many 'nix devs look at the command line and it's tools a major advantage over windows. It's really a matter of experience, and familiarity.


Is it really a bad thing?


20% of life-cycle cost (or less) is development. The other 80% is operation, maintenance, adaptation, etc.

Further, the data being processed transcends the application -- when an application is retired, the data is migrated into the new application. We want our data backed up more than our code base. Applications share data well, but the data itself is irreplaceable.

Focus on IDE ignores the real value that you're creating.

  • 1
    You don't think that an IDE and tools which make the 20% development easier will also make the 80% post-development easier also? – Carson63000 May 3 '11 at 11:42
  • @Carson63000: It might. But focus on development cost completely ignores the real value that's being created. If you want to choose an IDE or "stack" because it helps manage the user's information over it's entire life, then you're making a sensible decision. It should not be about you, it must be about their data. – S.Lott May 3 '11 at 11:59
  • If you don't have the right tools, you're the wrong person for the job. – JeffO May 3 '11 at 12:15
  • @Jeff O: The question isn't the tools. The question is the nature of the job itself. If the job has to be focused on the users, and the user's ability to manage their data. Tools -- in support of users -- make sense. Tools in support of developers don't make sense. The distinction is merely one of clearly articulating the ultimate goal. – S.Lott May 3 '11 at 12:22
  • Couldn't agree more. I deal with some Russian sites on public procurement daily, and each of them was built keeping 50% ease of development and 50% 'modern' look and feel in mind, leaving 0% for meeting user's needs. – Roman Grazhdan May 3 '11 at 13:45

I'm in the same boat. Given that I can get things done like 50% quicker with VS than with any other IDE, one reason being that I'm used to it, another one that it's just good. In the same way I'll always pick NetBeans for Java.

I don't feel embarassed to justify this. Especially not to customers. Why would I go with something else that slows me down? Or has less features? I only pick other IDE's if my prefreed one is not available, eg for some Dsp devices etc. But still then I'll do the editing in VS.


You've focused on ease of setup, but it wouldn't take long to need to consider: deployment, maintenance, upgrade, flexibility, and can it create software to do the job (That's what it's all about.). If you couldn't complete and maintain one of your projects, you'd be picking a new IDE.


If you want to develop in .NET Visual Studio is natural choice. There are some other possibilities like SharpDevelop / MoneDevelop but that's probably almost all. I'm almost sure that once you choose .NET as your development platform 99% developers expect Visual Studio as IDE.

This is the difference for example with Java where Eclipse, NetBeans and commercial IntelliJ Idea are used very frequently and many developers have some experience with all of them.


There aren't any reasons not to choose the tool stack that makes you more productive. Being more productive while coding means that more time will be available for the non-coding aspects of software development.

When you're working on a team you do have to set rules and procedures for code integration. At the very least, a coding standard must be agreed upon and be strictly respected by all participants (with the help of tools or without). Then, several processes must be automated early on to make sure that they're not left out of the overall process:

  1. Unit testing.
  2. Release management.
  3. Packaging.
  4. Creation of test data.
  5. Creation of test environments.
  6. Deployment to test environments.
  7. Functional tests.

There are tools to help with all that (scripts can do parts of the job), and once adopted they become part of the complete stack.

S.Lott does make an important point in his comment. The most recurrent among the nasty pitfalls in software development I've encountered is with developers so in love with their IDEs that they produce programs that only run within the particular IDE.

But if you make the provisions for the out-of-IDE processes I mention above, everything should go well. If you don't, you risk reaching a point in which nobody knows what must be done to make the program run without help from the IDE-stack (except perhaps for rewriting the whole thing).


A well-designed framework should play well with others. If there's a framework that can only be used from one IDE, I consider that a design flaw in the framework. So yeah, I have no problem with choosing a stack because of the IDE support - but this takes me in a direction completely opposite to yours.

I don't follow this rule religiously. If I need to write a native Mac OS app, I use Cocoa and Xcode, because those happen to be the right tools for the job.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy