One of the wonders of the web is RSS, its one of those things where people used to say "how do you keep up to date" and the answer was I use a large amount of RSS feeds, but unfortunately they don't have the sophistication of Emacs' newsreader. Well today I saw that brilliant old IT challenge of "If I can do it in less characters, then it must be more effective" now there are only two problems with this argument, firstly its bollocks, and secondly its... bollocks. Now I know that strictly speaking this is only one problem, but its such a big one I thought I'd point it out twice (name that TV programme?).
I came across this challenge in two guises, the first "impressed me" that a library call in Ruby could do lots of things and the second went for the traditional Java sucks angle against scripting languages.
Now these would be wonderfully astute calls if they hadn't been made every year since I entered IT. The only problem is that the ability of the people arguing has gone massively down. When I first got into IT it was the LISP people arguing that they could do anything in less characters than anyone else, and they were right. This was because they used a functional programming language and really understood IT. They never ever thought that a scripting language was the best way, and indeed nobody did because a strongly typed and formal language had much better performance and that meant performance in project teams which is what is important after all.
IT suffers from a massive dumbing down, people make arguments based on out right stupidity, a stupidity based on little or no understanding of the principles of computer science. The complexity of IT is ever increasing but the average intelligence is plunging. Things that were plain dumb 10 years ago are now being promoted as "best practice", not because they have become good ideas but because there is a volume (as in barrel) of people who think that their mickey mouse experience is all that anyone ever needs to know.
This is one of the most depressing things about IT. When the LISP boys used to show off at least you could stare in wonder at what they'd done. Having a library that does time conversion isn't exactly the most impressive thing I've seen, its not even the most impressive thing I've see my dogs do today, and the "I can write code really quick in this scripting language" is a great lesson in the "I don't have a clue about TCO" problem that IT has always suffered from. Just for once it would be nice to see people shout out about "I used this and 5 years later people were still able to make changes" or "I wrote this code and the developer sitting next to me understood it".
Maintenance is the hardest part of IT, writing code that survives for 5, 10 or even 20 years should be an achievement, not writing something 20 seconds quicker than the bloke sitting next to you. It would be nice to see people laud languages because of the features they have that make support easier, facilities that make monitoring easier or just pieces that make deployment easier. There is something seriously wrong in IT when every new generation comes along and makes exactly the same mistakes that the muppets of the previous generation made, but worse than that where previously the muppets were small in number they now appear to be pretty much the majority of IT.
This is a major challenge for IT, and in particular the current challenges of SOA and participation based systems. Sure someone can knock up a glorified FTP site with a GUI (YouTube anyone?) but what about doing real, active, participation and creating real business value on existing systems?
As long as IT is dominated by people whose perspective is I can code in this quicker, like really cool dude then it will continue to be perceived as a profession dominated by an obsession of itself rather than an obsession with improving what it does.
10 comments:
Ah one of my favourite soap-boxes. I agree wholeheartedly but would make a modification to:
"As long as IT is dominated by people whose perspective is I can code in this quicker, like really cool dude then it will continue to be perceived as a profession dominated by an obsession of itself rather than an obsession with improving what it does."
Because whilst these people certainly don't help, their management is often at least as much to blame because they push the "more code now" mantra complaining about "too many meetings" where for example we might do some proper design or actually figure out why a requirement makes no sense or discuss testing (eh, testing, we don't have time for that!) results etc.
The solution to this problem is simple - techies need to understand these issues and push back on their management and the management needs to make some efforts to understand a smidge more about development cycles beyond the fact that it produces code.
Sadly, I suspect you and I will be able to repeat this conversation in another decade assuming we don't both get fed up with the whole mess and escape to something better.
Dan
http://www.dancres.org/
"Sadly, I suspect you and I will be able to repeat this conversation in another decade assuming we don't both get fed up with the whole mess and escape to something better"
Bingo! That is so true...
See the allegorical version posted in Grady Booch's recent blog entry on architecture governance
We need more people thinking about how to build the cathedral and not how good they are at being stone cutters.
I totally agree with you. I don't think creating a piece of working code is rocket science. Anyone, especially with today's tools and sample code, can hack together something that works.
"An interpreted scripting language" vs Java argument is very unnecessary. Anyone holding an actual computer science degree would tell you that both have their own place. It is stupid to implement an enterprise level software in a scripting language. It's just as stupid to create a java application with 10s of classes to do a batch operation on a folder or display a web page that can change the css based on a dropdown value.
It all comes down to the IT culture you're growing up in. Unfortunately more and more people see software as something that you can pick up by reading a couple of books in a starbucks. Those are the people who get into such discussions over syntax/languages.
It's about time that people understand that software development is not just about learning ONE language ONE platform and sticking to it for the next 40 years. We're really past that point in time. In a rapidly changing environment what people need is an open mind and flexibility work in different environments.
Sorry to be the dissenter, but this is one of my favorite soap-boxes too. I agree that software development has been "dumbed down", particularly since about the mid-90s, but that's about all.
It does no good to rely on perjorative labels like "scripting language" to describe dynamically typed languages. The fact that a dynamic language can be used for scripting is an advantage for that language in that it extends it reach. I concede that some dynamic languages, *whose primary role is scripting*, can have qualities that are negatives for large-scale development (Perl is obvious), but you would have a hard time equating Perl with, say, Ruby in terms of suitablilty. Even Paul Graham has acknowleged that a language needs to "script" *something* to be successful (script in a loose sense).
Dynamic languages have pedigreed supporters and a history of success. Half of Wall Street was running on Smalltalk until the Java juggernaut took over (the HotSpot VM written by Smalltalkers btw), so it's historically inaccurate to claim that they are unsuitable as a class for developing and maintaining large scale applications.
The extensive use of static analysis in the development environment is a relatively recent advantage for static languages - that's true - but the often quoted type safety and provability and so forth does not cover its cost, in my experience. The costs of static language development are almost never considered, because they are just part of daily life for the vast majority of developers. This leads to your point about TCO.
Software development is a business, but the specific rules of engagement vary enormously across different domains. If I were writing software for the space shuttle or medical equipment, then provability is part of the business equation and the cost of it is justified. On the other hand, in many cases speed and flexibliity are more valuable, because the opportunity costs of correctness exceed the actually costs of some loss of correctness. And this is a continuum. There is no one true, correct, "mature" approach to software development - that's a naive and disruptive mirage.
Even if there were I could not concede from my experience that static typing of the, say, Java variety offers more than a modest improvement in "intrinsic" reliability than Smalltalk or (probably) Ruby. The biggest advantage of static languages is static analysis and the improvements in development environment experience, but that didn't appear to be the tone of your post.
I have 25 years in the industry and 10 years of full-time Java experience, so I'm not a "script kiddie". Not that that should matter, genetic fallacy and all. But my point is that having done substantial work in both paradigms I have a good sense of the tradeoffs, and IMO the costs of static typing are either overlooked dismissively or just not appreciated at all. And when you bring those to the table the situation is just not as clear as you pretend. Java is a fine language, but you pay a price for it.
You all have the right idea. But the wrong answer.
IT is unfortunately lacking skill. And this is not a consequence of scripting languages or the culture they create, in fact, quite the contrary. I find that the majority of people I interview these days do have computer science degrees (unlike myself). And that they have a very limit and java-centric skillset.
I write code daily in Java, Perl, JavaScript, whatever other language fits the bill. This is a practice I learned many years ago that has been dubbed as "using the right tool for the right job".
The problem I see these days is far too few folks in IT actually take any pride in their work. I see, on a daily basis, many folks who consider nothing other than the list of bugs assigned to them and the document the are supposed to have complete by the end of the day (as they've spent the last week doing things other than thinking about their upcoming project and prepare to slap some garbage design document together in 2 hours).
The problem, I see, is the fact that most engineers who work in most offices don't work on anything related to IT at home. In fact, most of them (somewhat understandably) practically refuse to use their computers at home for more than a video game machine. This unfortunately isn't a way to hone your skills and become a truely talented professional. But since the immature management of IT organizations rarely has any concept of the notion of talent, and cares only about getting what they asked for at the end of the day, this trend is increasing instead of declining.
That's why IT is becoming generally less intelligent. The poor fool who thinks writing code faster is just a person with little experience, and again, back to the problem of business caring only about the number of things completed at the end of the day. IT Businesses need to be made aware (and it's your job to tell them!) about the basic accounting principals of future cost and sunk cost, and how they can be applied to make your applications not only better, but cheaper and more cost-effectively.
The key is the "right" tool for the long term not the right tool for today. So you use lots of different languages (more languages means more support costs) but is that because it will make support easier or because it reduces the work you have to do when you code it?
The two are not the same
The key is the "right" tool for the long term not the right tool for today.
Right, but you can't really insist on using steam engines because of lower maintenance costs just because your maintenance folk is plumbers and not electricians.
Likewise, "I wrote this code and the developer sitting next to me understood it" should just be taken for granted. If it's not, either he isn't a developer, or I did not make myself clear in the code, but that's pretty independent of the language used. It's just that Java offers a lot of boilerplate that everybody understands (and provides an illusion of maintainability) but that has no value at all.
Andreas,
Its a dangerous assumption that the next developer will understand your code no matter how well its explained. Some code should only ever be maintained by smart people and exposed (via APIs or as infrastructure) to the rest. Other pieces of code will be maintained by less talented people so the art is in writing code at their level. Lets put it this way, if I am sorting a bunch of lists then the most efficient code is LISP, but given few people understand that the best option is more explicit Java code.
Assuming everyone has the same ability is just madness.
Its a very nice blog for...
architects in bangalore , architects in bangalore , interior designers in Bangalore , interior designers in Bangalore , architects in bangalore , architects in bangalore , interior designers in bangalore
Post a Comment