The Complexity And Tedium of Software Engineering
kentilton at gmail.com
Fri Jun 5 16:03:33 EDT 2009
Xah Lee wrote:
> On Jun 3, 11:50 pm, Xah Lee <xah... at gmail.com> wrote:
>> Of interest:
>> • The Complexity And Tedium of Software Engineering
> 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.
Quibble: those are not /tedious/. Those are as fascinating as an episode
of House, trying not only to get new information but how to get it and
how to figure out when some information already in hand is actually
misinformation, a classic solution to hard problems. Also figuring out
coincidences mistaken for cause and effect.
But that is just a quibble, ie, I think you need a different word, and
it is OK if it still conveys some form of unleasantness.
> 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. 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.
I think you are looking for an immaculate road system on a volcanic
island still growing ten feet a day.
> 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.
But when would we write the software? Even with all the head-banging,
look what we have been able to do with computers, leaving aside for the
moment the flight control algorithms of the Airbus?
When progress stops we will have time to polish our systems, not before.
But then you will be able to use the word "tedium".
More information about the Python-list