7

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 03 '11 at 08: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 03 '11 at 12:19
  • No it wasn't me :)... Maybe... I should remove that line! –  May 03 '11 at 12:21

8 Answers8

6

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 :)

Martijn Verburg
  • 22,006
  • 1
  • 49
  • 81
  • 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 03 '11 at 13:46
4

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.

Joe
  • 216
  • 1
  • 2
3

Is it really a bad thing?

Yes.

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.

S.Lott
  • 45,264
  • 6
  • 90
  • 154
  • 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 03 '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 03 '11 at 11:59
  • If you don't have the right tools, you're the wrong person for the job. – JeffO May 03 '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 03 '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 03 '11 at 13:45
  • @S.Lott You're statement reads as if has to be one or the other when it doesn't. Yes, developers tend to forget that the application has to live nicely outside the IDE, but requesting they use a less-than-best tool stack won't solve that. What's needed is an additional set of tools that allow developers to reproduce deployment environments and processes as closely to reality as possible. – Apalala May 03 '11 at 13:50
  • @Apalala: [Your] "statement reads as if has to be one or the other" Correct. It is entirely focused on the user. If an efficient IDE helps you support the user, then an efficient IDE is good. If an efficient IDE does not help support the user, then the efficient IDE is not well justified. Often, support of users clearly and obviously leads to the fancy IDE for developers. That's good. All I'm saying is that the question **must** be focused on the users first. – S.Lott May 03 '11 at 14:46
3

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.

stijn
  • 4,108
  • 1
  • 25
  • 31
1

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.

JeffO
  • 36,816
  • 2
  • 57
  • 124
0

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.

Ladislav Mrnka
  • 7,326
  • 1
  • 23
  • 32
0

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).

Apalala
  • 2,283
  • 13
  • 19
0

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.

Mike Baranczak
  • 2,614
  • 16
  • 16