Re: Why Software Sucks
Posted: Sep 27, 2005 11:49 PM
Wow, what a popular exchange :-)
The biggest parallel I see, is the hardware world. In the hardware world, developers have standards such as voltage, current and in the analog/RF world, impedence. When the design hardware, there are a handful of interworking compatibility issues to deal with.
In the software world, we make up the incompatibilities at will. We can't make our software work together because it has a constraint that no other software can meet.
The Web Services programming mantra, where everything speaks XML over a handful of protocols, seems to me, to be an attempt (deliberate or not) at creating a BUS like mechanism for coupling software things together. The problem is that all things don't speak this protocol/interface either. So, we are trying really hard to put facades on everything old so that it looks like the new.
The problem with XML is that we are creating a protocol over the interface, with each such coupled piece of software. That software is designed and implemented to speak the protocol, so it's like a chip, but it has limited use. It has to speak to things very much like the things on the other end.
I think we're building, larger, more complex things than we need which create tons of couplings. All of this is because it is more expensive to create small things. Now, the EJB and other similar container models are attempts at making it easier to create small things to solve specific problems. The problem is that there's a very limited set of intefaces and protocols that an EJB "device" can see. Thus, it can't be used for just anything. It usually can only talk to a database, or be a piece of a web service. It can't be a simple desktop component that maps the size of all the files on your desk. It can't be a web browser plug-in that finds, via google, web pages like the one you are looking at.
The JVM is a very generic container, as is the smalltalk environment, the LISP environment etc. These all let us develop really small and really large pieces of software to solve specific problems. However, these environments/virtual machines have a tremendous mismatch and thus a smalltalk IDE can't run my Java program that I am developing. The LISP runtime, doesn't let me write some functions in Java because they are more procedural and less recursive in nature.
The internet is another BUS that we've all gotten used to use for some very focused applications such as web browsing, email, instant messaging etc. But, underneath, all of these applications share the same ability. They take something off the bus, or put something on the bus, and it gets used on the other side.
The reason that the data can be used on the other side is because there is a very specific expectation for the use. There are protocols and specification which create very focused uses of the data (well, the web browser is getting muddier day by day).
In some of the earlier discussion, the suck factor was linked to mismatches in expectations and knowledge. The whole MS-Word argument is amazing. MS-Word is the best because it fulfills requirements which are undocumented, and somewhat intractable to describe. It sets a standard that is unobtainable, because there is no specification of what needs to be achieved. Look at what MS has done with HTML over the years. It constantly submits changes and updates to the specification that meet the abilities of its browser in an attempt to standardize, but stay ahead in the game.
What we need to do, is decide "The network is the computer" and move on. We should do this because it requires protocols to be documented and interfaces to be confining. This helps manage the expectation and the knowledge gap so that everything is well known.
If we could get IPV6 in place, then every object that we create could be a service with a specific IP address. We could find it anywhere in the world and reuse it over and over. Okay, I know that sounds far fetched. But, there are some things that would definately improve.
The notion of lookup services such as those provided by many different platforms provide registration for each of the associated platforms. But, those registrations are invisible to others. We need standards and we need specs and limiting, controlling interfaces. Then, we can design software using tools instead of a paint brush. This would move us more towards a hardware model and way, far away from the artist model.