on the last two trips to Mars that failed. Communication and incompetence on Earth were the problem. Exactly how do scientists screw up and get the unit system wrong?
But that was a software problem, and it wasn't the scientists, it was the project management. A real scientist would almost certainly have noticed that some of the constants didn't make sense in the context they were being used.
In any case, space missions have some real interesting problems, like hardware that's so out of date it isn't funny because there isn't more recent hardware that's certified for the environment.
And like "standard" ADA flight control software that's reputedly full of bugs that have never been squashed.
The authors state as a given that crashes will happen.
I remember a few years ago (well, more than a few) I had this conversation with IBM MVS architects in an arguement about whether MVS should boot faster. Their position was that it shouldn't crash in the first place.
So what's widely acknowledged to be the least likely system to crash? IBM Mainframes.
Their proposal includes three different and only loosely related issues:
1. User in control
2. Encryption for privacy
3. External certificates for authentication.
To put it bluntly, the primary issue is authentication. The control and privacy issues
are, admittedly, dear to some people's hearts,
but if anyone thinks that encryption will keep
government agencies out of your e-mail, that
person has an unrealistic view of the world.
So that leaves us with authentication. All that
is needed here is an agreement among several
major ISPs (AOL, Earthlink, anyone?) to set up
secure links between their servers, and only
tag e-mail as authenticated if it provably comes
from one of their users.
That's been tried already. Its called mainframe computing. Client/Server computing, even with it's warts, is still cheaper and more prodcutive in userland.
I believe the City of Largo in Florida (may have the wrong city, tho...) went almost completely to a linux server / linux thin client and saved a boatload in terms of % of tax revenues spent on IT dollars.
Why? Among other things, they cut support cost in userland to the bone - nobody has to diagnose a bad client to get the user back up and running. Just plug in another workstation, and they're back doing whatever they're supposed be working on.
You don't have to have all your eggs in one basket to benefit from a thin client environment.
It's the smaller companies that are just getting by or even the individual users who are gonna scream bloody murder if you try and change something that is working 'well enough.' How many problems (sometimes major ones) do YOU put off EVERY DAY just because fixing 'em is slightly inconvinient and everything is 'good enough' for now?
The individual user isn't the problem. He's using Microsoft Windows, and probably has automatic software update turned on. Microsoft rolls out their update to OE, and most of the world now has authenticated access to any mail server that supports it. It's the guys in the middle, who are using a wild variety of usually out of date software, and aren't updating it regularly.
John Roth
Are there any online services that I can join which provide tons of (current) syndicated comics for a low fee?
www.comics.com
www.ucomics.com
www.kingfeatures.com
www.creators.com
There may be more, but these are the ones I use.
John Roth
Re:A (hopefully) unbiased opinion on Perl v. Pytho
on
Python in a Nutshell
·
· Score: 1
This comment will probably make it obvious, but I'm not a programmer (not by profession at least). Anyway, here's my question: Why would someone want to implement Python in itself?
That's a good question! There are two answers besides the technical flourish. One is that it demonstrates that the language is able to handle system level tasks (as opposed to, for example, RPG.)
The other is that being able to write the interpreter in Python vastly simplifies the task of evolving the language. You not only have a reasonably straightforward Python to C translator for the production interpretor, but you can also run the interpreter under itself for testing and debugging. See Squeak for another example where this has a real payoff.
John Roth
Re:A (hopefully) unbiased opinion on Perl v. Pytho
on
Python in a Nutshell
·
· Score: 2, Informative
But the problem is that Python suffers from a lot of Perl's problems and adds a few of its own: you can't implement it in itself, it has no strong typing (even Perl's use strict is ridiculously better), an OO system with no support for data hiding, etc. etc
Actually, one of these is being worked on: There's an active project to write Python in itself. I believe they're taking the same tack as Squeak.
Any number of things could have been done. Even with Columbia, knowing there was a disaster in the offing, I'd expect some creativity under pressure, if only sending up Soyuz to take them off.
And in future, I expect that NASA will have a contingency plan or two availible, with fuel and supplies to implement it.
I see Bill got to this issue first, so I'm just going to add a few words.
"Test First" in XP is about design, not about unit testing in the classical sense. You specify something that your program should do, write a test to verify that it does it, and then write the code to make it do it.
A lot of QA people criticize the resulting suite of test cases as being incomplete. The're absolutely right: they are incomplete from the formal testing viewpoint.
So where do issues like corner cases get handled? Where they belong - in the acceptance tests. The acceptance test suite (also called the functional test suite or the customer test suite) is the place where requirements conformance is tested, and should be the responsibility of QA.
This is utterly predictable. Long projects with a single deliverable at the end are notorious for not delivering on time.
Several things come to mind immediately from the Agile methodologies playbook:
1. The customer should not set technical requirements.
2. A working (but not feature complete) version of the product should be delivered no less frequently than every three months.
3. The customer should set business requirements with one voice. If that means that the various customers have to vote on what's most important, then so be it.
4. Features should be implemented in the order that it's most important to the customer.
And we haven't even gotten into the software engineering yet!
It's an interesting idea. Of course, I read the original article, not the redigested summary the poster referenced. Much better.
Reasoning from an engineering model seems to have the potential to do lots of interesting stuff. The limit the article didn't mention is the reasoning power of the robot; it seems like it could easily get overwhelmed by models that are just too big.
An interesting potential application: universal controls for complicated home entertainment systems built out of heterogenous parts.
Why do you have multiple, non-executable expressions of a program in the first place? A large part of refactoring is to make the program text itself more expressive, make it very apparent to the reader what the design is all about. If you can do that, what's the use of having separate commentary?
The right question is: why do government projects cost more, take longer and fail more frequently than private sector projects?
The reason is that they mandate long discredited project management techniques. A for profit company that took ten years and $100 million for a mission critical system, and then failed to deliver, would have been driven out of business by its competitors.
I could recommend XP (Extreme Programming, not the Microsoft OS, which has nothing to do with development,) but that's undoubtedly too extreme for government. However, just requiring the contractor to ship meaningful results every three months, instead of the complete system after three years, would probably work wonders.
John Roth Any opinions expressed in this post are genuine, certified opinions.
The article reads like all they have done is code a bog standard Genetic Algorithm for moving boxes. Have I read the article wrong or have they discovered nothing new??
You're right. It's simply an extension of the same artificial life and genetic algorithms that have been around for several years. It's useful research, but only because it's an interesting way of exploring a design space in the same way evolution does - massive trial and error, with conservation of those things that seem to work.
The title led me to believe that they were actually simulating the real genes, proteins and other signals that go to building a body. Now that would be a breakthrough of monumental proportions - even if all they did was start with a slime mold.
John Roth
couldn't they have been gentler?
However, if it lets me handle HTML easily, without having to learn all kinds of packages that do lots of things I don't need, then I'm all for it.
John Roth
Watch that speed limit sign on the learning curve!
The biggest problem that I have is that it's hard to nail down and detail the ROI in purely financial figures. Which is exactly what the beancounters want
Well, yes. If marketing wants a new campaign, they've got to justify it in increased sales (or at least, not decreased against historical trends.) If facilities wants a new system, they've got to measure some kind of return - faster response on work orders, etc. Someone in management has got to step up and say: I need X, and it's worth Y dollars (or Euros, or whatever.) It's their job to measure it.
Making it IT's job to justify the IT expense is a mistake; it's no more IT's job to do that than it is Facility's job to justify spending money on chairs and tables. Facilitys can justify which chairs and desks, and IT can justify which development methodologies it uses, but in the end, IT exists to provide business value, and business value has to be measured by the business, not by the IT people.
Ever heard of that? I know far too many IS projects that have costs, but there is no way to quantify the benefits. There is one very simple thing to understand here: costs come out of IT, benefits come out of the customer department. If you can't get the customer to step up to the plate and provide a believable justification, followed up by demonstrated results, you're sunk.
The next layer here is time frame. A project that starts paying for itself (i.e. is deployed) three months or less from inception gives everyone a benchmark to know whether the customer's estimate of benefits, as well as IS's ability to deliver those benefits. A project that won't be deployed for three years is, frankly, silly. It's an exercise in blind faith, not an exercise in rational development strategy.
If your development methodology delivers things infrequently in large lumps, you've got real problems. If it allows you to break large projects down into two or three month chunks that can be deployed to start getting a return on that investment, then you've got something.
The last layer is risk. Those massive three year projects have unacceptable business risks. If you break them into two or three month deployables, you've limited the risk your customer (internal or external) faces.
John Roth
I was kind of surprised to see this assertion. So I did a little due dilligence (I looked at the web sites of both parties). Nothing whatsoever in their press releases. I finally found it here http://www.equifax.com/DigitalCertificates/dc_pres s09252001.html
Equifax sold their SSL Certificate business, not anything else, close to a year ago... They're still the same credit reporting, marketing and so forth company they've always been.
Slashdot Mirror
But that was a software problem, and it wasn't the scientists, it was the project management. A real scientist would almost certainly have noticed that some of the constants didn't make sense in the context they were being used.
In any case, space missions have some real interesting problems, like hardware that's so out of date it isn't funny because there isn't more recent hardware that's certified for the environment.
And like "standard" ADA flight control software that's reputedly full of bugs that have never been squashed.
John Roth
The authors state as a given that crashes will happen.
I remember a few years ago (well, more than a few) I had this conversation with IBM MVS architects in an arguement about whether MVS should boot faster. Their position was that it shouldn't crash in the first place.
So what's widely acknowledged to be the least likely system to crash? IBM Mainframes.
John Roth
Their proposal includes three different and only loosely related issues:
1. User in control
2. Encryption for privacy
3. External certificates for authentication.
To put it bluntly, the primary issue is authentication. The control and privacy issues are, admittedly, dear to some people's hearts, but if anyone thinks that encryption will keep government agencies out of your e-mail, that person has an unrealistic view of the world.
So that leaves us with authentication. All that is needed here is an agreement among several major ISPs (AOL, Earthlink, anyone?) to set up secure links between their servers, and only tag e-mail as authenticated if it provably comes from one of their users.
The rest of it should be rather straightforward.
John Roth
That's been tried already. Its called mainframe computing. Client/Server computing, even with it's warts, is still cheaper and more prodcutive in userland.
I believe the City of Largo in Florida (may have the wrong city, tho...) went almost completely to a linux server / linux thin client and saved a boatload in terms of % of tax revenues spent on IT dollars.
Why? Among other things, they cut support cost in userland to the bone - nobody has to diagnose a bad client to get the user back up and running. Just plug in another workstation, and they're back doing whatever they're supposed be working on.
You don't have to have all your eggs in one basket to benefit from a thin client environment.
John Roth
It's the smaller companies that are just getting by or even the individual users who are gonna scream bloody murder if you try and change something that is working 'well enough.' How many problems (sometimes major ones) do YOU put off EVERY DAY just because fixing 'em is slightly inconvinient and everything is 'good enough' for now?
The individual user isn't the problem. He's using Microsoft Windows, and probably has automatic software update turned on. Microsoft rolls out their update to OE, and most of the world now has authenticated access to any mail server that supports it. It's the guys in the middle, who are using a wild variety of usually out of date software, and aren't updating it regularly. John Roth
Are there any online services that I can join which provide tons of (current) syndicated comics for a low fee?
www.comics.com
www.ucomics.com
www.kingfeatures.com
www.creators.com
There may be more, but these are the ones I use.
John Roth
This comment will probably make it obvious, but I'm not a programmer (not by profession at least). Anyway, here's my question: Why would someone want to implement Python in itself?
That's a good question! There are two answers besides the technical flourish. One is that it demonstrates that the language is able to handle system level tasks (as opposed to, for example, RPG.)
The other is that being able to write the interpreter in Python vastly simplifies the task of evolving the language. You not only have a reasonably straightforward Python to C translator for the production interpretor, but you can also run the interpreter under itself for testing and debugging. See Squeak for another example where this has a real payoff.
John Roth
But the problem is that Python suffers from a lot of Perl's problems and adds a few of its own: you can't implement it in itself, it has no strong typing (even Perl's use strict is ridiculously better), an OO system with no support for data hiding, etc. etc
Actually, one of these is being worked on: There's an active project to write Python in itself. I believe they're taking the same tack as Squeak.
John Roth
Any number of things could have been done. Even with Columbia, knowing there was a disaster in the offing, I'd expect some creativity under pressure, if only sending up Soyuz to take them off.
And in future, I expect that NASA will have a contingency plan or two availible, with fuel and supplies to implement it.
John Roth
I see Bill got to this issue first, so I'm just going to add a few words.
"Test First" in XP is about design, not about unit testing in the classical sense. You specify something that your program should do, write a test to verify that it does it, and then write the code to make it do it.
A lot of QA people criticize the resulting suite of test cases as being incomplete. The're absolutely right: they are incomplete from the formal testing viewpoint.
So where do issues like corner cases get handled? Where they belong - in the acceptance tests. The acceptance test suite (also called the functional test suite or the customer test suite) is the place where requirements conformance is tested, and should be the responsibility of QA.
John Roth
This is utterly predictable. Long projects with a
single deliverable at the end are notorious for
not delivering on time.
Several things come to mind immediately from the Agile methodologies
playbook:
1. The customer should not set technical requirements.
2. A working (but not feature complete) version
of the product should be delivered no less
frequently than every three months.
3. The customer should set business requirements
with one voice. If that means that the various
customers have to vote on what's most important,
then so be it.
4. Features should be implemented in the order
that it's most important to the customer.
And we haven't even gotten into the software
engineering yet!
John Roth
It's an interesting idea. Of course, I read the original article, not the redigested summary the poster referenced. Much better.
Reasoning from an engineering model seems to have the potential to do lots of interesting stuff. The limit the article didn't mention is the reasoning power of the robot; it seems like it could easily get overwhelmed by models that are just too big.
An interesting potential application: universal controls for complicated home entertainment systems built out of heterogenous parts.
John Roth
Why do you have multiple, non-executable expressions of a program in the first place? A large part of refactoring is to make the program text itself more expressive, make it very apparent to the reader what the design is all about. If you can do that, what's the use of having separate commentary?
John Roth
the size of the event horizon. What's inside is unknown (and presumably unknowable)
John Roth
The right question is: why do government projects cost more, take longer and fail more frequently than private sector projects?
The reason is that they mandate long discredited project management techniques. A for profit company that took ten years and $100 million for a mission critical system, and then failed to deliver, would have been driven out of business by its competitors.
I could recommend XP (Extreme Programming, not the Microsoft OS, which has nothing to do with development,) but that's undoubtedly too extreme for government. However, just requiring the contractor to ship meaningful results every three months, instead of the complete system after three years, would probably work wonders.
John Roth
Any opinions expressed in this post are genuine, certified opinions.
The article reads like all they have done is code a bog standard Genetic Algorithm for moving boxes. Have I read the article wrong or have they discovered nothing new?? You're right. It's simply an extension of the same artificial life and genetic algorithms that have been around for several years. It's useful research, but only because it's an interesting way of exploring a design space in the same way evolution does - massive trial and error, with conservation of those things that seem to work. The title led me to believe that they were actually simulating the real genes, proteins and other signals that go to building a body. Now that would be a breakthrough of monumental proportions - even if all they did was start with a slime mold. John Roth
couldn't they have been gentler? However, if it lets me handle HTML easily, without having to learn all kinds of packages that do lots of things I don't need, then I'm all for it. John Roth Watch that speed limit sign on the learning curve!
The biggest problem that I have is that it's hard to nail down and detail the ROI in purely financial figures. Which is exactly what the beancounters want
Well, yes. If marketing wants a new campaign, they've got to justify it in increased sales (or at least, not decreased against historical trends.) If facilities wants a new system, they've got to measure some kind of return - faster response on work orders, etc. Someone in management has got to step up and say: I need X, and it's worth Y dollars (or Euros, or whatever.) It's their job to measure it.
Making it IT's job to justify the IT expense is a mistake; it's no more IT's job to do that than it is Facility's job to justify spending money on chairs and tables. Facilitys can justify which chairs and desks, and IT can justify which development methodologies it uses, but in the end, IT exists to provide business value, and business value has to be measured by the business, not by the IT people.
John Roth
Ever heard of that? I know far too many IS projects that have costs, but there is no way to quantify the benefits. There is one very simple thing to understand here: costs come out of IT, benefits come out of the customer department. If you can't get the customer to step up to the plate and provide a believable justification, followed up by demonstrated results, you're sunk. The next layer here is time frame. A project that starts paying for itself (i.e. is deployed) three months or less from inception gives everyone a benchmark to know whether the customer's estimate of benefits, as well as IS's ability to deliver those benefits. A project that won't be deployed for three years is, frankly, silly. It's an exercise in blind faith, not an exercise in rational development strategy. If your development methodology delivers things infrequently in large lumps, you've got real problems. If it allows you to break large projects down into two or three month chunks that can be deployed to start getting a return on that investment, then you've got something. The last layer is risk. Those massive three year projects have unacceptable business risks. If you break them into two or three month deployables, you've limited the risk your customer (internal or external) faces. John Roth
I was kind of surprised to see this assertion. So I did a little due dilligence (I looked at the web sites of both parties). Nothing whatsoever in their press releases. I finally found it here http://www.equifax.com/DigitalCertificates/dc_pres s09252001.html
Equifax sold their SSL Certificate business, not anything else, close to a year ago... They're still the same credit reporting, marketing and so forth company they've always been.