April 30, 2006
Jon Raynor added this comment to my previous post about keeping up with the pace of change in software development:
The IT field is basically a quagmire. It's better to accept that fact right away or move on to a different field. I guess someday I wish for Utopia where I won't be obsoleted when I get out of bed each and every morning.
The industry needs to stop running around like a chicken with its head cut off trying to find the next big thing. The tools constantly change, but yet they do the same thing, create code to run on machines. First we get a screwdriver and learn how to use it. Then out comes the newdriver, different than the screwdriver, but does the same thing. Then out comes the phewdriver which is totally different than the screw and new driver but performs the same function of both previous tools.
It's an interesting observation. I'm far from a handyman, but even I own many different screwdrivers: different sizes, different tips, different lengths. They're all performing the same job-- screwing*-- but each one is uniquely useful in the right scenario. I'd hate to throw out all the screwdrivers I own and opt for a one-size-fits-all approach. Sure, I may choose the standard screwdriver 90 percent of the time, but what about that other ten percent?
So a case can be made for having multiple languages and multiple tools, redundancies and all.
However, software developers are awfully eager to throw out existing tools for new ones. Unfortunately, these decisions are often based on myth and wishful thinking, and the decisions are typically made in favor of whatever the hot new thing of the moment is. Here are two mistakes that I see a lot:
1. Let's buy this whiz-bang power screwdriver that will double our productivity.
A silver bullet brand screwdriver, if you will. Just replace the word "Ada" with "Ruby", below:
One of the most touted recent developments is Ada, a general-purpose high-level language of the 1980's. Ada not only reflects evolutionary improvements in language concepts, but indeed embodies features to encourage modern design and modularization. Perhaps the Ada philosophy is more of an advance than the Ada language, for it is the philosophy of modularization, of abstract data types, of hierarchical structuring. Ada is over-rich, a natural result of the process by which requirements were laid on its design. That is not fatal, for subsetted working vocabularies can solve the learning problem, and hardware advances will give us the cheap MIPS to pay for the compiling costs. Advancing the structuring of software systems is indeed a very good use for the increased MIPS our dollars will buy. Operating systems, loudly decried in the 1960's for their memory and cycle costs, have proved to be an excellent form in which to use some of the MIPS and cheap memory bytes of the past hardware surge.
Nevertheless, Ada will not prove to be the silver bullet that slays the software productivity monster. It is, after all, just another high-level language, and the biggest payoff from such languages came from the first transition -- the transition up from the accidental complexities of the machine into the more abstract statement of step-by-step solutions. Once those accidents have been removed, the remaining ones will be smaller, and the payoff from their removal will surely be less.
I predict that a decade from now, when the effectiveness of Ada is assessed, it will be seen to have made a substantial difference, but not because of any particular language feature, nor indeed because of all of them combined. Neither will the new Ada environments prove to be the cause of the improvements. Ada's greatest contribution will be that switching to it occasioned training programmers in modern software-design techniques.
2. This screwdriver is for amateurs and hacks. We should buy a newer, more professional screwdriver.
David Megginson notes the self-perpetuating cycle of successful programming languages:
- Elite (guru) developers notice too many riff-raff using their current programming language, and start looking for something that will distinguish them better from their mediocre colleagues.
- Elite developers take their shopping list of current annoyances and look for a new, little-known language that apparently has fewer of them.
- Elite developers start to drive the development of the new language, contributing code, writing libraries, etc., then evangelize the new language.
- Sub-elite (senior) developers follow the elite developers to the new language, creating a market for books, training, etc., and also accelerating the development and testing of the language.
- Sub-elite developers, who have huge influence (elite developers tend to work in isolation on research projects rather than on production development teams), begin pushing for the new language in the workplace.
- The huge mass of regular developers realize that they have to start buying books and taking courses to learn a new language.
- Elite developers notice too many riff-raff using their current programming language, and start looking for something that will distinguish them better from their mediocre colleagues.
It's OK to add a new screwdriver to your toolkit every few years. But make sure you're adding it for the right reasons.
* Yes, it's still funny.
Posted by Jeff Atwood
I think it becomes clearer to think of a programming language as a set of screwdrivers rather than making the each-programming-language = a-single-type-of-screwdriver analogy. Because certainly many programming languages utilize that standard, multi-purpose flat-head, but some add unique, niche-type screwdrivers, etc.
Otherwise, I agree. It gets very tiring trying to stay abreast of things. Maybe for the whiz-bang uber-programmers it's no problem, but for some of us(i.e. me), it's hard to maintain, muchless, excel. There's just too much, even if you're trying to specialize.
Part of the problem, of course, is that manufacturers keep using oddball screws. Why on earth is my laptop screwed together with tiny little philips head screws, but the hard drive inside of it is secured with torx screws that are exactly the same size? The screws look identical except for the place where you put the screw driver. Woludn't it have been cheaper and easier to use screws with the same head? (OK, I'm sure there's some technical reason, but it certainly looks silly from my point of view.)
I see this same sort of thing with software development, as well. Things like, "the new version of our application was built with a newer compiler, so if you want your plugins to continue to work, you need to rebuild them with the newer compiler, too." Great! Thanks! I didn't have any other things I wanted to work on anyway. Ugh!
So it's not always that developers want to use the latest and greatest, but that we're often forced to by the OS/app/whatever that we work with.
something is not right here..
Windows = operating systems you can open and close to get air
Apple = Something fresh and healthy to eat
whiz-bang power screwdriver = ruby
paint can = development instructions
hammer and nails = MS .Net ?
.. ehh I dont get it Jeff, are you the keymaker? :)
Dude, you own way too many screwdrivers.
I think the problem is not one of new screwdrivers, but of *interdependent* screwdrivers.
If you look at C# and compare it to how I learned to program (Fortran 77, 6502 assembly and Basic), there are more differences than just syntax and memory protection. Even moving to my first professional programs, at a very fundamental level, the way I approached programming in DOS on a 386 CPU using C and assembly differs radically from how I program today.
a) I have a relational database that runs independent of my code.
b) I have an operating system that handles half of the infrastructure I used to code by hand.
c) I have libraries that cover the other half of the infrastructure I used to code by hand.
d) I have a GUI builder that makes light work of user interface layout.
e) I have different paradigms (objects, distributed computing, recoverable transactions, etc.) that underly the work itself.
The interesting thing isn't the toys that allow my focus be laser like on business logic, but the fact that trying revert to "the old ways" the house of cards collapses. The GUI builder relies on partial classes, inheritance and a huge library to make it work. The libraries are possible because objects made organization of complex reusable code blocks easier. The relational database exists because I can afford to burn CPU freely and it in turn relies on the operating system to provide a stable platform to ignore many issues that are abstracted away.
What we have today is built atop the structure that each prior platform gave us. In most cases, the old platforms don't entirely vanish, but instead act as supports for the new platform until the new platform stable enough to succeed. NTKERNEL still has assembly at the core, and C code around it. Windows is still C with C++. Many applications today are written in higher level languages, but they still require that C/C++ underpinning.
Back on topic, the point is not only we need to acquire and learn new screwdrivers, but those screwdrivers are interdependent in ways that mean you are going to eventually drag the entire infrastructure in a given direction. By using .NET 2.0, I found myself upgrading to the new application blocks, a new version of my object relational mapping tool and SQL 2005 to get the full benefits of the new platform. I didn't upgrade my screwdriver, I upgraded my toolbox.
As for Ruby, it is an interesting language which has much to commend itself. Likewisem, Rails does much to place the programmer at a higher level of abstraction when dealing with a specific application type (the data driven web app). However, because it is being built "alongside" the powerhouse application stacks I have to wonder about its long term success. Ruby on Rails has to maintain the entire stack above the OS/Web Server level as well as providing a library, which as it grows may be the undoing simply because of the overhead.
Working with screwdrivers for all these years is giving me RSI :)
actually, the Robertson is a better screwdriver. Canadian, too.
language development was quite stable for a long time, the COBOL years. one learned a bit of syntax for a few months at some store-front programming school (or the US Armed Forces), then spent years churning out the same stuff for a particular industry. no CS degree, or even 5 minutes in a college. the methods of AutoCoder, FlowMatic, and COBOL from the 1950s and 1960s live on today. and in the enterprise world, there is a good deal of effort to move all that "software investment" to microprocessors and linux.
and, there really should be a 3): hordes of wanna be Elite Programmers spewing out silly procedural code wrapped in OO syntax; aka Apache.
and these are the truly evil ones, since they generate so much noise that folks just start going along. in economics there is Gresham's Law; bad money drives out good. the same can be said of languages.
My gut reaction was to agree - why don't we just master the tools we have instead of creating new ones all the time? Then I thought about the path from Commodore BASIC to Visual Basic to VB.NET. Each one was a major improvement not only in language features, but what you could do with it.
Obviously changes in the underlying platform drove and enabled these improvements, but I think it would be difficult for anyone to claim that each wasn't needed, and a step for the better.
The same is true of software testing tools. Test teams sometimes get trapped on the "test tool merri-go-round." They have a tool that's working fine for its intended purpose, but then some new, whiz-bang widget comes out that they MUST move to. So they do. Then a year later, the next big thing comes along and so they move to that. Of course, none of these changes are made quickly -- they involve countless hours of tool evaluation, followed by education, porting of test scripts, etc. Often times, sticking with one tool and leveraging the heck out of it (even though it isn't perfect) turns out to be the better long term strategy.
Tools are a means to an end. But it's easy to lose site of that end when one is hypnotized by shiny objects.
My first reaction to the title was to say, "Because we have so many screws, and not all people use them the same way." Universal conformity may be great from an intellectual standpoint, but it just doesn't work.
That aside, I have to agree with Jon's quote. Ultimately it's all just ones and zeros. I've been fortunate to have been able to adapt to new ways of making ones and zeros, and I find things to love and hate about each method. However at the end of the day, it really just doesn't matter.
The elite guru programmers are currently using Eiffel for ASP.NET.
Insert Jim Adams joke about the size, length, and tip of screwdrivers..
Rather have Visual Basic over QBASIC. How about between Visual Basic and FreeBASIC?
A way to the most beautiful code is Ruby and Rails
It's one way. But you can write FORTRAN in any language:
I think Brooks' observation is still valid:
I predict that a decade from now, when the effectiveness of [Ruby] is assessed, it will be seen to have made a substantial difference, but not because of any particular language feature, nor indeed because of all of them combined. Neither will the new [Ruby] environments prove to be the cause of the improvements. [Ruby's] reatest contribution will be that switching to it occasioned training programmers in modern software-design techniques .
Rather have Visual Basic over QBASIC. How about between Visual Basic and FreeBASIC?
Suicide Booth: "Please select mode of death. Quick and painless or slow and horrible."
Fry: "Yeah, I'd like to place a collect call?"
Suicide Booth: "You have selected slow and horrible."
Bender: "Great choice!"
Hey, don't diss the Robertson. They are _by far_ the best *all-purpose* screws you can buy.
"As it turns out, if you make only one kind of hammer, capable of performing all the same tasks as all those different kinds of hammers, then it isn't very good at any of them. Driving a nail with a sledgehammer isn't very effective. And, if you want to kill your ex-girlfriend, there's really no substitute for a ball-peen hammer."
"That's true. So, if nobody buys Universal Hammers anymore, and if you're no longer selling all those old-fashioned kinds of hammers, what kinds of hammers do you sell?"
"Actually, we don't sell hammers at all."
If you just had screwdrivers in your toolbox, as a handyman, your screwed.
You definately need a nice toolset...screwdriver (.net), plier (java), hacksaw (scripting), and hammers (Oracle, SQL Server) to excel at programming.
I just don't like how I have to learn (really forced to) a new screwdriver, pliers, etc. every year. My old one that is paint covered and slightly rusty still turns screws just fine.
I also agree that I'd rather have a power screw gun over a screwdriver any day, so in that respect I'd prefer VB.NET over QBASIC because there really is an advantage, not perceived or hyped.
Those elite programmers...hmmm, maybe not so elite after all.