The Complexity And Tedium of Software Engineering

[John Thingstad]

På Fri, 05 Jun 2009 08:07:39 +0200, skrev Xah Lee <xahlee at gmail.com>:

> On Jun 3, 11:50 pm, Xah Lee <xah... at gmail.com> wrote:

> The point in these short examples is not about software bugs or
> problems. It illustrates, how seemingly trivial problems, such as
> networking, transferring files, running a app on Mac or Windwos,
> upgrading a app, often involves a lot subtle complexities. For mom and
> pop users, it simply stop them dead. For a senior industrial
> programer, it means some conceptually 10-minutes task often ends up in
> hours of tedium.

What on earth gave you the idea that this is a trivial problem?
Networks have been researched and improved for the last 40 years!
It is a marvel of modern engineering that they work as well as they do.

>
> In some “theoretical” sense, all these problems are non-problems. But
> in practice, these are real, non-trivial problems. These are
> complexities that forms a major, multi-discipline, almost unexplored
> area of software research.

Again, it is it not a trivial problem theoretically.
Unexplored? What world are you on?

> I'm trying to think of a name that
> categorize this issue. I think it is a mix of software interface,
> version control, release control, formal software specification,
> automated upgrade system, etc. The ultimate scenario is that, if one
> needs to transfer files from one machine to another, one really should
> just press a button and expect everything to work. Software upgrade
> should be all automatic behind the scenes, to the degree that users
> really don't need fucking to know what so-called “version” of software
> he is using.
>

Actually they mostly are. At least on my machine. (I use Windows XP and  
Ubuntu Linux.)

> Today, with so-called “exponential” scientific progress, and software
> has progress tremendously too. In our context, that means there are a
> huge proliferation of protocols and standards. For example, unicode,
> gazillion networking related protocols, version control systems,
> automatic update technologies, all comes into play here. However, in
> terms of the above visionary ideal, these are only the beginning.
> There needs to be more protocols, standards, specifications, and more
> strict ones, and unified ones, for the ideal scenario to take place.
>

No, there are already to many protocols and the ideas of how a network  
infrastructure should be built are mostly in place. I think we would  
benefit from "cleaning up" the existing interface. That is by removing  
redundancy.

What does need further research is distributed processing. Again this is a  
highly complex problem and a lot of work has been put into trying to make  
simpler and more manageable interfaces and protocol's. See for example the  
languages Erlang and Oz to get an idea.

---------------------
John Thingstad