Re: Rent seeking
Posted: Sep 22, 2005 2:59 PM
> first question: do we prefer to keep a
> [sequential|batch|procedural] process? if so, then stay
> with the COBOL. but you'll have a nasty impedence
> mis-match with the GUI. i'm up to my knees in that again.
> superficially, the demo shows a neat clickable, tabbed,
> , check boxed, etc. interface. just like Word. what the
> users (cats) find out after the Suits buy the stuff is
> that it really isn't like Word at all. you have to do A
> then B then C. if you don't, you get some cryptic error.
> of course, the procedure is never written down, since to
> o do so admits that it isn't like Word at all. it's still
> that nasty old Procedural Suite they used to have. then
> everybody gets irritated. what's worse (see Spolsky, et
> al), is that the GUI is not well suited to heads-down data
> entry, which much of corporate software really is. it
> shouldn't be like Word at all.
So that example would seem to fall into e.g., the cat food problem, the expectation problem, the don't know what we're trying to solve problem, and the suckered by the shiny bauble problem.
If there's that many problems, how can we possibly hope to create even just decent sofware?
>> What are the (dis-)incentives on
>> the managers to actually fix the problem?
> the incentive is to be able to sell the WhizBang Software
> Suite for the next decade. but if WBS is already behind
> the technology curve, because they've been riding that
> rented mule for 20 years, they often choose to ride it
> into the ground.
So is that as much an issue of inertia as anything else?
> > But isn't it rational to, say, write emulators for those
> > old mainframe platforms to run on the latest hardware
> > instead of trying to extract all of the years of
> > accumulated wisdom that's embodied in the old program?
> welllll, that leaves the paradigm mis-match still there.
> not much different from wrapping the MF COBOL with "web
> b services". the real issue is paradigm shifts (or not):
> event vs. procedural, file vs. database. also, often that
> "accumulated wisdom" isn't very smart: this kind of
> software generally implements mission-critical process.
> lots of advances have been made, and embodied in new
> w software. for example: inventoried vs. JIT
> manufacturing. the olde style software can't support
I totally agree. Alas, IME, rather than seeing the opportunities, people use all of that as yet more excuses to stick their heads in the sand. I.e., their analyses are completely asymmetric: With the old product, they heavily inflate its goodness and discount its failings while with the potential new solutions they heavily discount the potential and inflate the actual risks. Alas, given how wretched most software sales pitches are, it's hard to fault them too much.
Also, this brings up the fear of change. I.e., in your example, isn't an underlying issue really the fact that the organization is so set in it's ways that it is unable to change? Perhaps, ala Blade Runner, we should build in termination dates for organizations?
> > What I'm trying to get at is where's the crux, the chasm,
> > across which we have to make a transformative decision
> > rather than a status quo decision.
> the future. does the software house (or in-house, for
> that matter) still want to be viable in 5 years. if not,
> grab the lipstick. M$ has been doing much the same thing
> with windoze for a llllllllong time. Excel stole 1-2-3.
> which stole VisiCalc. imagine the return on investment if
> Bricklin could have controlled all that!!!!!!!!!!!
Ah but what's the value of the marketing? Regardless of what we might think about the technological merits, MS changed the game in terms of marketing power.
> > So it's the old "bread and circuses" excuse? Okay but
> > then how does that explain all of the crappy software for
> > developers that's written by developers?
> well, the stuff i use isn't really crappy: SlickEdit,
> wincvs, cvsnt, and jswat. 3 are Open Source. i used M$
> tools years ago.
Hmm... Is that to say that suckage is relative?
I mean, really, CVS is a wretched mess of an SCM. JSwat is an interesting example to me personally since I spent a few years using the original Swat.
> > So, what do we need to add to the mix to help make e.g.,
> > rational decisions for the mid- and long-term?
> if *we* are the developers, then some way to prove to the
> Suits that there *is* a long-term. or find another
> start-up. all of this crappy software did get built for
> the first time, once. not all of it was crappy when it
> did something new and better. and the history of software
> isn't all that long. not like, oh, civil engineering.
> the 360 is 40 years old. IBM doesn't like to admit it,
> , but the zSeries is not much different in architecture.
> and on purpose. in some ways, there's never been a
> a long-term in the software business.
Indeed. So perhaps it's just a question of patience in terms of waiting for people to grow up? Perhaps but I figure I'll be dead long before that happens. :-)
> what happened before that doesn't much count. the two
> paradigm shifts since then: databases, GUI. the Web is
> retrograde so far as paradigms go: a disconnected block
> mode interface, that's CICS 1968. unix circa 1990 had
> character mode connected databases. very cool. edit on
> each key stroke against the database. except for the
> pixels, Web stuff is very old hat. the java kiddies don't
> know this, of course. they just see the pixels.
> and so on. it's the Time Horizon. isn't that the edge of
> Black Holes?
Indeed, it's been really funny watching the pendulum swing back and forth. All of the hoopla over "AJAX" is just unbelievable to me.
Do you think anything technological is really helping this problem? For example, is the shifting view of programmers due to unit testing actually helping people think better?