This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Why progress is so slow
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
Look no further than Chad Dickerson's article on IDE's for an explanation as to why there hasn't been anything better than Smalltalk or Lisp introduced since the dawn of the software age:
As a Java shop, we have our choice of dozens of tools to produce our code, but our developers have opted for the humble text editor. Our developers use a wide variety of text editors within the team (UltraEdit-32, vi, and Emacs), but each developer basically sticks to the simple text file environment. Our team is highly productive and probably the best at hitting deadlines that I have ever managed, but when it comes to writing code, IDEs (integrated development environments) just leave them cold.
It starts with the notion that sharp sticks and pointy rocks are somehow more productive than tools optimized for your job. Part of the problem is that the relevant tools in the Java space are pale imitations of a Smalltalk environment. Another part of the problem is the whole dead object mode of development - a Java object resembles an object in much the same way that a corpse resembles a person. Why do so many Java developers opt for a text editor instead of a tool? Because the tool doesn't really do a lot for them, and the tool cannot be (easily) extended. Sure, Eclipse offers plugins. It's not the same as doing a quick modification to a Smalltalk environment and getting the benefit right now. Take a look at this post from Eric Winger for an example of what a developer can do to optimize their personal development environment. Now imagine an Eclipse developer doing the same thing... When you stop giggling, you'll understand why so many of them opt for the sharp sticks and pointy rocks approach.
Here's Chad's summary - I'll have a comment on it below:
The IDE debate will probably continue until the end of time. A surprising degree of passion flares if you bring up this issue with developers. But does it actually matter? The answer, like any dealing with the ambiguities of IT philosophy, is yes and no. As long as your developers produce quality code that they can debug at the lowest level when necessary, the IDE debate is probably more of a cultural issue than a technical one. Consistent, quality code delivered on time trumps the means of getting there; however, culture matters within a development team. If your development team spends a lot of time debating the merits of writing code in an IDE or a simple text editor, they probably won 19t be incredibly productive. The important thing is to choose the route that makes your team most productive - and execute.
The problem appeared early in his article - at the point where he said "we are a Java shop". he didn't say "We look around for the best tools for a job" - he said "we are a Java shop". Right there, he ensured that there was a fairly low top point to his team's productivity. Python? Ruby? Smalltalk? Nah, text editors and Java are the way to go. This is nicely in line with the 4 zone charts that these bozos like to draw, but it's not a way to rise above the competition. If you make sure that you do exactly what the other guys do, you have made a risk averse decision - you won't fail any worse than they do, but you also won't succeed any better. You'll tread water.
Chad should take a look at a Smalltalk environment - there are plenty to choose from - and see how productivity can rise when the team has an environment that lets them move the bar up.
Previous Topic
