Hi all. I'm a long time lurker, but when I saw my article made the front page, I made an account. :)
I don't think that using tools makes us "bad"... I think pretending that we're "good" when we really need the tools make it much more difficult for us to past our egos and really look for what we need. There are so many great practices and tools available, but most developers I've encountered because things are "good enough". I was hoping to encourage people to try something new. Something a "good" programmer would never need, but a "bad" programmer would desperately want.
In regards to knowing the API versus using an IDE... spend some time with a Ruby developer. Someone who's not used to having great IDE support. They've been forced to learn the language. The difference in their productivity level is amazing. Contrast them with a developer who only learned Java or dot Net and was using Eclipse or Visual Studio from day one. Those developers tend to not learn the underlying APIs and I think it hurts their ability to know what functionality and libraries are available to them.
Anyway, it's very cool seeing an article I wrote on HN!
Wait, what? OP claims that we are bad programmers because we use too many tools:
We can't remember all the methods our code needs to call, so we use autocompleting IDEs to remind us.
and then recommends using tools to become better programmers:
These tools flag common mistakes... really common mistakes.
I know I'm in the minority because I've had this debate with almost every programmer I know, but I do not use an IDE for exactly this reason. I want the "firmware" that knows how to assemble building blocks of code to be in my brain, not in my computer. To me, writing code is like driving a stick shift, for much of it I don't even think, it's unconscious competence. Can you imagine driving a car with auto-complete, color coding, or drop down menus? To this day, I get pissed off when something doesn't compile the first time, usually because of a typo.
There's a time and a place for every tool. An IDE or test suite is like a back brace or crutches; they are indispensable when you really need them, but they only weaken you when you're healthy. I guess I draw the line in a different place from OP (and almost everyone else I know).
Why is there such massive nerd-rage when it comes to people using IDEs versus what amounts to text editors with scripting toys?
IDEs are fantastic and I am a more productive programmer for using one. I work with a pretty big codebase and just having excellent cross-file navigation and usage searches are big time-savers. Color coding allows me to establish a visual understanding of more code at a glance which is especially useful when I didn't write it. Integrating with source control directly from your editor gives you fine-grained organization when you are working on multiple changes in parallel. Task managers (ie, Mylyn or Atlassian), in conjunction with source control integration, significantly reduce the overhead time that is required to perform workflow-related management during the day. And despite my hacker pride, I love having good debugging tools around as they are wonderful at aiding in maintenance.
Code completion saves you time and accelerates learning. Maybe I'm in the minority here, but I simply cannot understand why autocomplete makes you so bad. Once your team grows to beyond 4-5 programmers, you're going to be seeing plenty of code you didn't write yourself. A knowledge of naming conventions and design patterns allow you to use autocomplete to help find the behavior you want before turning to documentation or duplicating it yourself. At the very least, it helps me type faster because I am typing less and it helps me avoid spelling mistakes. Autocomplete is a search tool and a typing assistant; it does not create a black hole in your brain that sucks away any memory of what you have seen or done in the code.
If you find a function that is useful, stop and find out what it does. Why are you calling it if you don't know what it does? If you don't remember it after the first time, you probably will have it committed to memory by the third. And who cares if you don't remember it, do we really need to know every API of every library we use? No, we used it as a tool to get the job done. We have precious few brain cells to spend them on memorizing an ever-changing dictionary; let the computers do what they do so well.
I use Textmate and occasionally vim when the situation arises. They are excellent tools for certain types of work. But when I'm working on a feature in a big codebase, there is no place like my IDE. It takes care of all of us average programmers at average companies.
> " I want the "firmware" that knows how to assemble building blocks of code to be in my brain, not in my computer. To me, writing code is like driving a stick shift, for much of it I don't even think, it's unconscious competence. Can you imagine driving a car with auto-complete, color coding, or drop down menus? To this day, I get pissed off when something doesn't compile the first time, usually because of a typo."
Well said. I've also had the argument a few times, but have given up trying now.
You could also compare it to a novelist using a "Writing IDE" to create a story. Click "John", Click "Conversation with Kate", Fill in the speechmarks, click "Build suspense macro". It would be mental to write a novel that way, so why do some people write programs that way and then look surprised when they end up with rubbish code.
> To me, writing code is like driving a stick shift, for much of it I don't even think, it's unconscious competence. Can you imagine driving a car with auto-complete, color coding, or drop down menus?
Can you imagine driving a car with power windows, turn signals that turn off after you complete the turn, etc?
I dislike IDEs for all their features which for the most part I think just add clutter, since I've ever found a use for most of them like debuggers etc. but I'll admit that they are useful if done right and can bring a productivity boost.
When I have to write things like:
strstr($str, $delimiter)
and
explode($delimiter, $str)
Netbeans ctrl+p comes in very handy in re-enforcing my choice of arguement order because if I make a mistake that's a very subtle bug waiting to happen.
or when I have to wrote things like:
g_file_new_for_commandline_arg
who wants to type that out when they don't have to?
or this over and over:
AStudpidlyLongName::
when I can just type `ast` and press ctrl+[space] and get the name in a completion list highlighted every single time.
or:
m_ui->tooBar->addWidget
when I can m_ui.t... and have to automatically figure the correct sequence, this comes in pretty handly when you're working code written by other and they decide to use hard objects as opposed more common pointers.
I used to think I'm a bad programmer, and I was. But ever since I'm doing my startup, I'm concentrating on one project in one language, instead of ten different things in 4 different languages. My co-founder and I found and agreed on a practical subset of the language (C++), and we write great code. I'm still a "bad programmer" in the sense that if I wrote Javascript code, it'd not be great, but now I know that the key to success is to concentrate on one thing for a long time --- and actually it's possible to be a "good programmer" if you do that. Okay, I still don't do enough testing, but in our case (distributed DB) the long-term smart solution is to hire a test engineer..
You sir get a gold star, The big reason that projects fail is "technology soup", everyone has to get their pet project or technology into the project. It gets worse the bigger the projects get. When you get to the enterprise where the big project are, you get governance and a bunch of design by committee. Where people who are not writing the code, tell the people that are "here is what you are going to use".
It is funny but every time I walk into a project that is "fad" programming I see failure. When I walk in a see a bunch of guys heads down, iterating and releasing the most crucial features first, the project always seem to succeed. Maybe the solution is less magic technology dust not more.
While this doesn't necessarily negate the "we can't remember syntax" argument...I remember back before mobile phones were rampant, I was really great at remembering phone numbers. People besides by parents were regularly surprised at how I'd remember numbers I'd seen or read just once. Then I got a mobile phone.
I think I probably have less than 5 numbers memorized (those of my immediate family). In essence, using an IDE encourages us not to memorize syntax.
Am I the only one who feels the whole egoless programming thing has gone too far? Yeah, ego is a bad thing. But self-esteem and confidence aren't. I'm not afraid to say that I feel I'm good at what I do.
That doesn't mean I'm never wrong or that I don't make mistakes. It just means I'm proud of my abilities.
Great post! Some suggestions that were new to me, too, although you're mixing Java and Ruby in your examples.
I agree with everything except the DSL stuff at the end. People have mentioned on HN recently, and I believe it is true, that Cucumber, etc. may be something customers get involved with in the beginning, but then they lose interest in it. Sure there are a number of other things that vary from place to place like politics, conformance to standards, etc. But, customers typically just want to see results (in a reasonable amount of time). If you spend time on good design/UI/UE (read "nice looking and easy to use"), it is fast, it doesn't break, and you've tweaked to their needs, you're set.
I've spent more time in Ruby and Java than other languages. My background is leaking through. :) Feel free to post any other tools to the comments on the article.
Re: DSLs... I don't think the DSL specs always stay in front of the customer (they sometimes do), but they're a valuable tool. Whether it's a developer, a technical customer, or a non technical customer, you've provided a much simpler way to show what the system does. That's a huge win.
I also find that developers who spend time in DSLs tend to write much cleaner code. Once you get used that level of abstraction, you use it in other places.
I can't imagine using autocomplete or even an IDE. I remember when I first started I was writing C++ on Windows in Visual C++. My learning only accelerated once I moved off Windows and stopped using autocomplete. Once I started working on Linux and in vim, I didn't even consider looking back.
I like to think I'm a minimalist when it comes to my tools, so obviously my experiences and insights are very different from someone working in an IDE. I prefer the command line to a gui any day.
Does anyone still believe there are really any ground breaking insights to be made in these kind of self-loathing rhetoric articles?
Shouldn't there be more "You know what, sometimes just having something work is pretty much awesome" articles instead of everything fooling themselves that every programmer in the world needs to be a mini-genuis?
A big theme in programming is to get as much complexity out of one's head and into the computer as possible. In this regard, I consider the IDE an extension of the high level language. Whether I use one depends on what I'm coding in. I'm usually fine with gedit when coding Python. In Java, the IDE helps cut through the verbosity.
There is some truth to this article - humans are much worse than machines at simple, regular processes. Manufacturing eventually figured out how to divide up labor along the assembly line and automate as much as possible to make the process regular. Software is comparatively in its infancy. Maybe we will see a similar progression as companies replace the artistry of software with more standardized, repeatable processes. I probably won't be coding then.
The article starts of a little depressing, telling the reader that humans are bad at programming and we have no hope. At least it finishes telling us we just need to use a bunch of cool toys to look smarter.
I always thought it strange to consider it 'cheating' to rely on a powerful IDE. A programming language is a tool - nobody think it is cheating or a sign of weakness to use the most powerful/productive programming language suitable for a task. An IDE is similarly a tool, which complements the language - just as the code we write is basically a tool.
Not true. If you have the details in your head, you can manipulate and compare them far faster than if you have to rely on an external tool. That means you can rehearse more ideas, faster, which will lead to a better likelihood of picking the best one.
Remembering things is VERY important. It means you have an instant grasp of the code base, the APIs available to you. It means you can solve problems much quicker than someone who only has a limited memory, or uses auto-complete all the time.
Personally i dont use an IDE, i use gedit because it does what i want, colour coding, auto indentation and a file browser pane that supports (s)ftp (but i suppose thats actually the OS), thats all i'll ever want or need.
If you want to use an IDE, then by all means go ahead, but if your trying to hire me, dont make me use it, and dont make me use an OS i dont like either.
Everyone's different and they've got their own way of working, just let them do it their way and they'll be more productive, they'll achieve what you're after.
"Jared Richardson works at Logos Technologies As a recognized expert in the software industry..."
Take note of the word EXPERT. He claims developers are bad programmers yet he is an expert. It's contradicting or maybe the right word in the bio should be WORST? :P
Does anyone know why user access_denied, who has a [dead] sibling comment to this comment, seems to have been "hell banned"? Showdead needs to be set to true to see the comments or profile.
You know it sucks. Find the right tool set and practices to help your clients improve. You can't fix it overnight, but there's ~so~ much room for improvement in our industry.
This simple and completely true statement never ceases to fascinate me:
> In short, as an industry, we all stink.
We really do stink and we as an industry are nowhere near a state where there are any real standards and best practices in place like e.g. when building a skyscraper or a road. Those are fairly to pretty damn complicated tasks and there is so much knowledge, experience and best practice involved and everyone in the construction industry (should..) knows them and when it is done you can have it checked and certified that it was well built and won't crumble the next day.
I don't think anything like this even remotely exists in IT. We have a lot of RFCs describing protocols and what not but nobody can really objectively certify your serious-business software as well-built or can verify whether you applied even the smallest best practices or common sense guidelines because there are so many almost religious wars being fought over completely minor advantages and dis-advantages which simply do not matter on a global scale.
And far too many really, really actually bad programmers just get away with their mess or horrible, insane code.
We need to remember that computers are young. Really, really young. The invention of the first-ever electronic digital computer is still an event within living memory.
This can be hard to remember. Especially when you yourself are young, you're used to thinking of things that are even slightly older than you as eternal. (When you reach my age, and you are beginning to have colleagues who literally weren't alive during formative periods of your early career, you get a deeper appreciation for the fact that people -- including yourself -- have these horizons.) For example, I did graduate work on lasers, and I built my work on top of a great deal of earlier work, so I tend to think of lasers as things that have been around for a long time. But the laser isn't very old. It turned fifty this year. Many of my friends are older than the laser. Many of its early pioneers are still wandering around.
Look up the early years of engineering. Read certain chapters of the excellent Structures, or Why Things Don't Fall Down, or for a more personal view check out Chapter 20 of Mark Twain's Life on the Mississippi:
The early history of tall buildings is the history of towers falling down. The early history of modern bridges is the history of bridges collapsing. The early history of steam-powered transportation is the history of boiler explosions, especially in the USA, which had a reputation for quick-and-dirty mechanical hacks as far back as the early 19th century. These situations took decades to change... or longer. Sometimes an order of magnitude longer.
And, crazy ideas about the Singularity notwithstanding, technology proceeds at a human pace. Right now, we're still at the point where substantial portions of the world population don't even have access to a computer (although the smart phone promises to change that). Very few people know how to program at any level. And that is the major issue facing programmers today, as it has been since the microcomputer was invented in the 1970s: There is more value in spreading the temporary hacks around more widely and cheaply than there is in inventing more permanent and solid stuff. Until we can meet the insatiable and growing demand for poor implementations of 1970s-era computing technologies, there's really no time or money for anything else. This condition is probably temporary, but when I say "temporary" I may still be talking on the scale of decades.
Many "real world" building projects far exceed the originally estimated cost; some of them are not very stable at all, and scale badly when put under strain that wasn't originally envisioned.
Software development is not nearly perfect, but neither is engineering of "real" buildings. My farther in law is a civil engineer, and when I told him that I believed that engineering in his discipline worked much better than in the software industry, he just gave me a disbelieving look and called me naiive.
I think the use of some of these strategies mentioned are what should be best practice. Code coverage checkers and code analysis tools, most specifically.
[+] [-] JaredRichardson|15 years ago|reply
I don't think that using tools makes us "bad"... I think pretending that we're "good" when we really need the tools make it much more difficult for us to past our egos and really look for what we need. There are so many great practices and tools available, but most developers I've encountered because things are "good enough". I was hoping to encourage people to try something new. Something a "good" programmer would never need, but a "bad" programmer would desperately want.
In regards to knowing the API versus using an IDE... spend some time with a Ruby developer. Someone who's not used to having great IDE support. They've been forced to learn the language. The difference in their productivity level is amazing. Contrast them with a developer who only learned Java or dot Net and was using Eclipse or Visual Studio from day one. Those developers tend to not learn the underlying APIs and I think it hurts their ability to know what functionality and libraries are available to them.
Anyway, it's very cool seeing an article I wrote on HN!
[+] [-] edw519|15 years ago|reply
We can't remember all the methods our code needs to call, so we use autocompleting IDEs to remind us.
and then recommends using tools to become better programmers:
These tools flag common mistakes... really common mistakes.
I know I'm in the minority because I've had this debate with almost every programmer I know, but I do not use an IDE for exactly this reason. I want the "firmware" that knows how to assemble building blocks of code to be in my brain, not in my computer. To me, writing code is like driving a stick shift, for much of it I don't even think, it's unconscious competence. Can you imagine driving a car with auto-complete, color coding, or drop down menus? To this day, I get pissed off when something doesn't compile the first time, usually because of a typo.
There's a time and a place for every tool. An IDE or test suite is like a back brace or crutches; they are indispensable when you really need them, but they only weaken you when you're healthy. I guess I draw the line in a different place from OP (and almost everyone else I know).
[+] [-] netmau5|15 years ago|reply
IDEs are fantastic and I am a more productive programmer for using one. I work with a pretty big codebase and just having excellent cross-file navigation and usage searches are big time-savers. Color coding allows me to establish a visual understanding of more code at a glance which is especially useful when I didn't write it. Integrating with source control directly from your editor gives you fine-grained organization when you are working on multiple changes in parallel. Task managers (ie, Mylyn or Atlassian), in conjunction with source control integration, significantly reduce the overhead time that is required to perform workflow-related management during the day. And despite my hacker pride, I love having good debugging tools around as they are wonderful at aiding in maintenance.
Code completion saves you time and accelerates learning. Maybe I'm in the minority here, but I simply cannot understand why autocomplete makes you so bad. Once your team grows to beyond 4-5 programmers, you're going to be seeing plenty of code you didn't write yourself. A knowledge of naming conventions and design patterns allow you to use autocomplete to help find the behavior you want before turning to documentation or duplicating it yourself. At the very least, it helps me type faster because I am typing less and it helps me avoid spelling mistakes. Autocomplete is a search tool and a typing assistant; it does not create a black hole in your brain that sucks away any memory of what you have seen or done in the code.
If you find a function that is useful, stop and find out what it does. Why are you calling it if you don't know what it does? If you don't remember it after the first time, you probably will have it committed to memory by the third. And who cares if you don't remember it, do we really need to know every API of every library we use? No, we used it as a tool to get the job done. We have precious few brain cells to spend them on memorizing an ever-changing dictionary; let the computers do what they do so well.
I use Textmate and occasionally vim when the situation arises. They are excellent tools for certain types of work. But when I'm working on a feature in a big codebase, there is no place like my IDE. It takes care of all of us average programmers at average companies.
[+] [-] ryanwaggoner|15 years ago|reply
Have you been in a car built in the last few years?
[+] [-] RyanMcGreal|15 years ago|reply
I took from the essay that the tools we use are evidence of our bad programming ability, not the cause of it.
Incidentally, I mainly code in gedit, for much the same reasons you cite.
[+] [-] points|15 years ago|reply
Well said. I've also had the argument a few times, but have given up trying now.
You could also compare it to a novelist using a "Writing IDE" to create a story. Click "John", Click "Conversation with Kate", Fill in the speechmarks, click "Build suspense macro". It would be mental to write a novel that way, so why do some people write programs that way and then look surprised when they end up with rubbish code.
[+] [-] pavel_lishin|15 years ago|reply
Can you imagine driving a car with power windows, turn signals that turn off after you complete the turn, etc?
[+] [-] DisposaBoy|15 years ago|reply
When I have to write things like:
and Netbeans ctrl+p comes in very handy in re-enforcing my choice of arguement order because if I make a mistake that's a very subtle bug waiting to happen.or when I have to wrote things like:
who wants to type that out when they don't have to?or this over and over:
when I can just type `ast` and press ctrl+[space] and get the name in a completion list highlighted every single time.or:
when I can m_ui.t... and have to automatically figure the correct sequence, this comes in pretty handly when you're working code written by other and they decide to use hard objects as opposed more common pointers.[+] [-] Maro|15 years ago|reply
I used to think I'm a bad programmer, and I was. But ever since I'm doing my startup, I'm concentrating on one project in one language, instead of ten different things in 4 different languages. My co-founder and I found and agreed on a practical subset of the language (C++), and we write great code. I'm still a "bad programmer" in the sense that if I wrote Javascript code, it'd not be great, but now I know that the key to success is to concentrate on one thing for a long time --- and actually it's possible to be a "good programmer" if you do that. Okay, I still don't do enough testing, but in our case (distributed DB) the long-term smart solution is to hire a test engineer..
[+] [-] kls|15 years ago|reply
It is funny but every time I walk into a project that is "fad" programming I see failure. When I walk in a see a bunch of guys heads down, iterating and releasing the most crucial features first, the project always seem to succeed. Maybe the solution is less magic technology dust not more.
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] SanjayUttam|15 years ago|reply
I think I probably have less than 5 numbers memorized (those of my immediate family). In essence, using an IDE encourages us not to memorize syntax.
[+] [-] j_baker|15 years ago|reply
That doesn't mean I'm never wrong or that I don't make mistakes. It just means I'm proud of my abilities.
[+] [-] devmonk|15 years ago|reply
I agree with everything except the DSL stuff at the end. People have mentioned on HN recently, and I believe it is true, that Cucumber, etc. may be something customers get involved with in the beginning, but then they lose interest in it. Sure there are a number of other things that vary from place to place like politics, conformance to standards, etc. But, customers typically just want to see results (in a reasonable amount of time). If you spend time on good design/UI/UE (read "nice looking and easy to use"), it is fast, it doesn't break, and you've tweaked to their needs, you're set.
[+] [-] JaredRichardson|15 years ago|reply
Re: DSLs... I don't think the DSL specs always stay in front of the customer (they sometimes do), but they're a valuable tool. Whether it's a developer, a technical customer, or a non technical customer, you've provided a much simpler way to show what the system does. That's a huge win.
I also find that developers who spend time in DSLs tend to write much cleaner code. Once you get used that level of abstraction, you use it in other places.
[+] [-] reynolds|15 years ago|reply
I like to think I'm a minimalist when it comes to my tools, so obviously my experiences and insights are very different from someone working in an IDE. I prefer the command line to a gui any day.
[+] [-] tomlin|15 years ago|reply
I'm cool with that because I know I am gradually becoming better and better each day.
I invoke 3 core principals/ideals:
* No matter how good you are, someone is always better than you. Yes. Always.
* Surround yourself with people smarter than you, rather than shun them egotistically. Intelligence is contagious.
* Admit fault, show humility to others who do the same.
[+] [-] weego|15 years ago|reply
Shouldn't there be more "You know what, sometimes just having something work is pretty much awesome" articles instead of everything fooling themselves that every programmer in the world needs to be a mini-genuis?
[+] [-] ndl|15 years ago|reply
There is some truth to this article - humans are much worse than machines at simple, regular processes. Manufacturing eventually figured out how to divide up labor along the assembly line and automate as much as possible to make the process regular. Software is comparatively in its infancy. Maybe we will see a similar progression as companies replace the artistry of software with more standardized, repeatable processes. I probably won't be coding then.
Kind of reminds me of http://xkcd.com/378/
[+] [-] twymer|15 years ago|reply
[+] [-] argv_empty|15 years ago|reply
I thought memorizing all of the details of these was only important in school, and even then only at exam time.
[+] [-] olavk|15 years ago|reply
[+] [-] regularfry|15 years ago|reply
[+] [-] points|15 years ago|reply
[+] [-] TamDenholm|15 years ago|reply
If you want to use an IDE, then by all means go ahead, but if your trying to hire me, dont make me use it, and dont make me use an OS i dont like either.
Everyone's different and they've got their own way of working, just let them do it their way and they'll be more productive, they'll achieve what you're after.
[+] [-] JaredRichardson|15 years ago|reply
I'd appreciate any help spreading the word. I'm involved with much more of the technical sites than the managerial ones.
[+] [-] jister|15 years ago|reply
"Jared Richardson works at Logos Technologies As a recognized expert in the software industry..."
Take note of the word EXPERT. He claims developers are bad programmers yet he is an expert. It's contradicting or maybe the right word in the bio should be WORST? :P
[+] [-] JaredRichardson|15 years ago|reply
[+] [-] Tichy|15 years ago|reply
[+] [-] barrkel|15 years ago|reply
http://news.ycombinator.com/submitted?id=access_denied
It disturbs me that, looking over past submissions and comments, there doesn't seem to be any egregiously bad behaviour.
[+] [-] patio11|15 years ago|reply
[+] [-] twymer|15 years ago|reply
[+] [-] JaredRichardson|15 years ago|reply
[+] [-] access_denied|15 years ago|reply
[deleted]
[+] [-] known|15 years ago|reply
[+] [-] jasonlotito|15 years ago|reply
[+] [-] kahawe|15 years ago|reply
> In short, as an industry, we all stink.
We really do stink and we as an industry are nowhere near a state where there are any real standards and best practices in place like e.g. when building a skyscraper or a road. Those are fairly to pretty damn complicated tasks and there is so much knowledge, experience and best practice involved and everyone in the construction industry (should..) knows them and when it is done you can have it checked and certified that it was well built and won't crumble the next day.
I don't think anything like this even remotely exists in IT. We have a lot of RFCs describing protocols and what not but nobody can really objectively certify your serious-business software as well-built or can verify whether you applied even the smallest best practices or common sense guidelines because there are so many almost religious wars being fought over completely minor advantages and dis-advantages which simply do not matter on a global scale.
And far too many really, really actually bad programmers just get away with their mess or horrible, insane code.
[+] [-] mechanical_fish|15 years ago|reply
This can be hard to remember. Especially when you yourself are young, you're used to thinking of things that are even slightly older than you as eternal. (When you reach my age, and you are beginning to have colleagues who literally weren't alive during formative periods of your early career, you get a deeper appreciation for the fact that people -- including yourself -- have these horizons.) For example, I did graduate work on lasers, and I built my work on top of a great deal of earlier work, so I tend to think of lasers as things that have been around for a long time. But the laser isn't very old. It turned fifty this year. Many of my friends are older than the laser. Many of its early pioneers are still wandering around.
Look up the early years of engineering. Read certain chapters of the excellent Structures, or Why Things Don't Fall Down, or for a more personal view check out Chapter 20 of Mark Twain's Life on the Mississippi:
http://www.classicreader.com/book/2886/21/
The early history of tall buildings is the history of towers falling down. The early history of modern bridges is the history of bridges collapsing. The early history of steam-powered transportation is the history of boiler explosions, especially in the USA, which had a reputation for quick-and-dirty mechanical hacks as far back as the early 19th century. These situations took decades to change... or longer. Sometimes an order of magnitude longer.
And, crazy ideas about the Singularity notwithstanding, technology proceeds at a human pace. Right now, we're still at the point where substantial portions of the world population don't even have access to a computer (although the smart phone promises to change that). Very few people know how to program at any level. And that is the major issue facing programmers today, as it has been since the microcomputer was invented in the 1970s: There is more value in spreading the temporary hacks around more widely and cheaply than there is in inventing more permanent and solid stuff. Until we can meet the insatiable and growing demand for poor implementations of 1970s-era computing technologies, there's really no time or money for anything else. This condition is probably temporary, but when I say "temporary" I may still be talking on the scale of decades.
[+] [-] perlgeek|15 years ago|reply
Just one link: http://en.wikipedia.org/wiki/Scottish_Parliament_Building#Ti...
Software development is not nearly perfect, but neither is engineering of "real" buildings. My farther in law is a civil engineer, and when I told him that I believed that engineering in his discipline worked much better than in the software industry, he just gave me a disbelieving look and called me naiive.
[+] [-] twymer|15 years ago|reply