Am I asking for too much?
I am currently participating in a interesting thread on Matt Berther’s bog on my podcast. I commented on his post Blasting open source
because I felt my podcast was not meant to pick on up source projects although part of it could be interpreted that way. So since then what I have been explaining is why I don’t see any innovation happening in software today.
Although I like .NET and Java I think there has been no real innovation in software in the last 30 years. The primary things I see as the backbones of what we use computers for are:
- Databases - CODASYL defined the standard for network databases in 1969 (RDMBS were first described by Codd in the 1960’s and 70’s at IBM)
- Word Processing - The Unix Concepts of text formatting for publishing came around in the 1970’s (as a matter of fact UNIX was first designed as a text editing and text formatting system). Although UNIX text processing is much more akin to HTML then WYSIWYG editors like MS Word
- Spreadsheets - First patented in 1971, VisiCalc was actually being distributed for the Apple II in 1979
- General Programming via high level Languages -
a) Interpreted Languages (If you want the full deal Smalltalk was around in the 1970’s. Object oriented, dynamically typed and reflective)
b) Compiled Languages (Cobol was created in 1959 and C in 1972) - WIMP Interfaces - (Pioneered by the Xerox Alto in 1973)
- The Internet which started in 1969.
So if you take as a baseline of 1980 we have had these systems around for at least 28 years. Most have been around longer. Sadly I have been programming for 30 years so I have played with some of these at one time or another in my career.
Do I expect too much? I can’t help but see the feature set of these products though and say that on the whole the pace of innovation in computers disappoints me. Those advances we do see to have picked up come about more because of hardware advances then software advances. As Brooks says in No Silver Bullet
…the anomaly is not that software progress is so slow, but that computer hardware progress is so fast.
As I see it we continue to attack the accidents of software engineering. I quote from Brooks
If we examine the three steps in software technology development that have been most fruitful in the past, we discover that each attacked a different major difficulty in building software, but that those difficulties have been accidental, not essential, difficulties.
The three that he describes include:
• High Level Languages. Now this would include java and C#.
• Time Sharing. Now this would be the entire concept or personal computers, laptops, PDA’s etc… essentially ways to get the answer immediately.
• Unified frameworks. Here he talks about UNIX, but you can also include in this the .NET framework and the Java class libraries.
So my contention is that one of the reasons software innovation is so slow is we spend too much time reinventing what we have had since the 1970’s and not focusing on advancing the art of computer science. Am I wrong? So many of the things we see in the Open Source and Commercial World are clones of each other. Are we as developers taking the simple way out? Sure we can design a new enhanced WIMP interface, but that is because we already know most of the requirements except for that little tweak we are going to make? It is fun to do these kinds of projects because we don’t have to think about the hard stuff like requirements analysis, test cases and design. We just set down and code another build system, or IOC Container or OS.
We continue to attack the accidents because the essentials are so difficult. I was doing some reading on the System.Speech namespace in .NET and Natural Language Processing in general. One of the big things required to get these to work is to put together grammars for what we want the computer to do once it has recognized the words. The problem is almost no one is building the grammars. Why is that? Because it is hard. It would require us to step outside of the fun and simple things we do and take on some difficult tasks. The same thing could be said for coming up with systems that use common component architecture. How much simple would things be if we started building components and plugging them into applications. As David said in my Podcast, I want to drag and drop a CRM solution.
What does it take to get to these? We have to give up on some of the fun things we do and start attacking the essential problems in software development. Am I expecting too much? Are we as Software Engineers unable to tackle our discipline as a engineering science and start innovating again?
** Portions of this entry were posted a a comment on Matt’s blog ***
Filed under: Uncategorized
[...] Am I asking for too much? By dcarver Here he talks about UNIX, but you can also include in this the .NET framework and the Java class libraries. So my contention is that one of the reasons software innovation is so slow is we spend too much time reinventing what we have … Elegant Code - http://elegantcode.com [...]
I think you are asking too much! Look at this from a much larger perspective: most humans, not just software geeks, would rather do the fun/easy stuff because it’s a lot more fun/easy. The fact that my car has tires that only fit my particular model of car (damn you ford automotive engineers), but only gets 18 miles to the gallon is a great example of this. True innovation is rare, no matter what your venue.
I don’t think you are asking too much. But I think you are asking for it from the wrong people, in the wrong place, while picking on the wrong things. By attacking the free market for software, you are (to use your terms) attacking an “accident” of the way things are. But its not really an accident, its really just the way things are in the real world.
You’ve stated previously that you think software innovation is slow because software folks spend so much time “reinventing” things as opposed to “advancing the art of computer science”. Well I don’t think that is the case. First, software innovation is slow because it is incremental. Deal. And second, The Wizard book’s preface states that their conviction is that “‘computer science’ is not a science and that its significance has little to do with computers”. Therefore, the heart and soul of computer science is “the techniques used to control the intellectual complexity of large software systems”. (http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-7.html) We, as software developers, should focus on controlling intellectual complexity to advance the art of computer science; not dragging and dropping a CRM solution. And I would argue that we are advancing the art of computer science, regardless of your perception that it is an “accident”.
Well I’m glad to see you haven’t left your pontificating ways behind you.
To chime in I would have to echo Mike’s thoughts with the complexity of the systems that we are trying to create but I also agree that at some level we are still doing the same things we have always done just with a different wrapper and/or new shiny name.
One of the reasons I think I’m still programming and enjoying it so much is because of the artistic side of software development. Maybe that’s another topic, but like artists today and artists 200 years ago programmers and programming techniques today aren’t that much different than they were 20 or 30 years ago. What has changed is the objects and systems that we are using these tools to create.
To that end while we may still be using many of the same tools, or new shiny remakes of old tools, it is the creations that we put on the canvas and the applications that we develop that truly show real advancement. To that end I think we have made incredible progress. I agree with you that our tools haven’t changed. (For example, my favorite comment about the new ASP.Net MVC framework is that it lets me code classic ASP again only feel cool about doing it.) But you must admit that we have made incredible progress in our creative use and application of those tools. The tools will continue to be useful until they begin to limit our creativity.
@Andrew It seems to me that there is a bias that we need to be given something that will make our code better. I can’t help but contrast that to what Jim Weirich said about simplicity at MountainWest RubyConf 2008: start with a Small Core, build Simple Rules, and use Powerful Abstractions. His focus was to build your solution up rather than design it from the top down.
http://mtnwestrubyconf2008.confreaks.com/15weirich.html
If you hop out of the Microsoft world for a bit, you might change your criteria for what counts as shiny or new.