The Artima Developer Community
Sponsored Link

Weblogs Forum
Deterministic Software Development

45 replies on 4 pages. Most recent reply: Mar 22, 2007 5: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 | » ]
Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Deterministic Software Development Posted: Jul 13, 2006 10:39 AM
Reply to this message Reply
Advertisement
> The problem with the n-body problem is not that the
> computation is difficult it's that it doesn't settle into
> a clean cycle. Given the weights, starting points and
> velocities of the objects, determining the forces at that
> point is fairly straightforward but determining how these
> properties far in the future requires calculating all the
> future states between here and there. No matter how fast
> the computer can calculate the states, we can ask for a
> state a future point that will infeasible to calculate.
>
> However, I think you are ignoring a key characteristic of
> software that makes ut unlike the n-body problem. In the
> n-body problem the intial state provides all the
> information needed to claculate any future state. This is
> not the case in software. The information at the
> beginning of a software project is incomplete partly
> because there will events during the progress of the
> project that cannot be predicted and people are very
> unpredictable.

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.

Software can not fail if properly structured. In fact, software never fails, it just does what it is being told to do. If a pointer is null and crashes the program or a memory block is freed twice (for example), then it is the programmers' fault.

It just happens that the mainstream programming languages do not allow the programmers to express their intentions as specifications dictate. For example, I can not tell the compiler that 'this number is always from 5 to 10' or 'this pointer is never null'.

The result of this is cascading failure: millions of dollars damage from systems that are down due to a combination of inferior programming languages and "lazy" programmers (their laziness is justified though, because the languages do not offer an easy way out).

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Deterministic Software Development Posted: Jul 13, 2006 10:52 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.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Deterministic Software Development Posted: Jul 13, 2006 11:17 AM
Reply to this message Reply
> >Deterministic: Referring to events that have no random or
> probabilistic aspects but proceed in a fixed predictable
> fashion.
>
> Maybe I need to brush up my english, English is my second
> language.
> According to
> http://en.wikipedia.org/wiki/Deterministic_system_(philosop
> hy) : Deterministic system is
> "Some of these systems are complex, and events may be
> difficult to predict in practice, but if the starting
> conditions were known in enough detail, the outcomes of
> events in such systems could be predicted."
>
> So maybe you can point me to a page that better explain
> Deterministic than that?

No, that's a prefect definition. I think the problem may be the context and a lack of specificity in the defintion.

In this context, predictable means you can know the exact outcome. For example, a deterministic coin flip would allow you to say with absolute certainity that the result would be heads or that with absolute certainity that the result would be tails but if all you can say is that it's 50/50 heads or tails, it's not deterministic. Please note that this is just an example, I am not amking any claims about whether flipping a coin is actually deterministic or not and don't want to get sidetracked on that.

Now where I think the confusion may come in is if you structure the experiment to say that the expected result is 50% heads with a specified margin of error, you can say the result was 100% correct and therefor deterministic but really, we can never rule out odd occurences like flipping 1000 heads in a row so the experiment is still not strictly deterministic.

> "Social determinism is the hypothesis that social
> interactions and constructs alone determine individual
> behavior (as opposed to biological or objective
> factors)."
> http://en.wikipedia.org/wiki/Social_determinism
>
> >Are you suggesting that you can predict the behavior of
> an individual or group with 100% accuracy?
>
> There exists studies that show that a predict the behavior
> in a group can be done, if the enviroment is controlled, I
> will try and remember what the name of the experiments
> are.

So you believe you can set up an situation where you know exactly what a given individual will do? Not 60% of people will do A but 100% John Smith will do X. That would suggest to me that all people's brains work the same way and at the very least that insanity is not a real phenonmenon.

> "Behaviorism, an approach to psychology based on the
> proposition that behavior can be researched scientifically
> without recourse to inner mental states, is usually
> considered to be deterministic and opposed to free will."

Well if that's really what it proposes, it's been proven wrong:

Look at the Migram experiement: http://en.wikipedia.org/wiki/Milgram_experiment

"In Milgram's first set of experiments, 67.5 percent (27 out of 40) of experimental participants administered the experiment's final 450-volt shock..."

If the behavior of humans was deterministic, the result would 100% one thing or the other. You could then propose that there are other factors (like upbringing) that affect the results but that cannot be confirmed nor denied (currently) in any experiement that doesn't violate people's inherent rights (in my belief system.)

Bruce Eckel

Posts: 868
Nickname: beckel
Registered: Jun, 2003

Re: Deterministic Software Development Posted: Jul 13, 2006 2:04 PM
Reply to this message Reply
> "One of the assumptions of many behaviorists is that free
> will is illusory, and that all behaviour is determined by
> a combination of forces comprising genetic factors and the
> environment, either through association or
> reinforcement."

The key word being "assumption." There are any number of other psychological theories that make other assumptions.

Grant Olson

Posts: 3
Nickname: granto
Registered: Jul, 2006

Re: Deterministic Software Development Posted: Jul 13, 2006 2:56 PM
Reply to this message Reply
> > "One of the assumptions of many behaviorists is that
> free
> > will is illusory, and that all behaviour is determined
> by
> > a combination of forces comprising genetic factors and
> the
> > environment, either through association or
> > reinforcement."
>
> The key word being "assumption." There are any number of
> other psychological theories that make other assumptions.

And even if the theories were valid, I'd prefer not to have an installer for a program ask questions like:

Did you wet the bed as a child?
Have you ever tortured a small animal?

and include a urine sample so that it can deterministically predict my behavior. ;-)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Deterministic Software Development Posted: Jul 13, 2006 2:57 PM
Reply to this message Reply
> > "One of the assumptions of many behaviorists is that
> free
> > will is illusory, and that all behaviour is determined
> by
> > a combination of forces comprising genetic factors and
> the
> > environment, either through association or
> > reinforcement."
>
> The key word being "assumption." There are any number of
> other psychological theories that make other assumptions.

I think it's pretty clear that in any event, human behavior can be classified as a 'chaotic system' as described in the book 'Chaos' I mentioned earlier. Note that this is not what most people think of as chaos.

Dino Octavian

Posts: 15
Nickname: dinoo33
Registered: Jul, 2006

Re: Deterministic Software Development Posted: Jul 13, 2006 5:34 PM
Reply to this message Reply
>
> Bruce,
>
> you are mixing determinism and complexity, which are two
> totally different concepts.
>
> Software development is deterministic, in the same manner
> that the 3-body problem is: the outcome is predictable
> through a set of laws, no matter how complex the software
> is or how many bodies we throw to the problem.
>
> But that does not mean we can solve the equations! maybe
> we do not have the methodology or the computing power to
> examine such complex problems.

Actually determinism is conditioned by complexity. Determinism fails as soon as the complexity of our deterministic methods is less than the complexity of the object of study. The difference in complexity is reflected in the random behavior we observe on our subject.

We can solve the equations for a 2 body system and give exact predictions for any initial conditions. We can write the equations for a 3 body problem. And maybe we can even solve the system. But we cannot predict what the outcome will be out of many possible outcomes because infinitely small variations of the initial conditions choose one outcome or the other. Without one single prediction, there is no determinism. Adding more complexity to the problem, for the perfect gas made of lots of billiard ball like molecules, we cannot write neither the equations (too many) nor the initial conditions (can't even measure them: Maxwell's Daemon problem). Not even numerical methods help here. The ONLY approach we have is stochastic. The ideal gas problem is non-deterministic, although we know the deterministic rules governing the movement of each individual molecule. The complexity of the gas is way bigger than the complexity of our deterministic method of analysis. Determinism fails completely. In quantum mechanics determinism fails at a very fundamental level: our observation method is not complex enough to handle the complexity of the subject. Determinism fails because it is forbidden of us to know everything on the subject at any given point in time.

If determinism would not be failing on complex systems, there would be no need for statistical physics and statistical thermodynamics, quantum mechanics ... Entropy would not exist as a concept and there would no need for Plank's constant. Physics would be a closed chapter of human knowledge. Determinism is too simple to handle reality.

My assertion is that for software development, determinism fails early, at a very fundamental level, just like it fails in quantum mechanics. It is impossible to know everything about "the software" at any given point in time.

But don't take my word for it. Try and get a status on your current project. Try to know everything about it. Then the very second you find the unexpected bug in the code that stops the release of the day, please realize that you didn't know it all. It is impossible to know it all.

Leo Lipelis

Posts: 111
Nickname: aeoo
Registered: Apr, 2006

Re: Deterministic Software Development Posted: Jul 13, 2006 6:35 PM
Reply to this message Reply
Bruce,

I agree with you 100%. I think you made a great post.

Frankly, programming deals with mind and its concepts. Mind and its concepts, both, are ultimately unfathomable. Concepts give an impression of understanding, but only as long as we don't question them deeply. However, if we begin to seriously question our own concepts (especially the ones we hold most dear), we find they quickly crumble. The only thing that keeps concepts appearing stable is our own reluctance to mess with them, to question them, and so on.

Please examine for example logic. Logic is a system of rules for transforming and inferring statements in a conventionally valid manner. For example, if you start with a statement such as "ice is cold" and then say "'cold' is a temperature", then you can infer that ice is said to have a property of a temperature in a way that is conventionally considered valid. But if you say "ice is a temperature", then you have perverted "the system" and such statement would be considered illogical. But the most important thing about logic is that it, by itself, DOES NOTHING!! Logic has no use without some assumptions! Without some statements to transform or to use as the basis for inference, logic has no application. Therefore, all our knowledge is essentially baseless, as it is based -- at its root -- on assumptions that are themselves based on nothing at all. And our experience confirms this quite nicely every day, and yet we still refuse to see this.

Programming, unlike any other human endeavour, touches the very heart of this phenomenon. Since programming deals with mind and its concepts, all bets are off. Mind is stranger than quantum mechanics, by far.

Fact is, that our capacity for error continues undiminished. There is no evidence whatsoever that as the time goes "forward", our chances of making mistakes tend to 0. Since our error rate is about constant, there is basically no chance for us to converge on "the solution", or some deterministic approach. To admit this in ourselves is a sign of maturity. To fail to admit that is a sign of idealism. Essentially, determinism is a certain species of idealism. Determinism is not a pragmatic approach.

Just my .02c.

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Kung Fu styles Posted: Jul 13, 2006 7:17 PM
Reply to this message Reply
Software Development should be like the Kung Fu styles: Fast, Slow, Strong, Smooth, etc. Meaning that it should be adapted to the different problems.

Even the atoms, which are so small already and are responsible for the compositions of the structures that we can see with bare eyes, even the atoms are composed of even smaller parts, like electrons. And it's all dynamic.

Our body! Even though we have plenty of cells and whatnot, we also have organisms external to us, but that since we were born began joining our body. To some animals, such external organisms are very important to them, like bacterias that help with the digestion of cellulose, for instance.

Buildings! Buildings need all kinds of materials, varying from the strong steel to the fragile but transparent glass.

Even in software we have some flexibility. We have the pointer arithmetic in the lower level tools that power the more high level tools that use garbage collection and generally may want to avoid pointer arithmetic.

What we don't have in software development is consensus. But it's fine. We, while programmers, aren't superhumans. We can't reason deeply and get to only one conclusion, because no other group of professionals can do that. We generally agree to disagree, which is fine. We are always asking that same thing that was asked in the Jerry Maguire film: "Show me the money." Which is the same as "I believe it when I see it."

I just happen to think that we need all the tools that we can get, but an open mind is welcome as well.

For instance, dynamic typing may not be as strong as steel, but if it's like rubber or glass, maybe it will fit in your Engineering when you need to create your new thing.

Bruce Eckel

Posts: 868
Nickname: beckel
Registered: Jun, 2003

Re: Kung Fu styles Posted: Jul 13, 2006 8:25 PM
Reply to this message Reply
Nice comments, practically poetic!

I will (possibly) coin a word here: auto-determinism. When you believe everything is deterministic, you can only see deterministic behavior, so you don't question that view. A very difficult place to move from.

Leo Lipelis

Posts: 111
Nickname: aeoo
Registered: Apr, 2006

Re: Kung Fu styles Posted: Jul 14, 2006 1:07 AM
Reply to this message Reply
Bruce,

I think the main issue is a human one: how do I make sure I'm getting my value?

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.

So, how else can people know they get good value? Well, another way is to see that people spend most of their day productively, but how could you ever monitor that in a very creative field that often requires research and periods of contemplation? When you're contemplating and not writing any code, are you productive? Perhaps a lot more productive than someone who never stops banging out code. Perhaps not.

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 also why the judgement of traditional pointy-haired bosses is meaningless and completely without basis, even conventionally speaking (without getting into deep ultimate philosophy). And yet, at some point up the "command chain" a non-programmer will have to make a judgement of a programmer.

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 worth even 10 bucks. To others even a great tasting apple is not worth more than 5 cents. And then, a 10 dollar-per-apple person can have a mood swing the next day and conclude that they made a mistake and that the real worth is only 1 cent. In other words, values are not only inconstant from person to person, but they are even inconstant within a single person from time to time. And yet, people constantly try to evaluate everything, especially in business.

Regardless of whatever engineering techniques we come up with, we'll have an unpleasantly political job of basically massaging some manager's "feel good" antenna, which feels good on completely arbitrary basis. For example, you can spend 1 month on some brilliant server code and not get a word of acknowledgement. Then a Javascript person comes in and puts in some cute draggable columns in a table, and instantly they get a "WOW" response. The real hard work, the really impressive stuff -- it's all deep underground and totally invisible to management. In fact, the more important some job is, the more thankless and the less visible it is. The less important some job is, the more flashier it is, because the flashy and visible part is a tip of a pyramid that needs a wide and firm base of the pyramid in order to be stable. (A phrase "pyramid scheme" for some reason comes to mind)

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. At the end of the day, it will be like a marriage. If it works, it's not because of any objective values, but it's something else, maybe faith, maybe chemistry, whatever, but it's not quantifiable and it's not qualifiable.

Agile techniques can scratch the itch by they can't cure it. With agile methods, you have your milestones, which will likely be treated similar to deadlines by management. Or you may have some other metrics, which, if taken seriously, can produce very weird incentives that are counter-productive (for example, using KLOC to judge output can result in over-verbose code, and so on). Having more shorter milestones is a little better than a single all-or-nothing deadline, but it's merely managing the problem and not solving it.

Think of it this way. Our real boss is not a concrete human being, but a value system that keeps changing by its very nature. With a boss like that, can anyone be content? Who can hit the bull's eye that keeps shifting and re-defining itself?

By tweaking our engineering methods we are, maybe, making some marginal improvements, but at that level, we are still just dabblers.

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: Kung Fu styles Posted: Jul 14, 2006 1:47 AM
Reply to this message Reply
If the entire organization is not focused and self-aware, then there's no way of ensuring a good value for the work/money.

For instance, there's this news:
"Intel fires 1,000 managers"
http://www.vnunet.com/vnunet/news/2160361/intel-fires-managers

It probably means that Intel is trying to become efficient again. Though it would have been better if Intel had kept it efficient to begin with.

The same happens to software development, which needs some efficiency improvement, though some general restructuring of the industry is out of question. :-)

Grassroots. Bottom-up. Capisce? The only way to improve software development starts with the software developers. And in my book, whatever helps the software developers is a good resource.

"Perfect is the enemy of the good."

Perfect is not working, shall we try some of the good? It probably relates with the determinism issue.

Fireblaze .

Posts: 21
Nickname: fireblaze
Registered: Jul, 2006

Re: Deterministic Software Development Posted: Jul 14, 2006 4:02 AM
Reply to this message Reply
Look at the Migram experiement: http://en.wikipedia.org/wiki/Milgram_experiment

There you have you 100% of the participants behave the same:

"None of the participants who refused to administer the final shocks insisted that the experiment itself be terminated, nor left the room to check that the victim was well without asking for permission to leave, according to Milgram's notes and recollections when he was asked on this point by Zimbardo." 100%

"No participant steadfastly refused to give further shocks before the 300-volt level." 100%

You have to specify and write down your expected result before you start a software project, so they later can be verified (that is give a set of input parameter). I must have missed those known projects that does this.

Fireblaze .

Posts: 21
Nickname: fireblaze
Registered: Jul, 2006

Re: Kung Fu styles Posted: Jul 14, 2006 4:26 AM
Reply to this message Reply
>Grassroots. Bottom-up. Capisce? The only way to improve
>software development starts with the software developers.
>And in my book, whatever helps the software developers is
>a good resource.

I agree,
"The manager's function is not to make people work, but to make it possible for people to work" - Peopleware by TomDeMaroc & Timothy Listner.

Read the book, give your manager a copy of the book.

The book points out what is good and bad for a healty organization:
Things that help:
* Make a cult of quality
* Provide lots of satisfying closure
* Build a sense of eliteness
* Allow and encourage heterogeneity
* Preserve and protect successful teams
* Provide strategic but not tactical direction.

Things that hurt:
* defensive management
* bureaucracy
* physical separation
* fragmentation of people's time
* quality reductions of the product
* phony deadlines
* clique control

How many of you have worked on projects that didnt have things that was on the hurt list?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Deterministic Software Development Posted: Jul 14, 2006 9:30 AM
Reply to this message Reply
> Look at the Migram experiement:
> http://en.wikipedia.org/wiki/Milgram_experiment
>
> There you have you 100% of the participants behave the
> same:

Are you being purposely obtuse? I just posted information on the Milgram experiment and it that shows they did not behave the same. I'm not going to argue about what the definition of 'same' is. They did not all behave the same way i.e. their behavior was not determistic. Some people were willing to potenetially kill the other person, some were not. There's nothing you say that gets around that fact.

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-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us