opinion please: study formal methods in University or bend to market reality?
S. Miller
Hi-
After 14yrs I.T. work I am returning to University.
I plan to get a B.S. in math with a possible M.S. in
mathematics so that I can study and apply formal methods
(eg. of the Maude/SPIN/RAISE/VDM kind.)
I think the following is true much of the time:
* I.T. does not do a proper job of getting
requirements (and TQM should be used to
impact this) and otherwise understanding
the importance of customer satisfaction.
* Even if I.T. does get proper functional
and non-functional requirements, I.T. does
not have any real tools to maximize the benefit
of analyzing the requirements before
code, test (eg. there is no real "CAD").
I mainly refer to functional requirements
here.
* I believe that formal methods will ultimately
become central to the way things are done.
Rose/UML, while certainly having the right intent,
focus too much on graphical-notation and not on
meaning/semantics.
* There is little to zero demand for formal
methods in the commercial world except for NASA,
Boeing, DoD, medical and other safety-critical work.
Questions for you:
1] Would you bend to the commercial market place
and get a B.S./M.S. in computer science and
forget about formal methods? Or would you
try to set the pace and do formal methods
anyway?
2] Do you know of any companies in the Washington
D.C. area that seek to employee I.T. people
who have a strong background in mathematics
and formal methods? Other cities?
3] How mature do you think formal methods are?
Do you have experience with RAISE?
4] How important do you think a degree is?
(While I plan to get one anyway, I would
personally answer the question like this:
degrees in C.S. are not demanded by the I.T.
market and are far less important than expectations
set in the medicine, architecture, physics,
chemistry etc.).
Carl Devore
On Thu, 27 Jun 2002, S. Miller wrote:
> After 14yrs I.T. work I am returning to University.
> I plan to get a B.S. in math with a possible M.S. in
> mathematics so that I can study and apply formal methods
> (eg. of the Maude/SPIN/RAISE/VDM kind.)
>
> * There is little to zero demand for formal
> methods in the commercial world except for NASA,
> Boeing, DoD, medical and other safety-critical work.
>
> Questions for you:
> 1] Would you bend to the commercial market place
> and get a B.S./M.S. in computer science and
> forget about formal methods? Or would you
> try to set the pace and do formal methods
> anyway?
Unfortunately, there is no demand for quality software until the customers
demand it. Today, a company producing commercial software with the
quality built in from the start will be crushed by competition from the
companies producing a buggy version of the same product sooner.
If you want to change this, perhaps you should become a lawyer. Software
should be held to the same quality standards as hardware (both computer
and non-computer hardware). Some lawsuits should enforce this point. If
you search on the web for stories of people who have been killed or
injured by faulty software, you might be surprised.
S. Miller
> demand it. Today, a company producing commercial software with the
> quality built in from the start will be crushed by competition from the
> companies producing a buggy version of the same product sooner.
>
> If you want to change this, perhaps you should become a lawyer. Software
> should be held to the same quality standards as hardware (both computer
> and non-computer hardware). Some lawsuits should enforce this point. If
> you search on the web for stories of people who have been killed or
> injured by faulty software, you might be surprised.
>
Carl:
a quick note in response ...
i totally agree with your assessment. i wrote
a long paper on TQM w.r.t. software just to examine
the issue of customer satisfaction.
part of the allure for formal methods is, because
software is outsourced so much, to reduce the risk
of miscommunication, that then leads to law suits.
IP rights and the legal issues around it are expensive.
my neighbor just folded a relationship with certain
well known American University for I.T./engineering
services over this (involving $1M+) precisely because
requirements where not understood and therefore product
was wrong. And because the requirements are not clear
they could sue this University even if they wanted to.
And the university is supposed to be an expert in the
area of interest.
Anyway, is this a *full* rebuke of your assessment?
NO. It has anyway been observed that since most
I.T. customers are I.T. people themselves ...
need I continue?
But it has to be asked: does the market leader
(esp. in new markets) ultimately own the market
after its been discovered by the competition?
ANSWER IS NO. This is important because the usual
"romantic notion" touted by software people is
that you *have* to be fast above all because fast
equals business success. Nonsense. It's just a
choice.
I spent 10 mins trying to provide the link but
cannot put my hands on it: anyway the economist
(www.economist.com) ran an article on this last month.
it cited about 7-10 products in which the company that
originally brought a new product to market didn't own it or
any appreciable part of the market for that product
later on. instead another company - who better understood
the market and quality and business execution etc. - did.
Diapers, Apple Computers, & disposable razors are three
examples. I think this article also reviewed a book
written on the subject. This is a partial argument against.
Prediction: SUN will not own the best app. server
or the dot in dotcom. Neither will netscape. Or maybe
6-sigma will save SUN.
The other allure is reuse: software can be reused if
the requirements can be reused. who has the time to
look into the code to reverse-engineer the requirements
just to see if the requirements can work elsewhere? many
requirements are domain requirements and are common to
the business in the long term anyway.
The other thing is this: fast and mean gets you
to a certain point. TRUE. but changes to a buggy
system become too complex and expensive afterwards.
These costs are passed on to the customer. Unless
you are microsoft (equals antitrust) or unless the
technology changes so often that people are required to
change over anyway (false economy), this will become
a problem even to the customer.
STILL, I would be interested in answers to my
*OTHER* questions. Thanks. I really want perspective
on the other questions too!!!!
Shane
Herman Jurjus
"S. Miller" <clear...@attbi.com> wrote in message
news:g3LS8.179896$nZ3.83590@rwcrnsc53...
[snip]
> STILL, I would be interested in answers to my
> *OTHER* questions. Thanks. I really want perspective
> on the other questions too!!!!
>
Well, actually, i do have a degree in math and formal methods, and am now
working in the IT.
For what it's worth, i don't believe in bug-free implementations of
specifications as providing a solution for useless or dangerous software.
Typically, the bugs start with the specifications, already.
What if the specification says
"click on button => you get a cop of tea with sugar",
and some day the machine gives a cup of tea with sugar *and diesel oil*?
That does satisfy the specification, you know...
Formal specifications are just some sort of computer instruction, just much
more abstract.
The problem is that human intelligence seems to be essentially incompatible
with the exactness of formal theories. All this is related to the question
why it is so difficult for most people to learn math.
A very interesting subject, indeed, but formal methods are part of the
problem, not of the solution.
Regards,
Herman Jurjus
S. Miller
> Well, actually, i do have a degree in math and formal methods, and am now
> working in the IT.
> For what it's worth, i don't believe in bug-free implementations of
> specifications as providing a solution for useless or dangerous software.
I don't believe this either. However, with something like SPIN
and other "formal methods" one can find violations to the known
specification and with less expense than finding the error during
code/test. Read: cheaper not better, or it is better because it is cheaper.
Indeed, I think a formal approach to specification helps reveals where
there are holes in the existing specifications.
Even in EE or Chem.Eng., if the specification is wrong much $$$ are wasted.
Formal methods are certainly not magic here - just cheaper to what
passes for normal.
> Formal specifications are just some sort of computer instruction,
> just much more abstract.
Yes. All I.T. work pertains to specification and its computable
properties. A computer program (eg. assembler/C/JAVA) is just a
specification.
I am curious:
* what industry do you work in?
* is it too personal to ask what company?
* other insight into how industry perceives a person with
skills not generally in demand?
* what formal method/lang. do you use? trained on?
* (in my simple understanding) formal methods must have a way
of exploring state space to determine violations to specification.
state space is typically much too large plus (again in my
limited understanding) there is the issue of the halting problem.
So to what degree can one examine state space looking for
holes, violations, and inconsistency?
* what's your view on software development - including -
requirement change management?
Ralph E. Frost
Herman Jurjus <h.ju...@hetnet.nl> wrote in message
news:afictm$egnjm$1...@ID-110648.news.dfncis.de...
...
> The problem is that human intelligence seems to be essentially
incompatible
> with the exactness of formal theories. All this is related to the question
> why it is so difficult for most people to learn math.
Afer reading some of R. Buckminster Fuller's works earlier in my life and
then going on to study and then ponder organic chemistry, I've ended up
agreeing with Fuller's notions that a very large part of the problem with
teaching/learning math arises from folks imposing an initial low-level
"cubic" formatting operation on carbon-based consciousness which, itself
is predominantly tetrahedral.
The tacit assumption involved in such an "educational" process boils down to
assuming that natural structure is cubic. Golly. Gee whiz. It's not.
The natural structure, as folks found out last century, is a lot more
tetrahedral than cubic.
The magnitude of this error, its pervasiveness and the implications are all
huge. Almost too overwhelming to think about. Yet also true.
Folks try to map things to a cubic view but in the process of beginning from
an overly approximate notion of structure, folks have had to add a wild
tangle of abstract mathematical expressions in the attempt to compensate
for the initial conceptual/frame of reference/formatting error.
This is basically why learning math is difficult for a very, very large
segment of the population. I expect it will take about four or five
years to correct the error globally.
Maybe a bit longer.
- Ralph Frost
http://www.refrost.com
Use more robust symbols
Seek a thought worthy of speech.