Darren New <dne### [at] sanrrcom> wrote:
> http://www.gamearchitect.net/Articles/SoftwareIsHard.html?dupe

  It actually *is* possible to have software development which produces
(almost) bug-free programs on schedule and within budget. However, getting
to that point is extremely hard and probably prohibitively expensive.

  I loved that one article (which has also been referenced here in the past)
on how software is produced by NASA. The development system is absolutely
draconian and bureaucratic, where not a single feature or even line of code
is added, removed or modified without the change being carefully documented
and passed through an admission process. The rules are mind-numbingly strict
and bureaucratic.

  However, it works. Where projects of similar size in other, more regular
software companies, have something like 5000 bugs found in beta-testing
stage, NASA software projects have something like 5. And not just critical
bugs. *Any* bugs.

  And they *learn* from the bugs. Every time a bug is found in beta-testing,
they carefully study and document the *reason* why the bug got through to
beta-testing in the first place, through all the safeguards and development
methods, and once the reason is understood, these safeguards and methods are
improved so that similar bugs will never pass again undetected.

  (This idea of actually learning from bugs and documenting them in order
to avoid them in the future is actually a superb idea. However, how many
companies do that? I'd say the amount is really, really small. Most developers
just fix the bug and *forget* about it. Then they are doomed to repeat the
same process again in the future in similar situations.)

  And as said, they not only produce virtually bug-free programs, they do
so in schedule and within budget. How many other companies can say that?

  I liked how the article talked about the one guy who was a developer at
NASA, who wanted to go to the software industry where he could develop
software with more freedom, without all the bureaucracy. He got shocked
at how bad software development was elsewhere, and returned to NASA after
a few years.

  Of course getting to this kind of development must be rather hard and
expensive (at least at first). It also requires a kind of mentality and
expertise that most project leaders just don't have.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Of course getting to this kind of development must be rather hard and
> expensive (at least at first). It also requires a kind of mentality and
> expertise that most project leaders just don't have.

I think it's probably similar for a lot of safety-critical code.

The thing about NASA is they have safety-critical code, extremely bad press 
when it fails, and a software budget dwarfed by everything else they do. 
When the concern doesn't include how much it costs or how long it takes, 
it's a whole bunch easier to make perfect code.

Having the same development platform for 35 years can also help, as does 
having every bit of specs about how absolutely everything works. And in all 
honesty, the programs aren't all that big. How many bugs have you written 
because you're using some infrastructure code that isn't documented 
correctly and completely?

Which is not to say they're not awesome. I'm just saying they're solving a 
different problem than 3DRealms was trying to solve. :-)

http://www.atarimagazines.com/compute/issue132/92_Space_shuttle_techno.php

http://www.popsci.com/node/31716


-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> http://www.popsci.com/node/31716

  Btw, it really amuses me when the Moon landing conspiracy theorists make
the point that the lunar lander computers had less computing capacity than
a modern cellphone, like that was some kind of proof that the landings were
impossible.

  These people have clearly not seen any 4k intros (it's really amazing how
much functionality you can squeeze into 4 kilobytes of code), or tried to
find out how much hardware a cellphone really has.

  (Personally I see it the other way around: I'm amazed at how much
computing power there is in a device which you can hold in your hand.
Technology has really taken huge leaps.)

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:
> David H. Burns wrote:
>> "I'm not smarter than a fifth grader." ;)
> 
> http://www.gamearchitect.net/Articles/SoftwareIsHard.html?dupe
> 
OK. I admit it programming is hard -- a lot harder than I imagined. It's 
much
harder than it used to be, but why? Well there's multitasking, increase 
in hardware complexity,
the internet (one has to deal with the possibility that umpteen 
advertisers are
going to send unwanted pop-ups to you machine), Microsoft updates every 15
or 20 minutes, viruses (exploiting deliberate loopholes in the Windows 
operating system),
to name a few reasons. Does this make difficult programming inevitable. 
I suppose it does;
at least it is so and little can be done about it. But I'm not 
altogether convinced that this should
make it so difficult for me programming on my own computer largely for 
my own use and not
really caring whether I'm connected to the internet all the time.

It doesn't explain why I have had so much difficulty finding 
understandable paradigms and
prototypes for WINAPI applications -- though that might be due to the 
fact that I don't have
ready access to a large library (or store) where I can thumb through the 
programming books.

All this is very educational. :)

David

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> http://www.popsci.com/node/31716
> 
>   Btw, it really amuses me when the Moon landing conspiracy theorists make
> the point that the lunar lander computers had less computing capacity than
> a modern cellphone, like that was some kind of proof that the landings were
> impossible.

That reminds me:

Someone built a working replica of the guidance computer. Pretty neat!

http://agcreplica.outel.org/

Yeah, I remember the days of intros and such. Always cool to see how 
much they could cram into such a small executable.
-- 
~Mike

Post a reply to this message

David H. Burns wrote:
> OK. I admit it programming is hard -- a lot harder than I imagined. It's 
> much
> harder than it used to be, but why?

1) Your programs are bigger. (For example, my Linux boot partition won't 
even fit in the address space that CP/M used to allow for a disk drive.)

2) Your programs are way more complex. You're not writing to the screen and 
reading from the keyboard any more. Note that stdio programs are just as 
easy as they used to be.

3) Your programs depend on a lot more than they used to. You have all kinds 
of libraries to do all kinds of things you wouldn't have dreamed of when you 
were using an 8-bit computer. You can't port OpenGL to a Z80.

4) Most importantly: Each line of code interacts with other lines of code. 
Building 20 houses is 20 times as hard (or less) than building one house. 
Building a program 20,000 lines long is much harder than 20x the effort for 
a 1,000 line program.

> Does this make difficult programming inevitable. 

Only if you want to take advantage of it. Find an old copy of MS-DOS, boot 
it, and suddenly programming will be easy again.

> I suppose it does;
> at least it is so and little can be done about it. But I'm not 
> altogether convinced that this should
> make it so difficult for me programming on my own computer largely for 
> my own use and not
> really caring whether I'm connected to the internet all the time.

Whether you're connected to the internet is irrelevant for your own 
programs, unless you're using the internet.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> Someone built a working replica of the guidance computer. Pretty neat!
>
> http://agcreplica.outel.org/

Pfft! That's not a faithful replica: For instance, he didn't use core rope for
ROM, like the original did...

(not that I could blame that guy in any way - that type of ROM required manual
programming - *literally* >_<)

Post a reply to this message

clipka wrote:

> Pfft! That's not a faithful replica: For instance, he didn't use core rope for
> ROM, like the original did...

Yeah, he also admits to using RAM chips over core.. As well. I'm 
guessing it was quicker to use a chip that build a memory core from 
scratch ;)

> 
> (not that I could blame that guy in any way - that type of ROM required manual
> programming - *literally* >_<)
> 
> 

Heh. Bit, by bit... fun stuff.

-- 
~Mike

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Note that stdio programs are just as 
> easy as they used to be.

  Well, that depends. If your CLI program wants to eg. take advantage of
multiple processors, it will usually be a bit more complicated. (Although
some programming languages make this a bit easier.)

  A couple of decades ago multiprocessor computers were huge servers which
price started from $100k up, so for regular people it was just a dream.

  (Ok, you *could* write multithreaded CLI programs two decades ago, but
it wasn't as beneficial back then as it is nowadays.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Note that stdio programs are just as 
>> easy as they used to be.
> 
>   Well, that depends. If your CLI program wants to eg. take advantage of
> multiple processors, it will usually be a bit more complicated. (Although
> some programming languages make this a bit easier.)

True. Let's rephrase as "if you want your programs to do the same things 
they did under MS-DOS, they're just as hard to write now and no harder."

My point is that programming has gotten easier over time (such as with the 
invention of OOD, sophisticated IDEs and debuggers, etc) but the ambitions 
have grown greater.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message