>
> 2. There are two types of defects: Design and Implementation.
> a. Design defects are a direct reflection on the Software Architect's
> inability to properly design a robust program, or to interpret Business
> Requirements.
>
> Perhaps someone's inability, but you must understand at least two things,
> 1) Software Architects don't dictate the robustness of a program, they
> only implement it. Robustness often costs and is not required. If my
> market for a product is for a small English only group, is a defect that
> is was not designed to be easily translated to French? If it did not meet
> the original design and testing specifications then it would never get out
> to the public. Should you say that nothing is a defect simply because it
> was not planed for, or should plan for everything and never release a
> program? You make the assumption people know their business requirementsand understand how to implement them using rigid logic.
> Remember, software design is a business, if you do as asked you get paid,
> even if it is ridiculous. It is not the software designers job to fully
> understand the business process, just like it is not an architects
> business to understand why you want a specific design element. If you
> decide you want a house that looks like a giant piece of steaming animal
> waste, the it is the architects job to bring your dream to life, just as
> you asked for it. HE may point out that it looks like crap, and that
> certain things like solar gain and water drainage can be more efficientlyhandled by other
> designs, but if the client says that they want crap, that is what they
> will get, with no absolution.
>
This is precisely why it is usually engineers make the most successful
software companies. Examples: Larry Ellison, Bill Gates( ! ), Steve Jobs,
Charles Wang, and countless others. Only an engineer can spot a true
opportunity in the software realm. Other people can see 'domain
requirements' but who is to say that implementing those requirements is
profitable? I cannot count the number of times that I have met people who
think they are a genius for simply /recognizing a need/. How many of you
have been in the situation where implementing something is deemed profitable
by an unqualified manager, and at some undefined point in the development
schedule, making this project profitable becomes YOUR problem?* Its always
entertaining to run into the next 'software tycoon' who considers code to be
irrelevant 'technical details'.
a fun site, a nice reminder of the simple beginnings of the personal
computer:
http://apple2history.org/intro/intro.html
the Apple II included a 'reliable typewriter-style keyboard'!.
http://apple2history.org/museum/ads/simplicity.html
-jmz
* hint: never get yourself in this situation.
b. Implemetation defects are a direct reflection on the developer's
> inability to either do what he/she is told, or his/her inability to ask
> questions about requirements they do not understand.
>
> Again, you make the assumption that the people they are asking questions
> to know the answers. Or that they even know the questions to ask. If you
> design an application and you ask "hey are there any government or agency
> regulations I need to know about?" and get a no, well it is not their job
> to look any further. If it was then they would be an industry lawyer not
> a software designer. All parties involved should do what they can to know
> all points and facilitate understanding, however you must also understand
> where your time is best spent and what the scope of your work is. If the
> people who want the software say, "I don't know, could you find out?" then
> the software developer should get a quote from an industry lawyer and pass
> it up, but the hundreds of hours used to do the research your self would
> bring incomplete results and waste your budget.
>
>
>
> 3. When software defects kill people, the Software Engineering industry
> will have no choice but to become a credible engineering discipline like
> mechanical engineering, electrical engineering, and architecture with the
> accompanying reviews and professional certifications.
>
> That is like saying every person who hangs dry wall needs to be a licensed
> civil engineer. The people who need to be are, and the people who are not
> are not. But it is the responsibility of the buyer to understand that
> they can not higher an unlicensed general contractor to designee and buildacommercial high
> rise. Nor should you pay a professor in fluid dynamics to unclog your
> toilet. There is not one stander because there is not one kind of
> software. The world is complex, get over it. Do I believe the that
> society for professional engineers will one day license software engineers
> … Maybe, but more likely they would license computer engineers who would
> then specialize. And that is a ways off, right now there are a number of
> engineering disciplines that are purely state regulated, such as Fire
> Protection. Really, much outside Civil, Electrical, Mechanical, Chemical,
> Industrial, Environmental, and Aerospace, don't bank on seeing it any time
> soon.
>
> This sort of reminds me of one of my engineering professors though; the
> first day of class he looked out across the room and said "I am sure manyof you think you will get an
> 'A' in my class. What is an A? 90%? If you strive and achieve a 90% you
> should get an 'A' right? Wrong your engineers! If you get it 90% correct10% of all the planes fall out of the sky at any given time and you are
> responsible for the deaths of hundreds of thousands of people! Your
> playing with peoples lives now, you need to be 100% correct at all times
> to even pass my class! (Indecently I think with the curve an 'A' was 65%
> or better ;)
>
> Of course my static's professor's favorite exercise was giving you a
> bridge design and seeing who could cut the most material out and keep it
> standing. The goal was usually 10% cost savings or better without total
> collapse per the recommended design factors. :)
>
>
>
> ymmv,
> C.G.
>
> On 7/1/07,* George Toft* <*george@georgetoft.com* <george@georgetoft.com>>
> wrote:
>
> *http://georgetoft.com/georgeslaw.shtml*<http://georgetoft.com/georgeslaw.shtml>
> From my college days . . .
>
> "Hey, Grampa, tell us the story about 80 column punch cards, and why a
> good rubber band was your best friend. You mean you couldn't just talk
> to the computer?"
>
> "Well, Sonny, columns 1-5 were for your numeric labels. A 'C' in column
> 6 meant it was a continuation from the previous line, and your code went
> in columns 7-72. Columns 73-80 were your card sequence number and it was
> optional. Nobody liked to put numbers there because if we moved a block
> of code, we would have to resequence the cards. Screw that - just make
> sure you had a good rubber band, and another one as a backup in case the
> first one broke. Gives you a whole new meaning of data backup, huh."
>
> "Grampa, what was the deal with column 1 on the printer?"
>
> "Oh, yeah. Put a 1 in column 1 and the printer won't advance. Print
> about 10 lines with this:
> 1====================================================
> and all of the print wheels on the line printer would line up and the
> strikers would synchronize and go WHOMP WHOMP WHOMP and shake the whole
> computer center. Heh, heh, heh. The computer operators would jump out of
> their skin - they definitely knew when I ran a job."
>
> "Grampa, what's a line printer?"
>
>
>
> George Toft, CISSP, MSIS
> 623-203-1760
>
>
>
>
> Mark Jarvis wrote:
> > (repost using email address I signed up with)
> >
> > In 1960 (+ or - a year) I took a programming class at ASU where we used
> > the LGP-30. It had a 1000 (1024?) word drum and each word was 32 bits.
> > The drum was the main memory--there was no other storage. It had
> > 16--yes 16!--instructions with paper tape input and typewriter output
> > and it had a one or two inch oscilloscope where you could watch the
> > instructions execute. Part of each instruction was the address of the
> > next instruction to be executed. Too few today have the assembly
> > language background to appreciate the oddities of the machine, but it
> > had some doozies. Five years later I had graduated and was working at
> > Motorola Semiconductor on McDowell and transferred into the computer
> > section of the QC department. We had a GE 205 computer with 8192 20 bit
> > words of memory. If I remember correctly, a single word memory access
> > took 36 microseconds. When sorting 30 row, 12 column table using the
> > Shell sort algorithm, the console lights made a several second long
> > pattern that was quite easy to spot. BTW, the 205 was the entry level
> > knockoff of the GE215 box. Since the 215 had a memory cycle time of 18
> > microseconds, GE added a bunch of circuit boards to steal every other
> > clock cycle to make the machine slower so they could lease it for less.
> > Go figure!
> >
> > Yes, for lots of years I used decks of cards for both programs and
> > data. If you had any sense, you sequenced your cards in col 73-80 so
> > that when (not if--when) the deck was dropped, a few passes through the
> > sorter would fix things--and you initially sequenced by 10s or 20s to
> > allow for later additions.
> >
> > While I wouldn't take anything for the experiences of those years, I
> > wouldn't go back to them for anything either.
> >
> > Mark Jarvis
> >
> > Jim wrote:
> >
> >
> >>Lynn Newton wrote:
> >>
> >>
> >>
> >>>But I'm sure there are a number of subscribers to this list
> >>>who can one-up me with "I remember when" stories, by margins
> >>>of several years at least.
> >>>
> >>>
> >>
> >>I don't know if this would be in the one up category, but I remember
> >>being a high school freshman in 1981 and spending time after school in
> >>the math teacher's room messing around with his TRS80 with a whopping
> >>4KB RAM and running programs stored on cassette tape.
> >>
> >>
> >>
> >
> >
> > ---------------------------------------------------
> > PLUG-discuss mailing list - *PLUG-discuss@lists.plug.phoenix.az.us*<PLUG-discuss@lists.plug.phoenix.az.us>
> > To subscribe, unsubscribe, or to change your mail settings:
> > *http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss*<http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss>
> >
> >
> ---------------------------------------------------
> PLUG-discuss mailing list - *PLUG-discuss@lists.plug.phoenix.az.us*<PLUG-discuss@lists.plug.phoenix.az.us>
> To subscribe, unsubscribe, or to change your mail settings:
> *http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss*<http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss>
>
>
>
>
> --
> *powerofprimes@gmail.com* <powerofprimes@gmail.com>
> Carlos Macedo Gomes
> _sic itur ad astra_
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
--
.0000. communication.
.0001. development.
.0010. strategy.
.0100. appeal.
JOSHUA M. ZEIDNER
IT Consultant
( 602 ) 490 8006
jjzeidner@gmail.com
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)