Re: When MV is not an option

Dawn:

"dawn" <dawnwolthuis@xxxxxxxxx> wrote in message
news:1133104466.045909.296230@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

[snipped]

> In spite of all of the abstraction of code and the higher level
> languages, given the distributed nature of software applications today
> it seems that it is even more the case that we need professional
> software developers writing code.

This is where we encounter the first of many conundrums in business software
development (BSD: If a process is to be computerized is it advantageous to
disassociate the process knowledge from the computing knowledge? (or is it
wise to segregate the process from the language?)

To compare this to other disciplines, one would have to be crazy to conduct
economic transactions where the medium of exchange changes depending on the
kind of goods/services purchased. Could you imagine going into a grocery
store and finding household items (laundry detergent) is sold with
Australian dollars, non-alcoholic beverages in Japanese yen, liquor in
Mexican pesos, meat in U.S. dollars, etc, etc, etc.

Since such a scenario is so self-evidently counter-productive, and
counter-intuitive, why do we accept such a model for business software
development; especially when so much of client-server architecture has
proven unreliable and unstable?

[snipped]

> JavaScript is about to have what
> PICK had many years ago -- lots of non-software developers writing
> code, driving in screws with hammers. In the case of PICK, subject
> matter experts could write software where with JavaScript web
> developers are learning to code. There are benefits to this, but you
> also end up with some awful code.

The main difference is that most old-time PICK code was highly guarded by
the developers and the kind of open source library, that exists with
Javascript, never existed.

[snipped]

> Agile methodologies such as eXtreme Programming (XP) suggest writing
> only what is required to fulfill the requirements for the current
> iteration of software and then refactoring the software to incorporate
> the next features, rather than planning for them in advance. While I
> disagree to some extent and do think it is important to think past the
> end of our noses when designing, we need to take more somewhat more
> short-term risk when we maintain software in order to have maintainable
> software for the long haul. If we refactor the code when we make a
> change, rather than simply figuring out where we could stick some lines
> of code into the current application, we will require more and better
> testing but end up with better software that can be maintained
> indefinitely.

This is where test planning and beta testing is critical. Several clients
who can test the changes are worth their weight in gold, when using this
model of "refactoring".


.

Relevant Pages

  • Re: Javascript Best Practices Document v1.0
    ... >> practices of FAQs. ... Anyone expecting the be paid for using javascript ... web developers are expected to use, but that employers almost never devote ... If I were you - someone repeatedly advocating reusable low-level functions ...
    (comp.lang.javascript)
  • Re: XP, a Criticism
    ... >> incrementally and use refactoring to expand the necessary functionality, ... > XP relies very heavily on customer participation and unless a customer ... > requirements to both the developers and the QA people. ...
    (comp.object)
  • Re: Browser support
    ... > probably about 1000 lines of javascript, ... I've been looking at XQuery, a dog of a spec, ... The hard part, of course, is convincing their developers that it's ... > Finally, pardon my ignorance--what's AJAX? ...
    (comp.databases.pick)
  • Re: XP, a Criticism
    ... > incrementally and use refactoring to expand the necessary functionality, ... XP relies very heavily on customer participation and unless a customer ... requirements to both the developers and the QA people. ... OO principles to ensure maintainability from one increment to the next. ...
    (comp.object)
  • Re: What is wrong with Ada?
    ... The discipline that Ada requires is at odds with the ... I also think Adaists are an evolutionary step beyond those who program ... Immediate gratification developers have the potential to ... effects of dangerous languages and haphazard techniques. ...
    (comp.lang.ada)
Loading