The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Have a read...those who have not yet read.

K Send private email
Wednesday, August 23, 2006
 
 
Terrific article. Reader's Digest version:

Nearly flawless software powers the space shuttle. A team of professional, dedicated software engineers (who don't rely on Mountain Dew and endless pizza) work in a culture that demands perfection in their develpment efforts. They've created a development process that enforces the highest standards of work. Main points:

1. Commitment to excellence.
2. Management support of their culture.
3. Requirements gathered to the finest detail and agreed to by the customer. Changes are difficult to get inserted.
4. Robust testing process; even slightly maniacal.
5. Unheard-of commitment to change control.
6. General bemoaning of the current state of software development.

It's what our profession could look like if it ever grows up...and management grows up...and the customers could be kept in line.

But it's gotta start at the top of the organization.
Albi-wan
Wednesday, August 23, 2006
 
 
I especially like the second-to-last paragraph:

"And that's the point: the shuttle process is so extreme, the drive for perfection is so focused, that it reveals what's required to achieve relentless execution. The most important things the shuttle group does -- carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code -- are not expensive. The process isn't even rocket science. Its standard practice in almost every engineering discipline except software engineering."

Kinda says it all.
Albi-wan
Wednesday, August 23, 2006
 
 
It's a testament to the success of Big Up-Front Design.

Can you imagine the shuttle group using an Agile process to develop their software, with no up-front design except for a set of unit tests? It would be pandemonium.
BenjiSmith Send private email
Wednesday, August 23, 2006
 
 
Blah, blah, blah.

"It's standard practice in almost every engineering discipline except software engineering."

Tell that to the U.S. Army Corps of Engineers.

I'm so tired of everyone telling us how Engineering is something we should be modelling ourselves after.  There are good engineers and bad engineers just like in everything else.

Everyone is subject to the same limitations of budget and politics and some projects are successful and some aren't and some people do better planning than others.  But there isn't some magical methodology or title which gives that to you.
Cade Roux Send private email
Wednesday, August 23, 2006
 
 
And you too can achieve this - be sure to limit your team of 260 to less than 500,000 lines of code.

I've slung more than 2000 line of code before breakfast some days.

This article shows that the team that builds shuttle software is really good at ... building good shuttle software.  They do a great job, but it's almost a 30 year-old government program which has cost billions upon billions.

How exactly do we leverage this for anything but writing more shuttle software?
Cade Roux Send private email
Wednesday, August 23, 2006
 
 
I like item #4, "Don't just fix the mistakes -- fix whatever permitted the mistake in the first place." Its corollary is to blame the process, not the person.

But it's much more fun to blame the engineers.
dev1
Wednesday, August 23, 2006
 
 
Uh... this *is* where the phrase "mission critical" came from.  More than anything, their biggest contribution has been the Software Engineering Lab: http://sel.gsfc.nasa.gov/website/welcome.htm

Check it out and read up.  Pretty impressive stuff.
KC Send private email
Wednesday, August 23, 2006
 
 
The article is fun to read, but it draws the wrong conclusions. This is not a model that should be adopted by every software shop. Reason: it's just too expensive. No other software with 400k lines could afford a maintenance budget of 35M$ per year.

It might be a model for air traffic control software etc., but a bug tracking software or similar simply can afford a few bugs here and there.
Compilenix
Wednesday, August 23, 2006
 
 
Compilenix has it right.  Yes, you CAN get perfect software, BUT it's expensive.

SO, it's not a process you want to use for everything.  Nor is it a process you want to point to as being "best practices" -- because it's probably too damned expensive for most software applications.

So the Shuttle software stands as ONE datapoint of highly reliable software.  And that data point is WAY over on "does it HAVE to be this expensive?" side of the ledger.
AllanL5
Wednesday, August 23, 2006
 
 
Whats even worse is that this is the easiest software to write and maintain - compared to a typical desktop office app!
Fixed set or requirements, fixed hardware/os platform,
single well trained user, rigid procedure.

Typical windows/MFC desktop app 100K lines, 1 programmer 1 year. And this includes the help files, the users changing their minds everyday and trying to find out what windows is doing.
Martin Send private email
Wednesday, August 23, 2006
 
 
You can definitely apply this process to the development of consumer software and produce a Microsoft Word that has no bugs.

The question is how many customers are willing to pay $100,000 for a single license of Word.
Meghraj Reddy
Wednesday, August 23, 2006
 
 
This is true of defense contractors as well. I used to work in the change control board at General Dynamics many years ago and those guys were totally anal about changes. The engineers hated us. ;-)

But you have to consider the consequences of software bugs. For instance, if there's a bug in the CIWS fire control system the ship (and all the men on board) could be doomed. Better that every line of code is check and rechecked and the system is designed using BUFD.

These guys practice true software engineering. That is, engineering with the same controls and processes used by electrical and mechanical engineers. They sure as hell do not put two kids in a room and tell them to “go agile.”
MBJ Send private email
Wednesday, August 23, 2006
 
 
Given that it is a heavy process, I am certain they must have developed tools internally to support the process, ie, tracking changes.

The Question is: Are they as good as the space shuttle software?

Wednesday, August 23, 2006
 
 
> Yes, you CAN get perfect software, BUT it's expensive.

I wonder if that is true? I've been is similar shops, but the results weren't as good. Having a lot of process etc doesn't guarantee perfect software at any price.
son of parnas
Thursday, August 24, 2006
 
 
I seem to remember that NASA had a lot of processes for checking the hubble mirror. Or rather it had a lot of processes for checking the processes, it didn't have actually have any checks of the mirror.
Martin Send private email
Thursday, August 24, 2006
 
 
I hear lines like this all the time:
"Yet everyone complains how bad software is, with all the defects. If you bought a car with 5,000 defects, you'd be very upset."

Software is treated very differently to a car. There are hundreds (maybe thousands) of things I can do to break my car or make it crash. If I put it into first gear at 70mph or if I turn sharply at 70mph whilst hitting the brakes hard. These flaws in the car design are not treated as flaws, they are treated as driver training issues and common sense.
Adrian
Thursday, August 24, 2006
 
 
Are y'all talking about the same great engineering processes that Sony uses to produce exploding batteries or the USACE uses to:

"Serious vibrations were detected when the pumps were first run hard several days ago, corps specialist Jim St. Germain said.

On Tuesday and Wednesday, the corps performed new tests that indicate the vibrations apparently occur because the pump's rotor rubs against the pump housing. The vibration was eliminated when a test pump motor was rebuilt to eliminate the contact."

Or the Big Dig engineers used to prevent tunnel collapse?

All better processes come at a cost and a commitment - one that has to be passed on to the people who pay for the prokect and determine its scope.
Cade Roux Send private email
Thursday, August 24, 2006
 
 
On the other hand, you'd probably have good cause for complaint if your car crashed because you turned on the radio or adjusted your rear-view mirror.  "Oh, that'll be fixed in the next patch."
Kyralessa Send private email
Thursday, August 24, 2006
 
 
Umm, anybody remember our host's essay "Five Worlds" (/articles/FiveWorlds.html)?

Not that I don't love the way that we recycle arguments--most economical.
George Jansen Send private email
Thursday, August 24, 2006
 
 
Martin,

You are right. Most of the mission-critical applications use a non-multitasking and non-GUI approach. GUI is difficult to handle. I think for this type of software, they use a simple UNIX like OS with conole mode and many of its components may be years old. You don't have to trap each and every user activity but a series of tasks are performed in a sequential conditional manner.
K Send private email
Thursday, August 24, 2006
 
 
From the article: "Other than the occasional bit of shuttle memorabilia, you could be in the offices of any small company or government agency. Everyone has his or her own small office, and the offices have desks, PCs, and sparse personal artifacts."

Clearly, this author has not seen very many small companies or government agencies employing software developers.
Q7
Thursday, August 24, 2006
 
 
Boooooooooorrrrrriiiiinnnnnnggggggg............

The shop, not the article.  Ick.  Designing software that gets used by a handful of people on a platform that never changes.  Wow.  Big deal.  Designing a proper interface on a perpetually changing platform is 100 times harder then designing software for a space shuttle.

"...And no coder changes a single line of code without specs carefully outlining the change...."

Sounds like one of those places you hear about where you've got employees who do *nothing* the entire day but sign Form TPS193a.  Woe is the day that Mr. Form TPS193a Signer is on vacation because you can't get anything done.

"In the modern software environment, 80% of the cost of the software is spent after the software is written the first time"

Um, duh?  Unless I'm designing software for mission-critical stuff, I'd say this is fine.  And please, spare the arrogant attitude, you sir wouldn't last a minute in the "real world" if you tried to do 100% of the design up front. 

Three words:
Red. Tape. Nightmare.
Cory R. King
Thursday, August 24, 2006
 
 
The article is a nice overview of what it takes for them to build shuttle software but makes comparisons which aren't valid and takes leaps which are unwarranted.

Just another Monday-morning quarterback.

In my experience there is only one thing that matters in a good shop: Having a unified vision with a consensus about the goals, having a mutual understanding of what exactly (or inexactly and how much is unknown) it will take to achieve those goals, and having the commitment to the resources or whatever is required to go for it.

Everything else, the process, etc is a product of those things.  You might need a process or you might not.  You might need more or less planning.  You might need the planning just to give an accurate estimate to the stakeholders in the first place.  They may not want to pay for that estimate to be constructed.  But that's a choice they make with you.  No one can go into projects blind and expect not to be surprised.

I don't mind going into a project blind - as long as everyone knows how much is unknown.
Cade Roux Send private email
Thursday, August 24, 2006
 
 
First of all, the Shuttle is almost totally useless, a massively expensive publicity stunt that frequently kills its users. All that software quality didn't prevent catastrophic failure (where the heck was the rescue module?).

Second, those programmers are developing embedded software, with static, well-defined requirements. Developing software for machines is just very different from developing software for people.

People need to accept that "software engineering" isn't engineering. How many times have we developed something according to spec, by a deadline, and then nobody used it, because we accurately hit the wrong target. Is that quality?

I don't think so!
Steve Hirsch Send private email
Friday, August 25, 2006
 
 
So where can I take a look at the stuff?  I paid for it after all.
arch.stanton Send private email
Friday, August 25, 2006
 
 
Too bad they can't apply those techniques to their data reporting to management. Not that the NASA management culture would be able handle it if they could, of course.

http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001yB&topic_id=1
MT Heart
Saturday, August 26, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz