January 6, 2008
I've often thought that software developers were akin to Magpies, birds notorious for stealing shiny items to decorate their complex nests. Like Magpies, software developers are unusually smart and curious creatures, almost by definition. But we are too easily distracted by shiny new toys and playthings.
I no longer find Scott Hanselman's Ultimate Developer Tool list inspiring. Instead, it's fatiguing. The pace of change in the world of software is relentless. We're so inundated with the Shiny and the New that the very concepts themselves start to disintegrate, the words repeated over and over and over until they devolve into a meaningless stream of vowels and consonants. "Shiny" and "new" become mundane, even commonplace. It's no longer unique for something to be new, no longer interesting when something is shiny. Eventually, you grow weary of the endless procession of shiny new things.
I'm not alone. Jeremy Zawodny also notes the diminishing luster of shiny new things:
Over a year ago I unsubscribed from Steve's blog because he had a habit of writing in breathless fashion about the latest shiny new thing – often several times a day. I see too many people I know getting caught up in the breathless hype and forgetting to think about whether the latest shiny new thing really matters in the grand scheme of things.
Dave Slusher concurs:
[Robert Scoble] says that he gets too much email and that is ineffective for getting PR releases to him. He suggests that what you should do now is leave him a message on his Facebook wall. Dear god and/or Bob. In the time I've followed Scoble, I must have seen something like this a dozen times from him. Don't email, Twitter me. Don't Twitter, Pwnce. Jaiku me. Leave a wall message, send an SMS, just call me, email me, don't email me, don't call me. Enough already! I'm not even trying to get in contact with him, and I find this constant migration from platform to platform to be a load of shit that just wearies me. I felt the same way when I dropped TechCrunch, well over a year ago. I got so tired of hearing about another slightly different way of doing what we were already doing and why that tiny difference was worth dropping everything and moving over. I officially renounce the search for the newer and shinier.
It isn't just the neverending stream of tech news. It's also the tidal push and pull of a thousand software religious wars that continually wears us down, like errant rocks in a rapidly flowing stream. I bet the process David Megginson outlines sounds awfully familiar:
1. 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.
2. Elite developers take their shopping list of current annoyances and look for a new, little-known language that apparently has fewer of them.
3. 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.
4. 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.
5. The huge mass of regular developers realize that they have to start buying books and taking courses to learn a new language.
6. 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.
I hope you're sitting down, because I've got some bad news for you. That Ruby on Rails thing you were so interested in? That's so last year. We've moved on.
If you consider that, statistically, the vast majority of programmers have yet to experience a dynamic language of any kind – much less Ruby – the absurdity here is sublime. Some dynamic language features are trickling down to the bastions of Java and .NET, but slowly, and with varying levels of success. These so-called thought leaders have left a virtual ghost town before anyone else had a chance to arrive.
I became a programmer because I love computers, and to love computers, you must love change. And I do. But I think the magpie developer sometimes loves change to the detriment of his own craft. Andy Hunt and Dave Thomas, the Pragmatic Programmers who were a big part of the last sea change in Ruby, said it quite well in a 2004 IEEE column (pdf).
Users don't care whether you use J2EE, Cobol, or a pair of magic rocks. They want their credit card authorization to process correctly and their inventory reports to print. You help them discover what they really need and jointly imagine a system.
Instead of getting carried away with the difficult race up the cutting edge of the latest technology, Pete concentrated on building a system [in COBOL] that works for him and his clients. It's simple, perhaps almost primitive by our lofty standards. But it's easy to use, easy to understand, and fast to deploy. Pete's framework uses a mixture of technologies: some modeling, some code generation, some reusable components, and so on. He applies the fundamental pragmatic principle and uses what works, not what's merely new or fashionable.
We fail (as an industry) when we try to come up with the all-singing, all-dancing applications framework to end all applications frameworks. Maybe that's because there is no grand, unified theory waiting to emerge. One of the hallmarks of postmodernism – which some think is a distinguishing feature of our times – is that there's no "grand narrative," no overarching story to guide us. Instead, there are lots of little stories.
Don't feel inadequate if you aren't lining your nest with the shiniest, newest things possible. Who cares what technology you use, as long as it works, and both you and your users are happy with it?
That's the beauty of new things: there's always a new one coming along. Don't let the pursuit of new, shiny things accidentally become your goal. Avoid becoming a magpie developer. Be selective in your pursuit of the shiny and new, and you may find yourself a better developer for it.
Posted by Jeff Atwood
Unfortunately the customers also like shiny new things as my marketing person told me when I explained the package he wanted me to use couldn't meet the legal requirements of the job! The customer got something that looked great but under the hood lacked substance.
Another writer covered this topic from a completely different point of view several years ago... of course I cannot remember who that person is; I do remember the thesis; quakers have it right.
Quakers (and adjacent religions) have a process of evaluation for new technology. Many people think that to the *quaint* Quaker a new technology might be say, basic electricity. Believe it or not, the Quaker ideal of evaluation was *does this technology take away from out community* - now feel free to read into that but - as far as stringent policies go - they are pretty rough. Quakers allow the use of phones for example - but pay phones.
If only we hackers did the same thing. I personally think of myself as a very conservative hacker and programmer - I do not need much but by the same token - my software does not *do much* - it is designed for people like me - not the masses. So I can certainly say - yes- I do not fall victim to shiny ad syndrome - but I can see why other people do. The issue is largely systemic but it is beyond softwares.
The irony of this article is that you (Jeff) are actually keying in upon a *social* problem - not a programming one.
I think the biggest problem with 'magpie' developers is that they pick up shiny and new without having the clue as to why they're picking it up. I try to pick up only the shiny and new that are going to net me productivity gain and or bottom line improvements. For example: LINQ's drag and drop ORM with sql05/08 is handy for a 2tier quick/dirty app. Enterprise library is great to save some bottom line on creating custom cross cutting concern libraries (logging, security, interception/injection aka PIAB). WCF enables you to spend more time focusing on business value rather than plumbing code.
Before you pick up something new, try asking yourself "Why am i trying this out". If the reason is just "because it's new"... it's probably not worth your time.
In regards to getting in contact with someone.
Ever hear about *filters*?
For years I've been saying to folk, please don't call, I hate my phone.
And they Do.
And I have filters set up.
You know, to direct mail into folders ?
Asking people to Pwnce you, or leave a note on your wall, or leave a comment on your LJ. Whatever, Its only going to get turned into email anyway!!
Cut out the bloody middleman!
*foam at the mouth*
I've also lately come to the conclusion that the new and the shiny is..well..new and Shiny, but its also, 9 times out of 10, completely useless for my purposes.
I like sticking with a machine that does the job. Why upgrade until you have to ?
I really like the magpie metaphore ;) and indeed we steal a lot...
I think there are 2 major trends one good developers should follow:
1) in my opinion, good developers love change. they need it to keep learning and get better
2) I don't care which language to use (known or yet to learn) because the important thing is to deliver an adequate and working product. So the developer should adapt his tools to the job and not the contrary.
The only drawback is when you keep jumping from one shiny framework to the next hype language without really get things done ever.
What I find most interesting is the never ending pattern of "I have an issue with my current framework/platform/etc., and I can make one better from scratch."
If only the same glory could be had from making an existing mediocre platform into something superb, as can be had from make another mediocre platform, albeit shiny and new, from scratch.
Nature of the beast, I suppose.
The hard part is striking that balance between trying to build a website in assembly with a line editor, and spending all your time playing with shiny things and not getting any 'real' work done. Even if your job is to evaluate shiny new things, it's hard to evaluate their use if you lose track of what they're used for.
Personally, I invested enough time in learning vi that I'm unlikely to ever give it up.
Shiny new toys should not come as the plain expense of the programmers' and designers' efficiency. There are ways to reduce the impact by reducing the learning and implementation curve.
Also its true that not every shiny new thing is a jewel. And you don't need to migrate if you would get only a small benefit out of the new gadget, if the benefit is smaller than the reduced efficiency. Of course somebody has to test the gadget first. But when you do get new gadgets into production, it should happen under total control at every level.
How typical that most of the responses take the form of:
1. "You're wrong. The shiny things are really important and useful new features that boost productivity 1200%."
2. "You're right. Good thing I don't fit into THAT category! Now let me tell you how great my last Ruby/Scala app turned out..."
3. "You're right. That's why I only use VI/Emacs and Common Lisp."
Congratulations on missing the point, folks. Remember, you can write FORTRAN in any language.
"Don't let the pursuit of new, shiny things accidentally become your goal." Good advice.
I always like to let developers have a couple breaks between projects every year to pursue whatever development related activity they'd like -- whether reading a book, trying out a new tool/language, or experimenting with some programming techniques. It allows a person time to have a look at some "shiny, new things" and not feel like the programming world is passing you by, but without it becoming a all-consuming activity.
Aaron G, flip a coin...
Change for the sake of change is usually the fastest way to move backwards.
There are very few innovations over the last couple of decades that have radically changed programming.
I think the discovery of unit testing and object orientation are perhaps the only two real technologies that have changed programming for the masses.
I had an epiphany recently that your computer is just a machine. It's a complicated tool but it is still a tool. It's an enabler to get a job done. That's it.
If the code you write works, is fast enough, maintainable enough and your customer is happy then your job is done.
It does not matter if your program miss-implements that factory pattern one time or a hundred. It does not matter if the object model is badly factored. Even the horrible code most of us would turn our nose up at, is not fundamentally flawed. It does work, if elegant.
I heard a woman on Dotnet Rocks say that people think of software as "disposable." She said that in five year, most of the code you've written will have disappeared.
That's a horribly depressing thought.
How can we possibly move forward when we spend the vast majority of our time moving from one latest and greatest technology to the next?
If we're to move this industry forward, we need to start actually using the tools we have now, correctly.
I get MSDN Mag and many (not all) articles are about shiny new stuff for Microsoft, LINQ, .Net 3.5, WPF, etc. Some of the stuff I'll never use but at least reading about the shiny new stuff I can see how it could fit into any future programming and upgrade as needed.
Coming from Windows Forms, WPF would be major investment in time for me. For someone new, not a big deal, but I've already spent a lot of time learning all the windows controls and how to set the correct properties for them and how to use them. Now you can use something like Expression Blend to make the app without a single line of code. You still need the guts of the application, but things do change, so eventually I'll have to spend some time relearning how to make a Windows based application using XAML.
My Windows Forms knowledge will probably probably be obsolete in about 2 to 5 years depending on the adoption of WPF. I know how to make a Windows application, but to stay up to date I have to re-learn how to do it with WPF and XAML.
For someone new, WPF and XAML is probably the next best thing besides sliced bread. But, for someone who has learned it the older way, it is frustrating.
So, after some time, I get no return on my investment. This I do not care for.
Here is cardboard box
Here is a new shiny box
Here is a new shiny box with a ribbon
But in the end it is still a box.
We need more box improvements and less new boxes.
So, what you're saying is, the new shiny toy is no new shiny toys?
It is interesting to relate your post with Chad Fowler's "Watch the Market" chapter on "My Job Went to India". Fowler actually recommends us to become alpha geeks, as our current languages and tools may apocaliptically fade into disgrace, whereas the shiny and new ones may be the next big thing (that may yield lots of money for those who took the risk, of course). Fowler compares the investment in a technology with a common financial investment: you may find security in an ordinary savings account, but why not try a higher return investment?
Corollary #1: why not //speculate// with technologies? It's all about the money you can make.
Corollary #2: forget about clients and the actual problems that these technologies solve, it's all about the hype (and the money you make with the hype).
This is, of course, a pessimistic view, yet a possibility. Technology speculation - and not just simple curiosity - may be the drive of the Magpie developers.