Berkeley CSUA MOTD:Entry 19564
Berkeley CSUA MOTD
 
WIKI | FAQ | Tech FAQ
http://csua.com/feed/
2025/07/10 [General] UID:1000 Activity:popular
7/10    

2000/10/25-26 [Computer/SW/Apps, Computer/SW/Languages/Functional] UID:19564 Activity:high
10/25   Here is an interesting article about s/w. It goes against
        the typical silicon valley s/w mentality, and even some of
        the anti-female sentiment often shown on this motd:
        http://www.fastcompany.com/online/06/writestuff.html
        \_ "Yet everyone complains how bad software is, with all the
           defects." Everyone? I personally think that software quality
           has increased in the past 20 years. Look at the accomplishment
           we've made with OS, application, database, network, etc.
           \_ Okay: M$ Win*, M$ Excel/Word/PowerPoint, M$ Access/FoxPro,
              M$ TCP/IP & IE, etc.
              Things have become much worse.
        \_ "something wrong with the way its being written"
           If only writers had some process of their own.
        \_ You don't want to know how much this software probably costs.
           When there's no profit on the line then things are typically
           done well/right. Most software companies aren't about good
           software but about (duh) making a profit. --dim
           \_ And most software companies also have competitors, both for
              customers and for funding.
        \_ Yes, we're all familiar with slashdot, thanks.
        \_ I worked at NASA and yes there are people that write good
           code there but there is little innovation. The reason that
           it is reliable is because each change or improvement or
           idea has to get approved by ~ 50 people (and most ideas don't
           make it through the process). The atmosphere does appeal to
           a lot of mothers (mine included, AI research @ Ames 13 yrs)
           though. They like the slow non-aggressive work enviroment.
           Also efficiency isn't a top priority, many programs make
           the worst possible use of resources in order to ensure max.
           reliability. And this doesn't change even when you point out
           that the same thing can be done faster with equal reliability,
           because it would be "dangerous" to change it (the reality is
           that it would mean that some people would have to do work,
           which is avoided at all costs).
           \_ 1) resources aren't important.  In a situation like this
                 correctness is everything.  Resources are pretty damn
                 cheap.
                 \_ You are wrong. Resources on the shuttle are exteremely
                    expensive. You can't just launch the latest 2GHz PV
                    Q3A/UT FRK proc into orbit. The computer systems on
                    the shuttle are quite slow and every cycle on them
                    is precious. If you can do something faster then it
                    worth doing, esp. if it is provable safe. Improvements
                    in operational efficiency translate to longer cheaper
                    missions. Ultimately someone has to pay for this and
                    that is the US tax payer, if this thing gets too damn
                    expensive it will stop flying, regardless of all that
                    science is great and wonderful and should be done
                    regarless of the cost bs that you see on Star Trek.
              2) if it works and is BugFree(tm) them changing it IS
                 dangerous.  It means you have to go make sure there are
                 no problems with the code and change it in the painstaking
                 process you described before (which yes may be painful
                 for someone used to coding in a more freeform style, but
                 let's face it, it does work for what they want).
                 \_ The problem is not that it is dangerous to change
                    and test it, the problem is that beuracrats don't
                    like change because that means they have to do work
                    and they hate doing work. Nasa is run by inertia,
                    a body at rest remains at rest unless otherwise
                    compelled by an external force. And that external
                    force needs to be pretty damn strong. The reason
                    that there are so many women there is that they
                    like the fact that most of the time there is nothing
                    to do and when asked to do something they can just
                    say that it would take too long.
                    \_ It's all about risk versus gain. Change for the
                       sake of change is not wise in such an environment.
                       Further, even the smallest change can be *very*
                       expensive considering all the testing and validation
                       that must be redone. When there's sometimes code
                       that's been around for 30 years and consists of
                       millions of lines you can see why people are loathe
        \_ It's a four-year old article.
                       to change it unless there are requirements to do
                       so. It's not sloth. --dim
                       \_ @ Ames its sloth. I routinely got, yeah we could
                          change it or we could fix it, but I don't feel
                          like it, I just want to surf the web and go home.
                          We could maybe do it next month.
                          \_ change it != fix it != optimize it
                             \_ In the context of the code I was dealing
                                with change|fix == optimize, basically
                                most of the stuff ran slow and no one
                                wanted to even clean it up, because that
                                would get in the way of putting in a solid
                                7 hrs (they always take min 1 hr lunch) of
                                playing solitare or bz or web surfing.
           The people described in this article probably also write in
           ADA.
           \_ until recently (not sure how the advent of RTOS's affect this)
              all FAA certified software for ATC was exclusively hand coded
              and verfied assembly code.
              \_ At Nasa, the shuttle guys were ADA, the aeronautics guys
                 were FORTRAN and the AI guys were Lisp.
                 \_its amazing the thing ever got off the ground.
                   \_ well it was only 10 yrs late and over budget.
        \_ It's a four-year-old article.
Cache (8192 bytes)
www.fastcompany.com/online/06/writestuff.html
Transit Authority : business travel tips sign up * Premier Online Sponsors * Featured Services * 30 Find Online Degrees * 31 Business Directory * 32 Research Companies * 33 Find Biz Software As the 120-ton space shuttle sits surrounded by almost 4 million pounds of rocket fuel, exhaling noxious fumes, visibly impatient to defy gravity, its on-board computers take command. Four identical machines, running identical software, pull information from thousands of sensors, make hundreds of milli-second decisions, vote on every decision, check with each other 250 times a second. A fifth computer, with different software, stands by to take control should the other four malfunction. As the main engines come to one million pounds of thrust, their exhausts tighten into blue diamonds of flame. Then and only then at T-minus zero seconds, if the computers are satisfied that the engines are running true, they give the order to light the solid rocket boosters. But no human pushes a button to make it happen, no astronaut jockeys a joy stick to settle the shuttle into orbit. The software gives the orders to gimbal the main engines, executing the dramatic belly roll the shuttle does soon after it clears the tower. The software throttles the engines to make sure the craft doesn't accelerate too fast. It keeps track of where the shuttle is, orders the solid rocket boosters to fall away, makes minor course corrections, and after about 10 minutes, directs the shuttle into orbit more than 100 miles up. When the software is satisfied with the shuttle's position in space, it orders the main engines to shut down -- weightlessness begins and everything starts to float. But how much work the software does is not what makes it remarkable. What makes it remarkable is how well the software works. It is perfect, as perfect as human beings have achieved. Consider these stats : the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors. This software is the work of 260 women and men based in an anonymous office building across the street from the Johnson Space Center in Clear Lake, Texas, southeast of Houston. They work for the "on-board shuttle group," a branch of Lockheed Martin Corps space mission systems division, and their prowess is world renowned: the shuttle software group is one of just four outfits in the world to win the coveted Level 5 ranking of the federal governments Software Engineering Institute (SEI) a measure of the sophistication and reliability of the way they do their work. In fact, the SEI based it standards in part from watching the on-board shuttle group do its work. The group writes software this good because that's how good it has to be. Every time it fires up the shuttle, their software is controlling a $4 billion piece of equipment, the lives of a half-dozen astronauts, and the dreams of the nation. Even the smallest error in space can have enormous consequences: the orbiting space shuttle travels at 17,500 miles per hour; Before every flight, Ted Keller, the senior technical manager of the on-board shuttle group, flies to Florida where he signs a document certifying that the software will not endanger the shuttle. If Keller can't go, a formal line of succession dictates who can sign in his place. Bill Pate, who's worked on the space flight software over the last 22 years, says the group understands the stakes: "If the software isn't perfect, some of the people we go to meetings with might die. Virtually everything -- from the international monetary system and major power plants to blenders and microwave ovens -- runs on software. In office buildings, the elevators, the lights, the water, the air conditioning are all controlled by software. In cars, the transmission, the ignition timing, the air bag, even the door locks are controlled by software. Almost every written communication that's more complicated than a postcard depends on software; According to SEI's studies, nearly 70% of software organizations are stuck in the first two levels of SEI's scale of sophistication: chaos, and slightly better than chaos. Ten years ago the shuttle group was considered world-class. To be this good, the on-board shuttle group has to be very different -- the antithesis of the up-all-night, pizza-and-roller-hockey software coders who have captured the public imagination. To be this good, the on-board shuttle group has to be very ordinary -- indistinguishable from any focused, disciplined, and methodically managed creative enterprise. In fact, the group offers a set of textbook lessons that applies equally to programmers, in particular, and producers, in general. A look at the culture they have built and the process they have perfected shows what software-writing must become if software is to realize its promise, and illustrates what almost any team-based operation can do to boost its performance to achieve near-perfect results. It's Douglas Coupland's "Microserf's," a true-to-life fictional account of life in the software-fast-lane. And it's the dominant image of the software development world: Gen-Xers sporting T-shirts and distracted looks, squeezing too much heroic code writing into too little time; Its the world made famous, romantic, even inevitable by stories out of Sun Microsystems, Microsoft, and Netscape. 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. People wear moderately dressy clothes to work, neat but nothing flashy, certainly nothing grungy. It's strictly an 8-to-5 kind of place -- there are late nights, but they're the exception. Many of them have put in years of work either for IBM (which owned the shuttle group until 1994), or directly on the shuttle software. They're adults, with spouses and kids and lives beyond their remarkable software program. That's the culture: the on-board shuttle group produces grown-up software, and the way they do it is by being grown-ups. It may not be sexy, it may not be a coding ego-trip -- but it is the future of software. When you're ready to take the next step -- when you have to write perfect software instead of software that's just good enough -- then it's time to grow up. Ted Keller, 48, the group's senior technical manager, looks and sounds like the headmaster of a small private high school. It's Keller's job to make sure the software gets delivered on time, with all its capabilities, without regard to turf battles. He's a compact, bald man, a little officious and persnickety, qualities any astronaut would find reassuring. He has a gentle, geeky sense of humor, not so much with outsiders, but with his crowd. It comes out in a meeting between members of the software group and their NASA counterparts. It's held in a small conference room overstuffed with 22 people and an overhead projector. Several times, from the back of the room, Keller issues a wry remark about the speed of code delivery, or the detail of some specifications, and the room lightens with laughter. Otherwise, the hour-long meeting is sober and revealing, a brief window on the culture. For one thing, 12 of the 22 people in the room are women, many of them senior managers or senior technical staff. The on-board shuttle group, with its stability and professionalism, seems particularly appealing to women programmers. For another, it's an exercise in order, detail, and methodical reiteration. The meeting is a classic NASA performance -- a rehearsal for an almost identical meeting several weeks away. It consists of walking through an enormous packet of data and view -- graphs which describe the progress and status of the software line by line. Except for Keller's occasional asides, the tone is businesslike, almost formal, the view - graphs flashing past as quickly as they can be read, a blur of acronyms, graphs, and charts. What's going on here is the kind of nuts-and-bolts work that defines the dri...