I think that the likelihood that a task will be carried out under pressure has to do with how immediately beneficial the results of the task are (long-term goals vanish in the immediate firefighting activities) and how easy it is to carry out the tasks (low-hanging fruit are first). Most teams are under pressure most of the time these days, and have enough trouble on their minds without extra tasks that are future-looking and hard to perform.

BTW: When an organization complains about "lack of discipline", it is my experience that it's universally because they have placed unreasonable time constraints on the development team. When the team scrambles to get work done and cut corners in order to hopefully hit *some* of the dates, they will make mistakes. Some are in code, some are in process, some are in personal relationships. When the pressure is severe, people start to crack and crumble. The discipline issue is a way that managers blame the developers for trying to comply with the unrealistic dates and procedures that the managers made for them. "You tie huge burdens to men's backs but you do not lift a finger to help them" is a pretty good description. But that's for another rant.

I want my IDE to make it easy to do the right things. I like Eclipse becuase it makes unit testing and refactoring very easy, and these are things that need to be easy. People need fewer reasons to abandon testing and refactoring when they're in a crunch. I like dynamic languages because they make it easier for me to get that first step "make it work" done, and then make it easy to reflect on the code I've written. Refactoring tools for Python (Bicycle Repair Man) help even more because they make some refactorings easy enough. The libraries are easier to understand typically, and the live command line environment lets me experiment and figure out what the libraries really do. These are the kinds of help that people under pressure really need.

Some IDEs spend most of their function points trying to compensate for the crappy qualities of a bad language, but there are reasons to love an IDE. One advantage of working in a more normal text editing environment *for a while* is that you can separate the quality of the IDE from the quality of the language. This is good because then you realize how great an IDE it is, and you realize how bad a language.

I think that a lot of it is just the sense of being in an unfamiliar environment. When I change editors and operating systems and languages, I can be paralyzed. Add a few libraries and enterprise tools, and I'm like a deer in the headlights. That whole biological urge to flee or freeze kicks in, the stress piles up. It's deep and profound that stress and fear. But even with appropriate tools, if enough other variables are new or different you will have the same feeling. Maybe for weeks, maybe for months, maybe for years.

It's areas like this that old school unix sorts that tend to really learn their editors (usually vi and (x)emacs) well, as also espoused by the Pragmatic Programmers, which used to make up a large percentage of the Ruby community -- less so now that Ruby has shot up in popularity, don't seem to have as much of a problem. The lack of "total control of text" that most IDE editors have often turns off folks like this. I see it a lot when teaching, where I see a category of programmer that uses the only the "most intuitive features of notepad" in their IDE editor and relies on various menus and pull downs for all other text. THey're stymied that they can't code ruby as comfortably as when they see me demo, and are dazzled by how quick the code changes shape w/o any menu usage.

The combination of: quick touch typing, attacking things in small pieces, very strong adherence to TDD, and being. quite good control of my editor of choice, and freqeunt but small refactoring seems to keep things in balance for me. I would probably be more agressive in refactoring with tools, but the refactorings you mentioned are not so difficult with good editor control.

This sort of ties into the questions I asked in another post (where I feel refactoring was the only part not answered by Bob).
How do you even make a refactoring tool for Ruby, without static typing? Consider the simple example of Rename Method. How would the tool know what method calls to change, since it cannot know if a call refers to this method or a similarly named method in another class. Or, for that matter, if the method you are renaming was supposed to mirror the interface of another class. Same problem for more complex refactorings.
But I guess there is a good answer to all of this, since it works for Smalltalk.

On the subject of IDEs, I feel that a good IDE should primarily give you tools to process your code, rather than building abstractions on top of you code. Of course, abstractions are not evil in themselves; I still prefer visual GUI building to the extremely tedious work of stringing components together in code.

Source control is your friend. ;-)

> big do-it-all-for-you IDEs are most useful for poor developers

I fully agree, I am no big fan of wizard-driven push-button IDEs that spit tons of ugly code in your face and gives a false sense of control to developers who ignore what is going on "behind the scene".

But refactoring features are very conceptually different from that. In fact the poor developers you mention almost never refactor.

now I just need to rename, flip to the header, flip to the cpp, compile, fix the breaks, compile again, probablly break again cause it gave up early the first time, run the tests

though with tools like incredibuild it takes some of the pain out of it, but ruby? pffft, thats easy to refactor

As for big IDEs? I dunno, I'm really liking vs2005 with resharper installed.

I was able to break through the fear and start refactoring. And, so far, it really hasn't been very difficult. I've been able to keep my tests passing without any horrible hicoughs. But, WOW, the backpressure in my own head was astounding. I still catch myself staring at the code; refusing to act. It's almost a fugue state; a mild catatonia. I know what I want to do to the code, but I stare at it instead because I fear I'll break something.

There's another factor here too which I'll address in MakingMessesInRuby.

What about your tests?

Don't get me wrong.. I'm a huge fan of refactoring tools in Java and C#. I'm just not convinced they are needed as much for Ruby. They would be useful... but not, imo, at the cost of a large, bloated, overbearing IDE.

Now I'll really be controversial... big do-it-all-for-you IDEs are most useful for poor developers (which explains why there's such a big market for such IDEs). In my experience, they get in the way as much or more than they help.

Sure, some better tools support would help with Ruby... but it's not as important as some people think. And it wasn't that long ago that I was one of those people.

It'll still be developing Ruby in a big, heavy IDE. It's overkill.

Dave, I do not think it is a question of the "IDE controlling/managing/hiding the complexity of the language being used" but a question of fluidity.

With a proper tool, your programming experience becomes fluid in the sense that it flows almost directly from your brain to your application: your intention gets reified in a matter of a click or (better) a keyboard shortcut.

Often, tools (or lack of proper tools), stand in your way: they break your flow of ideas by forcing you to figure out the n-step needed to concretize a particular intention.

And all this is extremely critical when refactoring, which is probably the programming practice that requires the most fluidity (and/hence is the heck of a fun).

I used to think that too. I'm not sure anymore. How much of the value of powerful IDEs has to do with controlling/managing/hiding the complexity of the language being used? I've come to think that that's a lot of it.

I find myself refactoring in Ruby as fluidly using TextMate[?] as I did with Eclipse or IDEA in Java.. moreso maybe because it's faster... there's no wizards.. you just do it.

I used RadRails[?] for a while.. it has some nice features but after a while I foudn that it just got in the way. It's big, and slow... not very condusive to working fluidly. And also it totally doesn't fit well into an OS X environment.

Working in Ruby is fundamentally different at a philosophical level. As is Smalltalk.. but that's different again.