On Mon, 2003-08-18 at 17:00, Finkbine, Ronald B. wrote:
All in all some interesting comment but also some parochialism.
>It is almost certainly the case that there are software developments
>that use 1960s views of development organizations but is there really
>any need to further enshrine such outdated views of development by
>researching such systems.
I didn’t realize that ALL ideas from the past have been discredited. I must have
missed that. I still choose to use a QWERTY keyboard. Maybe we should revisit the past
with things that have worked in the past and try another development lineage. Total
discredit? Not worth even looking at again? Doesn’t sound like science at work to
me, more like religion.
>Whilst provably correct programs are a bonus the constructivist view of
>formal development has yet to show that it is workable in real
>development environments.
I would think that most developers would invite some method of showing (proving) their
software is correct if it were in a usable/doable tool/methodology. DFA’s seem to be
that form of computation model. But this depends on what type of REAL development you
seem to be talking of. Small systems can be coded by small teams, large systems are
more problematic. Small teams coding large systems with very limited interaction (or
no interaction as you seem to subscribe to) leads to the embarrassing admission from
Microsoft that this fall they are going to reduce their company-wide automatic
software-patch-installers programs from eight to two (one for apps and one for the
OS). How does a overall very successful company allow eight different programs do
effectively the same thing? Eight-fold duplication!! Sounds like someone needs to be
talking/coordinating with others.
If you object to the term system analyst, why not just have the configuration
management (CM) person coordinate the test cases. Same difference, just different
terms. Who does the system architecture for the whole system, one team of 2 who code 8
hours a day? Someone higher on the education/experience curve has to write the
system-wide test cases. Thirty programs do not make a workable system without
coordination.
In some system, provable is a requirement not a luxury. Heart monitors, aviation
software, and DSP do not do well with the GOOD ENOUGH mentality that most
programmers/companies have today. Just ship it, we’ll fix the bugs later……
>Forgive me but this is a very 1970s view of database-centered
>application development and therefore not a good start point since the
>world has moved on.
But the world hasn’t moved on. Research is being done on a number of areas that
require a database [reversing a computation, self-diagnostic systems (why this
program just died but don’t throw me into the debugger!!!), evolutionary programs].
Every one of this NEEDS a database. By the by, isn’t the craze about XML and the
like about interchange of data that must reside somewhere?
>I am not sure "Cleanroom" approaches can work in these days of SQL, C++,
>Java, etc. since there is no sensible mathematics to describe exactly
>the semantics for the size of program most systems are these days.
Sensible mathematics/methodologies can be invented if we are allowed to do that. I
already covered the programs-too-big thing.
>Success in a project is more easily obtained when everyone takes ownership of the
>>problem directly.
Unless of course you have a weak team, maybe a bright office worker moved into the
coding department. You cannot always have smart (top 25%) personnel to build into
sharp teams. Some countries/industries/companies don’t have an oversupply of bright
folks with the right educational background and experience ready to move into the next
big project.
Software development methodologies and tools need to work with AVERAGE programmers
which, silly me, I thought this group was about.
> must stuff about working together, self-directed, cooperation, philosophy,
> >confrontation, suffering and star wars films…… deleted.
No final authority on a project? No UNIX guru in the lab helping people or would
having one be too divisive? I suppose too much knowledge in one person dispirits the
rest of the staff.
Maybe I am too involved with common programmers, not above average ones. I taught a
couple years at a liberal arts college with very bright students (mostly American) who
didn't want to work too hard at college. I would much rather teach at a regional state
university (like I do now) with fairly bright average people. Many have been thrust or
walked into the software departments at their companies and need to finish a degree to
stay or get promoted. Many are already coding without much educational background. The
USA labor department sees a need for technology workers of 300k+ per year (I last
looked about a year ago) and we graduate 35k people per year with CS degrees in the
US. That is a lot of vacum pulling in non-CS people. How can they code, be controlled,
be productive if no one will do it?
This discussion is depressing. Like much of what passes for computer science research
today (look up words like [agile | extreme] with software on Google), everyone has a
new methodology or new tool that no one else will use or will only work in small
amounts. We discuss and argue, words just chase each other around the page, getting
nowhere fast.
Ron Finkbine
[EMAIL PROTECTED]
�
`�ˬ����جr�,�������.�Ɲ�)���X���^�ɚ�Y���Y���b�ا~�݊�.��'���q杚)���X���^�ɚ�Y���Y���b�ا~�ڞz.�Ǐ<����.�ƫr�zm����
��V�r�y�&�جr�,�Ji�
+�
