The Artima Developer Community
Sponsored Link

Weblogs Forum
Deterministic Software Development

45 replies on 4 pages. Most recent reply: Mar 22, 2007 2:43 AM by Steve Johnston

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 45 replies on 4 pages [ « | 1 2 3 4 | » ]
James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Kung Fu styles Posted: Jul 14, 2006 6:32 AM
Reply to this message Reply
Advertisement
> Software Development should be like the Kung Fu styles:
> Fast, Slow, Strong, Smooth, etc.

I'm a big fan of the monkey and drunken styles of programming.

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: Kung Fu styles Posted: Jul 14, 2006 1:29 PM
Reply to this message Reply
"I'm a big fan of the monkey and drunken styles of programming."

I see.

Which should be fine if that's all that you need. :-)

Seriously, it's really an issue of scaling, adapting...

I'm not here thinking as the programming school:
"Paper: 'The camel has two humps' - Programming Aptitude Test"
http://www.cs.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf

One size fits all does not seem to be a good way to tackle the programming needs. Sometimes you may want to program with Design by Contract, Static Typing, Unit Testing, Quality Assurance. While in other times you might want to go without some of the previous resources. Sometimes you will have plenty of resources of a big organization, other times you might have a couple of friends only.

The question is: If your organization is resourceful, couldn't you use other techniques as well as you would use your pet techniques? With the same rate of success? With maybe a better rate of success?

I know that it's to ask too much sometimes -- to simply ask for change. Though the world changes, and with it you need to change as well.

Dima Berastau

Posts: 3
Nickname: xored
Registered: Jul, 2006

Re: Kung Fu styles Posted: Jul 15, 2006 5:45 PM
Reply to this message Reply
> Traditionally, you ask the person to commit to a date,
> then if it's done by that date, you got your money's
> worth. If not, then you're not getting good value, so to
> speak. The problem is, this doesn't work well with
> software of any non-trivial complexity.

I think/hope most projects would begin with an estimate. As you get more done you update the estimate. "The date" is virtually always a moving target that you refine as you go along.

>
> People want to be assured that they are not "screwed", so
> to speak. The problem is -- it's IMPOSSIBLE to know. The
> only person who can even have a hope of judging a
> programmer is another programmer of equivalent experience
> and domain of expertise. That's why programmers like open
> source -- because the judgement of peers is meaningful.
>

That's taking it a bit too far. There's usually a contract that details (more or less) what the customer wants and this is where you are trying to get to, right? Customers are not interested in "the good vibes" you had while coding and hence appreciating your work on some "deeper" level. What they want is a functional product. Nothing wrong with that.

>
> And then the very notion of value is extremely subjective
> and inconstant. For example, how do you know if an apple
> is worth 1 dollar? Well, you have to taste it for one.
> But what if it tastes great? To some, that means it's
> s worth even 10 bucks. To others even a great tasting
> apple is not worth more than 5 cents.
>

Economists have been eating these apples and oranges for well over 200 years. There's of course a whole bunch of opinions but the dominant approach with neoclassical economics is that of marginal utility. The price you pay for things is basically the result of a dynamic equilibrium between sellers and buyers that captures average value of whatever it is you are willing to pay for. That's a simplification of course, but it's still useful.

> This problem will never be solved. For this reason,
> programming will never be a happy job. Oh, programming
> can be pure bliss if you do it for yourself, or out of
> love, unconcerned about any judgements or money (but
> that's not what I call "a job"). But if you ever have to
> report to anyone or if you ever do it for someone else, it
> will always be a mediocre experience at best, because the
> other person will likely doubt the value they're getting,
> and there really will be no objective/reliable way of
> proving the value either.

I don't really see why other people's "feeling of value" has anything to do with you enjoying the work you do. I try to have a good time programming (for money or not) and not worry about what other people "might" think.

Back to the point... given our current state of knowledge, software development processes are non-deterministic. If some very bright psychologist comes up with a model that can predict people's behaviour in a frequently changing environment I'll be the first to use it! We don't have much right now.

However, it's not all chaos either, is it? When we are incapable of formalizing all this stuff into a model what comes into play is experience... I was reading an interview with Marvin Minsky (AI guru) the other day - I think it's in MIT Technology Review - and what struck me as interesting is that after all this time we still can't get a computer to draw the simple logical connections a 3-4 year old can do. That should be enough to put ALL deterministic theories of software development in perspective.

In the end of the day it is VERY difficult to disagree with Bruce on this one. Shouldn't this be common sense? I find it quite strange that people are willing to pull in a whole bunch of physics examples and say "Things are deterministic... if we know XYZ". But that's the whole point. We don't know XYZ. And provided that we don't know XYZ the approach should account for that rather than ignore it.

Back in the real world I think most people implicitly use a non-deterministic model. The whole idea of short and focused iterations is to contain "the unknown" factors and make mistakes in small steps.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Deterministic Software Development Posted: Jul 17, 2006 1:31 AM
Reply to this message Reply
> > Not really. No matter what new functions enter a
> system,
> > it is known a priori...otherwise programs would not
> > compile. All the kinds of inputs a program can have are
> > there in implicit form, known by the programmers, but
> not
> > known by the compiler.
>
> I think you are missing the point. We are talking about
> software development processes, not the software itself.

Not really.

Software development processes can easily fail because software tools are not as good as they should have been.

New people on a team can create code that breaks the whole system, because tools(i.e. compilers and such) are happy to accept whatever is thrown to them without restrictions.

If the tools were right, the chance of screwing a project by newcomers would be minimal.

To put it differently, the knowledge of the constraints of a program exists within the brains of the old members of a project and thus newcomers do not have an easy way to extract that knowledge.

My opinion is that knowledge must be encoded inside programs, so as that failure risk is minimized.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Deterministic Software Development Posted: Jul 17, 2006 6:05 AM
Reply to this message Reply
> > > Not really. No matter what new functions enter a
> > system,
> > > it is known a priori...otherwise programs would not
> > > compile. All the kinds of inputs a program can have
> are
> > > there in implicit form, known by the programmers, but
> > not
> > > known by the compiler.
> >
> > I think you are missing the point. We are talking
> about
> > software development processes, not the software
> itself.
>
> Not really.
>
> Software development processes can easily fail because
> software tools are not as good as they should have been.
>
> New people on a team can create code that breaks the whole
> system, because tools(i.e. compilers and such) are happy
> to accept whatever is thrown to them without
> restrictions.
>
> If the tools were right, the chance of screwing a project
> by newcomers would be minimal.
>
> To put it differently, the knowledge of the constraints of
> a program exists within the brains of the old members of a
> project and thus newcomers do not have an easy way to
> extract that knowledge.
>
> My opinion is that knowledge must be encoded inside
> programs, so as that failure risk is minimized.

By suggesting that risk is something that can be minimized and therefore exists, you are implicitly recognizing that software development is not deterministic.

Juancarlo Añez

Posts: 12
Nickname: juanco
Registered: Aug, 2003

Re: Deterministic Software Development Posted: Jul 17, 2006 5:51 PM
Reply to this message Reply
> I have a passing knowledge of Prolog (and some of its
> variants). One purveyor, Amzi! (not a typo), claims that
> multi kilo line java/C/etc. suites get replaced by 100
> line Prolog programs. And having worked with the
> language, I can see how that might be. But using such a
> language requires a suspension of control: the code is
> working out an answer from some data that you can't see.
> Side effects, and self modifying code, are designed in.
> . Not my cup of tea.

Actually, "rule engines", which are in vogue right now are not much different from prolog with side effects.

When I studied Prolog at the university it was considered "closer to the problem domain".

Take a look at Microsoft's approach to workflow management in .Net. It features deterministic algorithms that produce non-deterministic but probably correct results from the user perspective.

JA

Juanca

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Deterministic Software Development Posted: Jul 18, 2006 1:06 AM
Reply to this message Reply
> By suggesting that risk is something that can be minimized
> and therefore exists, you are implicitly recognizing that
> software development is not deterministic.

I think you are confused about what determinism is. A system is deterministic when it is defined by a set of laws so as that no matter what the input, the result depends on the laws only, and hence any future state of the system can be predicted.

The above is irrelevant to our capability of running the calculations required in order to predict a system's outcome. A system may be deterministic, but we may not possess the capability to calculate its outcome.

Software development is a deterministic process which can be so complicated that it may seem like being non-deterministic to us...but it actually is. The "degree" of determinism (we can not say that, but for the sake of discussion) depends on the correctness of our systems. Since most systems are correct less than 100%, the percentage of error increases exponentially with any new factor introduced in the system.

To put it simply, if the tools were right, no matter what a person could do, he could not mess up a system. Since the tools have holes, dangers exist.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Deterministic Software Development Posted: Jul 18, 2006 6:33 AM
Reply to this message Reply
> > By suggesting that risk is something that can be
> minimized
> > and therefore exists, you are implicitly recognizing
> that
> > software development is not deterministic.
>
> I think you are confused about what determinism is.

Well considering that you think deterministic implies determinism, you are clearly confused. Determinism is a philosophy: http://www.google.com/search?hl=en&q=define%3A+determinism

Detetministic is a technical term: http://www.google.com/search?hl=en&lr=&q=define%3A+deterministic

Specifically in this case: "Referring to events that have no random or probabilistic aspects but proceed in a fixed predictable fashion."

> A system is deterministic when it is defined by a set of
> laws so as that no matter what the input, the result
> depends on the laws only, and hence any future state of
> the system can be predicted.
>
> The above is irrelevant to our capability of running the
> calculations required in order to predict a system's
> outcome. A system may be deterministic, but we may not
> possess the capability to calculate its outcome.

And therefore you cannot prove it to be deterministic. Moreover your belief that it is determinstic has no pragmatic value as there is no way to make use of it.

> Software development is a deterministic process which can
> be so complicated that it may seem like being
> non-deterministic to us...but it actually is.

And what evidence are you basing this belief upon?

> The "degree"
> of determinism (we can not say that, but for the sake of
> discussion) depends on the correctness of our systems.

How does the outcome change whether the system is deterministic? Just because you get the result you expected doesn't mean the system is deterministic.

> Since most systems are correct less than 100%, the
> percentage of error increases exponentially with any new
> factor introduced in the system.
>
> To put it simply, if the tools were right, no matter what
> a person could do, he could not mess up a system. Since
> the tools have holes, dangers exist.

Great theory. Get back to us once you prove it or even demonstrate it to a basic degree.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Deterministic Software Development Posted: Jul 18, 2006 5:49 PM
Reply to this message Reply
Bruce Eckel wrote
-snip-
That's the step I think the agilists have taken. I think all the agile methods have in common that they shorten the feedback loop and create lots of little experiments with evaluations and course corrections in between. I suspect that a lot of the resistance to this is because it doesn't promise a deterministic solution like methodologies of the past have promised, and if you are very attached to determinism, you can't be satisfied with that.

(I think all the iterative methods have in common that they shorten the feedback loop and ...)

Which "methodologies of the past" promised a deterministic solution?

A book I bought 15 years ago was titled "Strategies for Software Engineering: The Management of Risk and Quality". Pick up a book on project management and you might read - "Life is full of uncertainty. Project managers call that risk."

Not much sign of deterministic solutions there.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Deterministic Software Development Posted: Jul 18, 2006 6:09 PM
Reply to this message Reply
James Watson wrote
> Someone else posted a study like this. I have a big
> problem with both:
>
> "The findings came from NICTA’s study of 400 projects in
> the U.S., Australia, and Chile, using questionnaires
> and interviews
to discuss success and failure factors
> with practitioners."
>
> This is not an experiment testing software development.

There's no claim on the slides or in Robert Glass's article that this was an experiment testing software development.

http://nicta.com.au/uploads/documents/NICTAJuneVernerJun2006%20(2).pdf

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Deterministic Software Development Posted: Jul 19, 2006 5:34 AM
Reply to this message Reply
> There's no claim on the slides or in Robert Glass's
> article that this was an experiment testing software
> development.
>
> http://nicta.com.au/uploads/documents/NICTAJuneVernerJun200
> 6%20(2).pdf

I'm sorry, when did this become a behavioral science forum?

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Deterministic Software Development Posted: Jul 19, 2006 8:16 PM
Reply to this message Reply
> > There's no claim on the slides or in Robert Glass's
> > article that this was an experiment testing software
> > development.
> >
> >
> http://nicta.com.au/uploads/documents/NICTAJuneVernerJun200
>
> > 6%20(2).pdf
>
> I'm sorry, when did this become a behavioral science forum?

You're apology is accepted. When did this become a physics forum :-)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Deterministic Software Development Posted: Jul 20, 2006 5:58 AM
Reply to this message Reply
> > > There's no claim on the slides or in Robert Glass's
> > > article that this was an experiment testing software
> > > development.
> > >
> > >
> >
> http://nicta.com.au/uploads/documents/NICTAJuneVernerJun200
>
> >
> > > 6%20(2).pdf
> >
> > I'm sorry, when did this become a behavioral science
> forum?
>
> You're apology is accepted. When did this become a physics
> forum :-)

Last week ;)

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: Deterministic Software Development Posted: Jul 26, 2006 12:28 PM
Reply to this message Reply
For the record, I have just seen a comment on Slashdot that explains the culture (Japanese even) that I believe helps the overall outcome of a company:
http://it.slashdot.org/comments.pl?sid=192206&cid=15784528

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Deterministic Software Development Posted: Jul 28, 2006 2:48 AM
Reply to this message Reply
> Well considering that you think deterministic implies
> determinism, you are clearly confused. Determinism is a
> philosophy:
> http://www.google.com/search?hl=en&q=define%3A+determinism

Determinism is a word that in some contexts means 'a philosophy' and in some other contexts means 'deterministic state' as you described.

> And therefore you cannot prove it to be deterministic.

Of course we can prove it. If something is defined 100% with a set of 100% known laws, then it is provably deterministic.

> Moreover your belief that it is determinstic has no
> o pragmatic value as there is no way to make use of it.

Don't be so sure about it. See the link at the end of this post.

>
> > Software development is a deterministic process which
> can
> > be so complicated that it may seem like being
> > non-deterministic to us...but it actually is.
>
> And what evidence are you basing this belief upon?

What do you mean 'what evidence'? have you ever seen a truly random error? I haven't. All the bugs I've seen, and I mean 100%, were due to violation of constraints.

> How does the outcome change whether the system is
> deterministic? Just because you get the result you
> expected doesn't mean the system is deterministic.

Why not? since a system's behaviour is mathematically proved, and the result of experimentation is consistent, it means determinism is at work.

> Great theory. Get back to us once you prove it or even
> demonstrate it to a basic degree.

Check out this link:

http://www.nasa.gov/centers/ames/research/exploringtheuniverse/exploringtheuniverse-computercheck.html

It talks about CGS, a system which analyses the code and finds run-time bugs at compile time. It works by pretending it is executing the code, but it does not.

The CGS system works exactly like I have proposed in some other posts:

http://www.artima.com/forums/flat.jsp?forum=106&thread=153973&message=201404&redirect=true&hilite=true&q=achilleas+margaritis

So, I'll say what I have repeatedly said: whatever I can do with my mind, so can a tool do. In the same way I, the human, can catch bugs, so can tools.

Flat View: This topic has 45 replies on 4 pages [ « | 1  2  3  4 | » ]
Topic: Deterministic Software Development Previous Topic   Next Topic Topic: Working Effectively With Characterization Tests

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use