Throughout the short history of commercial software development we see the same dynamic repeat itself again and again: 1. New abstractions are introduced which increase developer productivity. 2. Developers resist these abstractions because they a) legitimately need to maintain low-level control to satisfy requirements OR b) they don't want to learn the new abstractions and tools required to use them 3. The developers that resist for reason b either suffer or eventually capitulate because of competitive pressure. When C was created many assembly developers resisted using it even though the benefits were obvious. Many C++ developers still resist writing client applications in Java and C#. Many Java developers still resist using slower, more powerful languages for writing web applications where performance is far less important. In some cases these decisions are justifiable (see reason a) but they are edge cases.
When a developer chooses, all other things being equal, to use a low-level abstraction instead of a high one it’s worth asking them why. If they attempt to justify their decision on the grounds of “simplicity” chances are that they are motivated by reason b). High-level abstractions are simpler than low-level ones by definition. They reduce code size and increase code clarity. Most of the time what the developer is really saying is “I didn’t want to learn anything new.” So why do some software developers resist learning new things? It’s not laziness. A developer who manually writes the same code with slight variations a hundred times and spend countless hours maintaining it can hardly be accused of being lazy. The real reason is that they are afraid of new technology.
So how can a software developer possibly be afraid of technology? Two words: cognitive dissonance. These individuals spend their lives creating technology to improve the productivity of accountants, managers, and housewives but insist on coding GUI’s by hand. They use REST instead of web services because they don’t want to learn how to generate a proxy. They’ll write reams and reams of repetitive code instead of learning a new domain-specific language and every argument they’ll use to justify it can also be used to argue that they should get rid of their compiler and write bytecode by hand.
It’s easy to understand why software developers can be afraid of new technologies. Software development is extremely challenging for many reasons. Once having successfully developed software using one set of abstractions a developer would be wise to consider carefully the decision to learn new ones. This is why it’s so important to familiarize yourself with a variety of different platforms, technologies, and development approaches before you are put on a deadline. Once you understand the strengths and weaknesses of a variety of development paradigms, platforms, libraries, and tools you can stop wasting time fearing the unknown and start fearing the known.
Do you know any luddite software developers?
8 comments:
Jafar,
Don't be a Luddite! I am looking for a post, from you, on the new ADO.NET Entity Framework.
Hopefully you will attack it with as much clarity and insight as your LINQ posts.
Scott
Fantastic post. Yup, even techy guys can be anachronistic.
High-level abstractions are an integral and healthy part of every engineering paradigm, in my opinion. There are so many abstractions between the assembly level to, say, a WPF-based application that (for me, at least) it gives an headache to try and think of the stack that every XAML tag travels through in its way to change a few hundreds of flip-flops on some video memory out there.
Even 'old fashioned' C programmers usually work against an API of a specific operating system, which itself is an abstraction. It's pretty clear that Assembly is an abstraction of the underlying hardware, so it's only a question of how deep you want to go.
From my experience, there's no reason not to embrace the abstractions that make your life easier, especially when you've gone through the hell they're supposed to save other developers from.
I could hardly disagree more.
I'll have to assume that when you say, "High level abstractions" you are talking about the latest and greatest API from Microsoft. And that's fair enough.
The problem as I see it is that an experienced programmer simply does not write the "same code with slight variations a hundred times and spend countless hours maintaining it".
The fact is though that the IT industry is young and there are relatively few of these devlopers around.
It makes sense that younger programmers will want to take advantage of anything that makes coming from "a standing start" easier.
Meanwhile the experienced programmer writes his own frameworks and libraries to help him achieve his everyday tasks.
This will usually take a good deal of time but will come to represent something that not only works but something the developer can debug himself if need be (NOT wait for a service pack or future bug fix) and can understand totally making him or her a far more efficient and knowledgable programmer. Not to mention get a great deal more work satisfaction and enjoyment from what they are doing, which is what it's all about at the end of the day.
Why should all that be junked just because Microsoft have used bloatware to solve the same problems, only slower and more inneficiently? Or to be more accurate, most often they have solved a "problem" that really didn't exist for you in the first place.
Sure the new High Level toys can be fun to play with but there's nothing better than doing it yourself.
So, if a C++ programmer can use his experience and talent to create something faster than you, better than your effort you have strung together in some XML document (whilst calling it "programming"), why should he follow the Microsoft Marketing Machine?
Just as long as the area of your expertise is viable and the tools you use are supported and industry standard then I see absolutely no reason to jump and change (totally) the way you work year on year.
In fact, could anything BE less productive?
"I'll have to assume that when you say, "High level abstractions" you are talking about the latest and greatest API from Microsoft."
I never mentioned Microsoft once in my post. My arguments apply equally well to using ANT instead of bash for build scripts.
"The problem as I see it is that an experienced programmer simply does not write the "same code with slight variations a hundred times and spend countless hours maintaining it".
If you are working in any language other than LISP you most definitely do to some extent. That's because all other languages have blindspots in that there are recurring patterns that they cannot abstract out. How many times have you written for(int cnt = 0; cnt < arr.length; cnt++) in C?
"Just as long as the area of your expertise is viable and the tools you use are supported and industry standard then I see absolutely no reason to jump and change (totally) the way you work year on year."
That's what I said. When the industry moves on, you will too. It will move on to functional programming just like it moved to OO programming.
"Meanwhile the experienced programmer writes his own frameworks and libraries to help him achieve his everyday tasks.
This will usually take a good deal of time but will come to represent something that not only works but something the developer can debug himself if need be (NOT wait for a service pack or future bug fix) and can understand totally making him or her a far more efficient and knowledgable programmer."
If the abstractions suck you shouldn't build stuff on them. No software is perfect but for my money .NET and Java are mature enough at the moment to build on top of. Experienced programmers ARE efficient and knowledgable. They don't need to reinvent the wheel. Then again it's your time. Do what you like with it. I prefer to spend it accomplishing new things.
As a self confessed Luddite Developer, I have to disagree with your assessments.
Software tools today should be much easier to use and much more intuitive.
When I first started with .NET I used the visual designer almost entirely. Today, I find that I use the source view most of the time. Why are these tools not making my development any easier?
I find the abstractions behind WPF and Silverlight a complete mystery. Even the evangelists out there appear beside themselves when they actually get something to work.
When you see the Ajax scriptmanager requiring a 450KB download (about 100KB if comressed) you realise that these people are NOT living in the real world.
The problem is NOT that developers are unwilling to learn new stuff. In fact developers love new stuff, new widgets and new gadgets. They just think that new stuff should make them much more efficient and that the new stuff needs to be much more intuitive.
SQL for instance was tried and tested and developers did know how to write database queries using SQL, T-SQL and Oracle's PL-SQL.
Then along comes Microsoft and Linq who try to tell us that SQL is difficult to understand and produce something which appears to be SQL in reverse!!!
I begin to think that the true Luddite's are really the people producing some of this new fangled nonsense.
I think 2moons dil changes my life. Because of 2moons gold, I meet a lot of friends. Besides, my friends usually give me some 2moon dil. I usually buy 2moons dil through Internet and advice from my friends, so I gain a lot of cheap 2moons gold and harvest in life.
9Dragons is a very good game. Through buying 9Dragons gold, I find fun in it. I am so glad that I can earn a lot of 9 Dragons gold. 9Dragons cater to the taste of young people. With cheap 9Dragons gold, you can get everything you want in this game. So I like to buy 9 Dragons gold. For me 9Dragons money is not just a simple thing.
情趣用品|情趣用品|情趣用品|情趣|情趣用品|情趣
I'm currently the technical lead at a software development company writing software for banks and I agree completely with Jafar.
I see no reason for programmers to write code to connect to a database when I hired them to write business logic. There is very little value in them writing the plumbing to connect to a database when that pattern has already been solved a hundred times over. Yes, there are caveats to the rule but in general I think that the frameworks do a very good job of solving the common problems.
Post a Comment