| Data Store Entry |
Created | Actions |
|
PLT Scheme:
I'm putting this in the Software Quality store because one of the arguments for using Scheme is that it's not C. Anyway they have a really nice little IDE and support for web servlets, etc. Fun. - rob
rob(5/4/03 2:38 PM CST): Here is a very good presentation by Shriram Khrishnamurthi talking about DrScheme. Unfortunately it's audio-only, so you will probably want to follow along with his slides.
|
5/4/2003 4:32 PM
rob
(Modified 5/4/2003 4:38 PM)
|
Detail View
New Window
Move/Edit
|
|
Edward Tufte: Ask E.T. forum:
Like the dreaded Sherlock 2, the OS X interface design is distracting and
self-conscious, with a marketing slickness rather the straight-forward
transparent charming style of the past. It is out of tune with the superb
industrial design of Apple hardware.
Mac users will probably get used to it.
|
4/29/2003 2:20 PM
nick
|
Detail View
New Window
Move/Edit
Full Text
|
|
Rule of secure coding: 'See input as evil'- ADTmag.com:
''The number one thing for developers to realize is that you need to treat input
as evil,'' he said.
|
4/15/2003 4:55 PM
nick
|
Detail View
New Window
Move/Edit
Full Text
|
|
Too Much Free Software:
Too Much Free Software
by Marius Andreiana, in Editorials - Saturday, March 29th 2003
00:00 PST
The plethora of Free Software applications available today, none working
perfectly, is a problem which stands in the way of major adoption of Linux on
the desktop. In order to conquer the desktop, we have to stand united.
Interesting article and commentary following. - rob
|
4/4/2003 10:29 AM
rob
|
Detail View
New Window
Move/Edit
|
|
FW: If you didn't read this already:
-----Original Message-----
From: Nick Tornow[mailto:ntornow@sheergeniussoftware.com]
Sent: Thursday, March 27, 2003 11:43 AM
To:internal@sheergeniussoftware.com
Subject: Re: If you didn't read this already I'm in a nit-picking mood lately with people over-simplifying the software process, so while I think I agree with both Andy and Dave I found this interview to be a bit muddled and am going to make some comments for your optional perusal: Page 1: While their point here is good, that configuration information can be seperated from the logic, I think they are dodging some issues. For instance, each field that you make configurable requires several considerations, none of which are discussed: 1) each configuration field multiplies the possible configurations of the system by the set of possible values for thatfield. This is an occassionally overlooked problem at development time that can make testing and error tracking more difficult 2) one must consider validation of configuration fields 3) one should consider security of configuration fields 4) one should consider whether the configuration field must be documented 5) changes to configuration fields have implications for software upgrades
Page 2: "You have to accept the fact that you're not going to get it right the first time. And you're not going to get it perfectly right the second or third time. You'll never get it perfectly right, but along the way you can get better and better . To do that, you have to discipline yourself to apply a reflective process to what you do. " - I pretty much agree with this discussion
Page 3: Again they dodge many issues with the point of the value of creating a "mini-language". The points are generally good but should be tempered by counter examples: 1) "When there's one change in the real world, you want to be able to make only one change in the code. By setting up an environment that includes a dedicated domain language, you come much closer to that goal" - modern programming languages provide many abstractions to allow higher level work, such as objects and methods. Though I think the first point is generally valid, the second is inaccurate. 2) a mini-language must be coded, tested, and maintained 3) new developers must learn the mini language, but they sometimes won't at first and therefore there may be many mistakes made 4) the mini-language will not have the full expressive power of the real language and will therefore sometimes need extension 5) once the extensions to the mini-language become substantial, there is little argument for using the mini-language at all I am not attempting to refute the idea of a"mini-language" just saying the interview glosses over the core issues. Unfortuantely, this seems like an all-to-common trait of many software articles I have read lately. The interview format in which the interviewer does not act as an antagonizer only makes it worse, imho. -Nick ----- Original Message ----- From: Tully Edson To: internal@sheergeniussoftware.com Sent: Thursday, March 27, 2003 9:30 AM Subject: If you didn't readthis already Put Abstractions in Code, Details in Metadata http://www.artima.com/intv/metadata.html --Tully
|
3/27/2003 1:15 PM
lvaughn
(Modified 3/27/2003 1:30 PM)
|
Detail View
New Window
Move/Edit
|
|
Too cool for secure code:
Until Unix and Linux programmers get over their macho love for low-level programming languages, the security holes will continue to flow freely, argues SecurityFocus columnist Jon Lasser.
nick(3/27/03 11:16 AM CST): I take a couple issues with this article:
"In an age where processing power is cheap, there's no excuse for a mail client written in C or C++" - while this is generally a good point, certain algorithms in a mail client must be lightning fast for it to win the usability battle. I think the argument is much stronger for server software where security and stability are at a premium.
"I think it's safe to say that programmers spent less time at self-criticism than pilots" - this is a broad statement and is an interesting assertion, but is sort of silly. A more reasonable statement might be something like: if programmers/users of software were as concerned about the stability of their code and as intolerant of errors there as pilots/passengers are with the structural integrity and safety records of their planes, then we might not see so many problems. When you phrase it this way though, it's clear that many of the reasons software is the way that it is have to do with social/economic issues of the market than the programmers themselves.
|
3/26/2003 2:56 PM
rob
(Modified 3/27/2003 12:16 PM)
|
Detail View
New Window
Move/Edit
|
|
The Software Construction Analogy is Broken:
It often seems that the effort to re-use software components is just as
difficult as building needed functionality from scratch. Most components are
generalized so that they can be used in a wide variety of situations - with the
result that any given piece of software made from pre-fab components has a whole
bunch of unused functionality left over - pipes that lead nowhere, half-walls
and stairways to dead ends. That extra functionality often makes it difficult to
learn about and use a component and adds substantially to the integration work.
It also means that the cost of developing the component's functionality has to
be recovered somehow. Creating the needed functionality from scratch is often
more efficient. All the extra functionality of a generalized component is left
out making it easier to learn and use, and it is perfectly integrated with the
other parts of the system immediately. Those who promote the construction
analogy in the form of component based development overlook the simplicity and
intuitiveness of "components" in construction. Any analogy or methodology which
deals with software components must explicitly recognize and address the
incredible complexity inherent in the concept of software components.
|
3/24/2003 12:46 PM
nick
|
Detail View
New Window
Move/Edit
|
Software in a box:
One might ask why a company would choose a hardware model in such a scenario
when 1U servers are available from many reputable vendors. The generally
accepted practice of delivering software designed for open platforms to be
installed by the customer may be up for review. When you examine the details of
what it takes to sell, provision, manage and rely on a piece of software, the
customer increasingly prefers closed-end hardware to open-platform software. On
top of this, for a start-up, this "software in a box" path is actually more
cost-effective and easier to execute.
|
2/12/2003 11:52 PM
nick
|
Detail View
New Window
Move/Edit
|
Wired 11.02: Immortal Code:
"There
was an old idea," says Bob Frankston, a hardcore programmer from legendary
VisiCalc, "that you should have huge catalogs of code lying around. That was in
the '70s; reusable code was the big thing. But reusing pieces of code is like
picking off sentences from other people's stories and trying to make a magazine
article." It might make your point, but not very well.
|
1/28/2003 4:52 PM
nick
|
Detail View
New Window
Move/Edit
|
From Jim::
As you probably know, I belong to an obscure religious cult whose
chief tenet is that *every* application needs a "console", and almost
every application needs a console that supplies a granular delegated
administration permissions scheme. Since the glory days of Candle
Corporation in the early 1980s, enterprise systems management product
value-added seems to have migrated away from "performance" and
towards "administration" (e.g., Mission Critical Software, Inc. and
now ConfigureSoft).
|
12/16/2002 1:45 PM
nick
|
Detail View
New Window
Move/Edit
|
Joel on Software - The Law of Leaky Abstractions:
This is what I call a leaky abstraction. TCP attempts to provide a
complete abstraction of an underlying unreliable network, but sometimes, the
network leaks through the abstraction and you feel the things that the
abstraction can't quite protect you from. This is but one example of what I've
dubbed the Law of Leaky Abstractions:
All non-trivial abstractions, to some degree, are
leaky.
Abstractions fail. Sometimes a little, sometimes a lot. There's leakage.
Things go wrong. It happens all over the place when you have abstractions.
|
11/14/2002 1:31 PM
lvaughn
|
Detail View
New Window
Move/Edit
|
Nick: as soon as a technology spans rfcs things start to decay into chaos
Nick: snmp being a prime example
rob: agreed.
rob: rfcs should all be like the one for pop
rob: they should all be written by americans
Nick: yes
Nick: and no more than three of them
Nick: three americans I mean, not three rfcs
rob: yes. understood.
Nick: though three rfcs tops might not be a bad thing either
rob: i think things should be done like eclipse
rob: people write the damn thing the way they want and then release it. no discussion.
rob: nothing good ever came from discussion.
rob: much less a committee or god forbid a "working group"
|
10/30/2002 4:01 PM
nick
(Modified 4/10/2006 3:14 AM)
|
Detail View
New Window
Move/Edit
|
Linux Trace Toolkit:
The Linux Trace Toolkit, more commonly known as LTT, is a fully-featured tracing system for the Linux kernel. It includes both the kernel components required for tracing and the user-level tools required to view the traces.
Many regard LTT as a best-of-breed tracing system when comparing it to other tracing systems available and it is most certainly the first tracing system distributed as free software under the GPL. It is therefore open for customization and enhancement.
Over the years, LTT has been enriched by many contributors who have added many of the features currently found in LTT.
The following are some of LTT's main features:
* Linux kernel tracing capabilities with 48 unique trace points.
* Variable-length events minimizing overall trace size.
* Micro-second event time-stamps.
* Minimal performance overhead (< 2.5 %).
* Completely configurable trace option during kernel build.
* Multi-platform support: i386, PowerPC, S/390, SuperH, ARM, and MIPS.
* Fully-featured graphical user interface with event graph, system and per-process analysis, and raw event descriptions.
* Cross-platform trace reading capabilities.
* Single copy of traces between kernel-space and permanent storage.
* User-selectable and dynamically configurable event trace mask.
* Dynamic creation and logging of custom events both in kernel and in user space.
* Support for custom formatting of custom events.
* Dynamic probe integration with IBM's DProbes.
* Support for the Real-Time Application Interface (aka RTAI).
* General hooking interface available within kernel trace facility.
|
10/28/2002 4:09 PM
jcohen
|
Detail View
New Window
Move/Edit
|
CS-TR-02-9: Notes on Postmodern Programming:
Notes on Postmodern ProgrammingCS-TR-02-9
Authors: James Noble, Robert Biddle
Source: [US mirror 1]
Adobe PDF(1797kb)
; GZipped PostScript
(1700kb)
Source: [US mirror 2] Adobe PDF(1797kb) ;
GZipped PostScript
(1700kb)
Source: [US mirror 3] Adobe PDF(1797kb)
; GZipped PostScript
(1700kb)
Source: [US mirror 4] Adobe PDF(1797kb) ;
GZipped PostScript
(1700kb)
Source: [NZ mirror 1] Adobe PDF(1797kb) ;
GZipped PostScript
(1700kb)
Source: [NZ mirror 2] Adobe PDF(1797kb) ;
GZipped PostScript
(1700kb)
Source: [NZ mirror 3] Adobe PDF(1797kb) ;
GZipped PostScript
(1700kb)
or if you must
Source: Adobe PDF(1797kb)
; GZipped PostScript(1700kb)
These notes have the status of letters written to ourselves: we
wrote them down because, without doing so, we found ourselves making up new
arguments over and over again. When reading what we had written, we were always
too satisfied. For one thing, we felt they suffered from a marked silence as to
what postmoderism actually is. Yet, we will not try to define postmodernism,
first because a complete description of postmodernism in general would be too
large for the paper, but secondly (and more importantly) because an
understanding of postmodern programming is precisely what we are working
towards. Very few programmers tend to see their (sometimes rather general)
difficulties as the core of the subject and as a result there is a widely held
consensus as to what programming is really about. If these notes prove to be a
source of recognition or to give you the appreciation that we have simply
written down what you already know about the programmer's trade, some of our
goals will have been reached.
[Up to Computer Science Technical Report Archive: Home Page]
ntornow(10/28/02 11:52 PM CST): "Postmodern computer science tends to eschew metaphor ?rather, in place
of a metaphor we have a past. This is true on both the large scale (the disci-
pline as a whole) and the small scale (individual programmers and programs).
Postmodernism is often descriptive: recording the state of the world, rather
than presenting some grand theory. Writing programs follows reading pro-
grams, because postmodern programming is extension, recovery, reuse, rather
than creating masterpieces from nothing. Theory follows practice, because we
aim to understand the world as it is, rather than remake it from scratch with a
genesis device [64]."
ntornow(10/29/02 12:17 AM CST): The Rational Software Process ? How and Why to Fake it describes why unifying
irrational processes is more rational than Unied Processes [56, 47].
|
10/23/2002 10:57 AM
lvaughn
(Modified 10/29/2002 1:17 AM)
|
Detail View
New Window
Move/Edit
|
Linus On Coding Style
1 Oct - 7 Oct (26 posts) Subject: "[patch] Workqueue Abstraction, 2.5.40-H7"
In the course of discussing a workqueue abstraction patch, Linus Torvalds gave
some opinions of coding style issues:
Pease don't introduce more typedefs. They only hide what the hell the thing
is, which is actively _bad_ for structures, since passing a structure by
value etc is something that should never be done, for example.
The few saved characters of typing do not actually _buy_ you anything else,
and only obscures what the thing is.
Also, it's against the Linux coding standard, which does not like adding
magic single-letter suffixes to things - that also is the case for your
strange "_s" suffix for a structure (the real suffix is "_struct").
Remember: typing out something is not bad. It's _especially_ not bad if the
typing makes it more clear what the thing is.
He added in reply to himself:
Btw, just to avoid counter-examples: Linux does use structures and typedefs
occasionally to hide and force compiler typechecking on small structures on
purpose. We have a few places where we do things like
typedef struct {
unsigned int value;
} atomic_t;
(and similar things for the page table entries etc).
This is done because the things are often really regular scalars, but we
use the structure as a strict type checking mechanism. In this case, using
a typedef is fine, because we don't actually ever want to _access_ it as a
structure, and the typedef provices exactly the kind of information hiding
that we need.
But type hiding for a real structure just doesn't make sense, since we use
it as a true structure, and hiding information just makes it harder to see.
Elsewhere, he added:
Big things should have big names. That's why "u8" is u8, because it's not
just physically small, it also has very little semantics associated with
it.
I want those variable declarations to stand out, and make people understand
that this is not just a variable, it's a structure, and it may be taking up
a noticeable amount of space on the stack, for example.
That's the main issue for me. I don't personally care so much about trying
to avoid dependencies in the header files that can also be problematic.
That's probably partly because I use fast enough machines that parsing them
a few extra times doesn't much bother me, and circular requirements tend to
be rare enough not to bother me unduly.
So the thing is a big red warning sign that you're now using a complex data
structure, and you should be aware of the semantics that go with it.
|
10/14/2002 2:33 PM
jcohen
|
Detail View
New Window
Move/Edit
|
From http://www.fortune.com/indexw.jhtml?channel=artcol.jhtml&doc_id=208505&page=3:
Even before Ballmer gave the green light, Bill envisioned how the new operating
system and its applications should delight users. The vision was--well, you have
to hear him tell it: "My biggest thing is getting knowledge workers to install
this version of Windows and say, 'Wow!' in two dimensions. As in 'Wow, they took
the pain away! They fixed the stuff that was always crummy!'--like it was hard
to update the software, to move files between different systems, to understand
what these error messages meant, etc.' And as in 'Wow, I can get new value out
of my PC by taking it to meetings and taking notes on it. I'm doing annotations,
or when I call somebody my screen comes alive, and we're looking at the article
or contract or budget we're working on, and if I want to add somebody into the
call, I just go to my screen, pick the name, and all that phone stuff just
happens--the guy is there and looking at the same document.' And then, having
all your stuff available anywhere on any device you own."
....
? I want to make sure that you guys are asking the right questions.You can't ever forget that the No. 1 question we're trying to solve with Longhorn is "Where's my stuff?" Right now, file space on any PC is a cesspool. The file system should be more like e-mail archives, where you can search and sort by any of a number of criteria. And it's got to be snappy as heck.
? I'll give you the philosophy: Everything is just a document, whether it be music or video or e-mail or whatever. Each will have a name and a history, and every user will have his or her favorites.
? If we can get this nailed so that I can find my stuff no matter what device I'm using, I think Longhorn will become a real breakthrough. Everything beyond that is extra credit.
...
His favorite by far is the Tablet PC, a cross between a conventional laptop and a pen-enabled computer, which is due to hit the stores this fall. (Microsoft came up with the design specification, but the devices will be made and sold by PC makers.) He's convinced that "digital ink"--basically, your handwriting superimposed on a document onscreen--will become an extremely versatile and popular way to record data. He is especially hopeful about integrating digital ink into instant-messaging programs so you can exchange drawings or handwritten notes electronically.
...
Among his favorite projects is BestCom, an experimental program that turns a PC into an administrative assistant. It will screen calls and e-mails, set up and confirm meetings and telephone conferences just by entering them in the calendar, and prioritize and forward messages to the user's cellphone, PDA, or pager when he's out of the office. Bill calls it Outlook Plus and hopes it can be turned into a product for Longhorn.
...
He's keen on another project called Broadbench, the brainchild of Gary Starkweather, best known for inventing the laser printer back in the 1960s at Xerox's legendary Palo Alto Research Center. Broadbench is a parabolic screen for your computer as big as your desk. Indeed, Gates foresees a time when Broadbench will evolve into your desk itself. Talk about a paperless office. Says Starkweather: "Bill isn't afraid of taking long-term chances. He also understands that you have to try everything, because the real secret to innovation is failing fast."
|
10/9/2002 12:15 AM
nick
|
Detail View
New Window
Move/Edit
|
800x600 155104262 (49%)
1024x768 121398548 (38%)
1280x1024 13531564 (4%)
1152x864 9829770 (3%)
640x480 9444499 (2%)
Unknown 3905573 (1%)
1600x1200 2502246 (0%)
65K (16bit) 148177104 (46%)
(32bit) 123793320 (39%)
16M (24bit) 31610814 (10%)
256 (8bit) 11340506 (3%)
Unknown 689158 (0%)
16 (4bit) 105560 (0%)
1. MSIE 5.x 169637980 (47%)
2. MSIE 6.x 154125573 (43%)
3. Netscape 4.x 9869530 (2%)
4. MSIE 4.x 8169025 (2%)
5. Netscape comp. 3753432 (1%)
6. Opera x.x 3226772 (0%)
7. Netscape 5.x 2958492 (0%)
8. Netscape 6.x 2238267 (0%)
9. Unknown 971997 (0%)
10. Netscape 3.x 179262 (0%)
11. MSIE 2.x 172519 (0%)
12. MSIE 3.x 155969 (0%)
13. Netscape 2.x 16692 (0%)
14. Netscape 1.x 478 (0%)
15. MSIE 1.x 337 (0%)
1. Win 98 181018437 (50%)
2. Win 2000 82785427 (23%)
3. Win ME 45447765 (12%)
4. Win NT 16512470 (4%)
5. Win 95 13621803 (3%)
6. Mac 7619278 (2%)
7. Unknown 4554189 (1%)
8. Win 3.x 1561301 (0%)
9. Linux 1158518 (0%)
10. WebTV 794126 (0%)
11. Unix 264307 (0%)
12. Win XP 96533 (0%)
13. OS/2 31460 (0%)
14. Amiga 10711 (0%)
|
10/8/2002 11:59 AM
jcohen
|
Detail View
New Window
Move/Edit
|
|
It all starts here -> http://www.section508.gov/
--Mike
> -----Original Message-----
> From: Louis Woodhill
> Sent: Wednesday, September 25, 2002 1:56 PM
> To: Mark Cresswell (E-mail); Brent Rhymes (E-mail)
> Cc: Shelby Fike (E-mail); Brian Helman (E-mail); Michael Cerny; Jason Cohen (E-mail)
> Subject: Section 508 requirement
>
> Mark:
> Brent:
>
> As of 1/1/03, we will not be able to sell anything to the Federal Government unless it is "Section 508 Compliant". This has to do with the UIs of the product being usable by blind or otherwise handicapped people.
>
> Louis
>
> Mike: Please forward Mark and Brent links to this requirement.
|
10/2/2002 5:13 PM
jcohen
|
Detail View
New Window
Move/Edit
|
Fw: Computerworld: Users Struggle With Bad Code
All,
Bugs are expensive, with the most expensive ones being those that
actually cost *lives* like the Canadian-built computer-controlled
radiation machine that killed a few patients with lethal doses
because of a programming error. The following burst of articles in
Computerworld was occasioned by the release of a NIST study that
concluded that of all the ways that bugs in commercial software that
make it all the way out into the field are Really Expensive for all
concerned.
These articles feed into my current focus on the need for programming
tools that reduce costs in phases of the software product lifecycle
other than original development. A good Console is a facility that
reduces costs in the field, but so are features of the programming
environment that reduce the number of bugs that make their way out
the door/reduce the impact of the ones that do.
First and foremost, to reduce the number of bugs, reduce the number
of lines of code that are required to perform a certain number of
function points. PTK certainly seems to do that. But their are a
lot of other possibilities, and whenever we convene to discuss
"Software Goodness", we should certainly try to enumerate them.
Recently, Jason has stated his belief that much needed code analysis
can be automated at reasonable cost, and this is certainly worth
exploring. For now, however, I just want to put in a plug for PTK
facilities that make it easy for even the laziest programmer to
include "Reasonableness Checks" in his logic.
The most generic form of reasonableness check we have discussed is
probably what in the Shadow Mainframe code is called "Last-Ditch Loop
Control", where the Shadow address space detects that it is using so
much CPU time that it must be looping, and shuts itself down rather
than futilely burning up the mainframe's resources. In the case of
the Radiation Machine that killed, it would have been awfully useful
if the programmer who wrote the code had not been too lazy to compare
the dosage his module calculated should be delivered to a lethal dose
and refuse to deliver that much or more.
(I actually would not mind much more fine-grained loop control via
programming constructs like DO UNTIL BUT NOT FOREVER, and DO WHILE
WITHIN REASON.)
I don't think we will ever figure out how to ship complex new
software that has no bugs in it. But we should be able to anticipate
what the symptoms of many of the possible Serious Bugs would look
like and check to see if they are happening, rather waiting for our
users to detect the bugs and figure out how to recover from them/be
diligent enough to report them to us.
But none of these things will happen unless the needed functionality
is almost totally inherited from the programming environment.
Otherwise, the time/cost of initial development will continue to be
the only kind of time/cost that is minimized, and the much-larger
costs in other phases of the product lifecycle will continue to be
ignored.
Jim Woodhill
713-828-2138 / jim@woodhill.com
http://www.computerworld.com/softwaretopics/software/story/0,10801,72363,00.
html
Don't Shrug Off Bugs
IN Computerworld, 1 vii 02
By FRANK HAYES
How much do bugs cost us? This week we have an estimate. The U.S.
government's National Institute of Standards and Technology (NIST)
released a study that says software errors cost U.S. users $59.5
billion each year. That's more than Bill Gates is worth these days
($52.8 billion, according to Forbes), but it's still only about $200
per American.
Of course, most corporate IT shops won't care.
Then again, the NIST estimate is very conservative - it specifically
excludes catastrophic software errors that might shut down a business
or cost big money in some other way. That $59.5 billion is just the
cost of routine work-arounds and corrections by users, along with the
added cost of buggy software that had to be fixed late in the
development process. The real cost of bugs is much higher.
Most IT shops still won't care.
Oh yeah - the NIST study also calculates that $22.2 billion of that
$59.5 billion, or 37%, could be saved through "feasible improvements"
in software testing. Not pie-in-the-sky, exterminate-all-bugs
campaigns, but practical approaches to catching and fixing bugs
sooner in the development process.
Hear that yawn? That's the sound of most of us, still not caring.
And why don't we? We should. We're always hearing from analysts and
the boss how important it is to get a return on investment from IT,
and how IT's No. 1 goal these days is cutting costs. But we know it's
hard to quantify the ROI of having fewer bugs. It's tough to tote up
the savings from time not wasted by employees using the applications
we create.
Now, for once, we've got credible numbers that say we can get a
quantifiable return if we invest in better ways of writing software.
And we don't have to become perfect to get that return. We just have
to get better.
And the improved security from fewer bugs? Better customer retention
on the Web site because of fewer bugs? Reduced downtime and lower
risk of lost data or catastrophic failure due to fewer bugs? We'd get
all that, too - along with our share of that quantifiable $22.2
million in low-hanging fruit.
So why don't we do it? It's not that we really don't care. It's that,
at a gut level, we don't believe that it's possible, or that it's
necessary, or that it matters. We indulge ourselves with the idea
that all software has bugs, so trying harder to get rid of them is
pointless perfectionism.
Intellectually, we should know better. Our ways of building
applications are outdated. They come from a time when users were
grateful to have any real-time access to data at all, when customers
were insulated from all our systems by at least one layer of
employees, when our systems were important but not truly mission-
critical - if worst came to worst, employees could keep the business
going using pencils and paper.
But now our users just plain can't do their jobs if our systems fail.
And we have real, revenue-generating customers using our Web
applications and experiencing every error and flaw. And bugs aren't
just an annoyance anymore - they're a real threat to productivity and
profitability.
Software is ever more critical and ever more complex. And with so
much riding on it, we can't afford the bug- ridden way most of us are
still writing it. We've got to prevent the bugs we can and catch a
lot more of the rest long before the code moves on to QA.
There are lots of ways of doing it: programming in pairs, unit
testing early and often, radically increasing use of automated
testing tools. There are straitjacket methodologies and lightweight
best practices, approaches that will cost a bundle, and techniques
that just require a little training and a lot of commitment on the
part of programmers.
But none of them will make a difference until we really do start
believing that bugs matter and that our software has far too many of
them - and that they're costing us billions.
FROM
http://computerworld.com/softwaretopics/software/story/0,10801,72390,00.html
Users Losing Billions Due to Bugs
IN Computerworld, 1 vii 02
By Patrick Thibodeau and Linda Rosencrance
WASHINGTON -- IT managers have long known that software bugs cost
money, and now, thanks to a landmark federal study, they know how
much: $59.5 billion a year.
Nearly two-thirds of that cost, 64%, is borne directly by end users,
with developers and vendors incurring the remainder, according to a
309-page report from the National Institute of Standards and
Technology, a federal agency that conducts extensive research on
technology issues.
There are very few markets where "buyers are willing to accept
products that they know are going to malfunction," said Gregory
Tassey, the NIST senior economist who headed the study. "But software
is at the extreme end, in terms of errors or bugs that are in the
typical product when it is sold."
The study, the result of 18 months of research including extensive
feedback from users, examined the impact of buggy software in the
automotive, aerospace and financial services industries and then
extrapolated for all U.S. markets. The nonprofit Research Triangle
Institute in Research Triangle Park, N.C., conducted the study for
the NIST.
One case study in the automotive and aerospace industries involved
interviews with 10 software developers and 179 users of
computer-aided design, manufacturing and engineering systems and
product data management software. Some 60% of those surveyed said
they had experienced "significant software errors" in the previous
year. The total cost in these sectors from inadequate software
testing was estimated to be $1.8 billion.
Similar results were found in the financial services sector, where
four software developers and 98 users were interviewed. According to
the study, developers agreed that an improved testing system was
needed that could track a bug to where it was introduced and show how
it influenced the rest of the production process.
Not everyone agrees with the study. Cem Kaner, a computer science
professor and attorney at the Florida Institute of Technology, said
the report incorrectly blames poor testing for bugs. The problem is
software design and development, he said. "Testing will expose a few
of the weakness that are left," he said.
But Boris Beizer, an independent consultant in Huntingdon, Pa., said
the NIST study is any that has ever been done in pinning down
economic cost. Nonetheless, he said software is improving but also
getting more complicated, "and that's driven by users."
Beizer said he doesn't believe the study points to a software quality
crisis and said the market has forced many lousy vendors out of
business. Users' best defense continues to be to "trash the companies
that give them bad software," he said.
One vendor said the NIST study isn't taking into account productivity
gains from software that's being asked to do a lot more. "They're not
giving suitable credit for that," said Chuck Grindstaff, president of
product life cycle management products at Electronic Data Systems
Corp. in Plano, Texas.
The study calls current testing tools "primitive" and said standards,
particularly those that lead to early detection of bugs, could reduce
the economic impact by about a third, but it won't eliminate all
errors.
"Patches are a hidden tax on users," said Andrew Jaquith, who studies
the economic impact of security- related bugs at @Stake Inc. in
Cambridge, Mass. The study "puts numbers around the age-old theory
that it's better to catch things early than late," he said.
FROM
http://computerworld.com/softwaretopics/software/story/0,10801,72376,00.html
Users Struggle With Bad Code
IN Computerworld, 1 vii 02
By Patrick Thibodeau and Linda Rosencrance
Even if IT managers don't measure the cost of software bugs, they can
see the results.
For instance, Frank Hood, CIO of information systems at Krispy Kreme
Doughnut Corp. in Winston-Salem, N.C., said that on average, two
staff members spend two weeks every quarter fixing security-related
bugs, as well as bugs in the operating system and other applications.
Hood said software vendors don't always offer companies a hot fix,
but rather say they're going to fix the problem in the next version
and offer a "verbose" work-around instead. And he said there's not
much a user can do about it. "Unless they're so leveraged in your
company, you're at their mercy," Hood said.
Ashok Bakhshi, IT director at Schindler Elevator Corp. in Morristown,
N.J., said it's an added expense for employees in the field to have
to download and install software fixes. "I think it would be very
enlightening to see how much money we are wasting with bugs," he said.
The National Institute of Standards and Technology, in its report on
bugs, said testing standards could reduce costs, but it doesn't
suggest how to get to that point. One group working on software
quality problems is the Sustainable Computing Consortium, which
consists of 18 organizations from all sectors of the economy and is
located at Carnegie Mellon University in Pittsburgh. The consortium
has teamed up with the school to develop new standards, measurement
tools and best practices research to improve software quality,
dependability and security.
"There is no way for vendors and users to measure the quality of the
code," said William Guttman, a professor of economics and technology
at Carnegie Mellon.
Security issues fuel much of the demand for code improvements. Users
need to get mad, said Shawn Hernan, the team leader for vulnerability
handling at the CERT Coordination Center at Carnegie Mellon. "Anger
would be the right thing, particularly in respect to security. It's
literally the same mistakes being made over and over again," he said.
|
7/7/2002 11:39 AM
nick
(Modified 4/10/2006 3:17 AM)
|
Detail View
New Window
Move/Edit
|
From http://www.mathcs.sjsu.edu/faculty/rucker/chaos.htm:
(This is a funny example of what software goodness is not -- jc)
Note for users of Windows NT. When exiting a module of the CHAOS program, press Alt-X followed by Y for yes to get out to the CHAOS start screen, just as is customary. At this point you would expect to press Alt-X to exit the program. (This move works in Win95, but not in WinNT.) But in WinNT, you should instead press Ctrl-Alt-Del to bring up a Windows NT Security dialog. Press T for Task Manager. The dialog will disappear, and the CHAOS start screen will briefly reappear. Wait for a few seconds and then the Windows NT Task Manager will appear. Highlight the DOS CHAOS application and select End Task. Wait a few seconds for the task to terminate.
|
7/1/2002 11:15 AM
jcohen
|
Detail View
New Window
Move/Edit
|
|
View Store: software quality