Software bloat (Larkin was right)
in [Design]
|
Prev: OrCad/ question
Next: Capture hierarchy
From: Michael A. Terrell on 20 May 2010 21:44 John Larkin wrote: > > On Thu, 20 May 2010 15:28:37 -0400, "Michael A. Terrell" > <mike.terrell(a)earthlink.net> wrote: > > > > >Joel Koltner wrote: > >> > >> "D Yuniskis" <not.going.to.be(a)seen.com> wrote in message > >> news:ht3t6d$soh$1(a)speranza.aioe.org... > >> > The problem I see with *all* OTS "business solutions" is they > >> > want to impose their business logic on *your* business. They > >> > want you to process and use data the way *they* envisioned. > >> > >> Yes, so it would seem. > >> > >> > In addition, they impose arbitrary constraints on the data, etc. > >> > Is there some reason a "description" has to fit in N characters? > >> > Or that a P/N has to fit a certain template? etc. > >> > >> 20 and perhaps even 10 years ago, I think there were decent reasons for this > >> with limited memory, hard drive space, etc... but unfortunately the software > >> vendors for this kind of program seem to be very slow to change. > >> > >> > I think this is a result of misplaced efficiency tradeoffs. > >> > I.e., they want to be able to index/search data "quickly"... > >> > saving a few micro/milliseconds on each operation. Yet, they > >> > are oblivious to the seconds, minutes or even *hours* of > >> > "real time" delays that these "efficiencies" cost -- when > >> > a user can't locate a particular item (because the item's > >> > ABBREVIATED DESCRIPTION was abbreviated inconsistently or > >> > used one keyword instead of another, etc.). > >> > >> Yep, agreed 100%. > >> > >> And I think Google has shown that you can effectively index orders of > >> magnitude more data than any one company will ever produce and still get > >> searches down well below one second. > >> > >> > This, I think, is an outgrowth of the same sort of > >> > ridiculous mindset that people initially bring to > >> > *organizing* data. E.g., how many part numbering systems > >> > have data embedded *in* the part number that tries to > >> > describe the item? (isn't that the role of the *description* > >> > tied to the P/N??) People impose structure on things > >> > unnecessarily instead of letting the machine do that on > >> > their behalf. > >> > >> I've tried to discourage embedded lots of information into a part number, > >> although I do see value in trying to get the most basic information (e.g., > >> resistance for resistors) in there. I agree that a lot of people seem to want > >> to embed 3 or more fields into a part number and it rapidly gets to the point > >> where you need a secret decoder ring, though. > >> > >> > E.g., when I started preparing documents, standards, etc. > >> > here, I used a much more commonsense approach: I started > >> > with *1* :> (instead of something artificial like > >> > 1985-SPEC-SFW-001.1 -- the ".1" being a revision level, etc.) > >> > Then, moved on to "2". > >> > >> We'll occasionally have internal discussions on how to number software > >> revisions, and I've generally advocated that we just stick the build date and > >> time in the code and be done with it (that's what I do with my own software). > >> The tools can do that automatically, so why even worry about whether this is > >> versoin 1.2.4.3 or if it should be bumped to 1.2.5.0? Many times people > >> forget to bump the revision numbers anyway, and this has been a major headache > >> when, e.g., some guy in testing tries to tell a programmer which revision of > >> the code contains a given bug. > > > > > > The idiot engineering manager we had for a few months at Microdyne > >wanted to change all stock numbers. His plan was to use the resistance > >of a resistor as the part number. He threw a hissy fit when I pointed > >out that we had over a dozen different types of 10K resistors in > >inventory. It didn't take them long to fire him when they found out how > >useless he was. I think he was hired by Scott Adams to be Dilbert's > >boss after that. :( > > We spent a goodly amount of time defining how part numbers would be > generated. A resistor part number *does* include its type and value, > and there are rules for what to do if one 10K 0.1% 0603 resistor is > green and another is blue. All the resistors are numerically and > physically in order by value. They used R for the first character, then a three digit code for the type of resistor, followed by more digits for the value. The biggest problem was the 'E' category which was a catchall category. I even found a Chevy Blazer that was part of the Satellite installer group's equipment listed in the 'E' inventory while trying to find an IC they had used in a test fixture. It took half a day to brow beat engineering into admitting that they had built the fixture out of sample parts from several vendors, and there were no spares. > Everything is also available in ASCII files, so you can write your own > Basic or Perl programs to do weird stuff. I recently wrote one to > search for resistor ratios using in-stock parts. > > John -- Anyone wanting to run for any political office in the US should have to have a DD214, and a honorable discharge.
From: D Yuniskis on 20 May 2010 22:58 Hi John, John Larkin wrote: >> You developed this in-house? Why not use something off-the-shelf? >> (OTOH, most OTS solutions force you to do business "their way") > > We tested some commercial packages and didn't like them. They clearly Understandable. > didn't understand the electronics business, were slow (usually sat on This ^^^^^^^^^^ is true of damn near all OTS software solutions, IMO. It *might* work for the folks who wrote it. But, probably won't for anyone else (since no two companies do things the same way) > top of a general-purpose database manager, a hazard in itself) and > often had silly per-seat-per-year license rules. > > I wrote the skeleton of this myself and we hired a contract guy to do > the detail coding. The biggest part wasn't the code, it was inventing > and documenting a new part numbering system, re-describing all the > parts in stock (close to 5000 of them) and moving/relabeling all the > bins. It was worth it, and now we own the source code. I don't believe in "part numbering systems" beyond: "How many digits in the P/N?" (see other thread for my discussion). E.g., how would I even *begin* to assign part numbers to each of the software modules I create? The biggest mistake *I* made was not giving *everything* a part number (I didn't think certain things would ever need to be "controlled"). > The Brat bird-dogged the project to completion, including browbeating > the programmer into doing good work and forcing the engineers to go > through those 5000 part records one at a time. I was impressed.
From: John Larkin on 20 May 2010 23:06 On Thu, 20 May 2010 19:58:07 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: >Hi John, > >John Larkin wrote: >>> You developed this in-house? Why not use something off-the-shelf? >>> (OTOH, most OTS solutions force you to do business "their way") >> >> We tested some commercial packages and didn't like them. They clearly > >Understandable. > >> didn't understand the electronics business, were slow (usually sat on > >This ^^^^^^^^^^ is true of damn near all OTS software solutions, IMO. >It *might* work for the folks who wrote it. But, probably won't >for anyone else (since no two companies do things the same way) > >> top of a general-purpose database manager, a hazard in itself) and >> often had silly per-seat-per-year license rules. >> >> I wrote the skeleton of this myself and we hired a contract guy to do >> the detail coding. The biggest part wasn't the code, it was inventing >> and documenting a new part numbering system, re-describing all the >> parts in stock (close to 5000 of them) and moving/relabeling all the >> bins. It was worth it, and now we own the source code. > >I don't believe in "part numbering systems" beyond: "How many >digits in the P/N?" (see other thread for my discussion). > >E.g., how would I even *begin* to assign part numbers to each >of the software modules I create? I'm talking about electronic parts, not software modules. We use a "telephone number", like 123-4567. The first three digits are the class (103- is the class for 0603 ceramic caps for example) and the last 4 digits are the specific part. 103-1300 is the 10 pF one. We have rules for *everything*. The best way to control software modules is to not have them: use one monolithic source file for a given project. We do assign a part number and a revision letter to a piece of software, just like any other engineering drawing. John
From: D Yuniskis on 21 May 2010 00:38 Hi John, John Larkin wrote: > On Thu, 20 May 2010 19:58:07 -0700, D Yuniskis > <not.going.to.be(a)seen.com> wrote: > >> Hi John, >> >> John Larkin wrote: >>>> You developed this in-house? Why not use something off-the-shelf? >>>> (OTOH, most OTS solutions force you to do business "their way") >>> We tested some commercial packages and didn't like them. They clearly >> Understandable. >> >>> didn't understand the electronics business, were slow (usually sat on >> This ^^^^^^^^^^ is true of damn near all OTS software solutions, IMO. >> It *might* work for the folks who wrote it. But, probably won't >> for anyone else (since no two companies do things the same way) >> >>> top of a general-purpose database manager, a hazard in itself) and >>> often had silly per-seat-per-year license rules. >>> >>> I wrote the skeleton of this myself and we hired a contract guy to do >>> the detail coding. The biggest part wasn't the code, it was inventing >>> and documenting a new part numbering system, re-describing all the >>> parts in stock (close to 5000 of them) and moving/relabeling all the >>> bins. It was worth it, and now we own the source code. >> I don't believe in "part numbering systems" beyond: "How many >> digits in the P/N?" (see other thread for my discussion). >> >> E.g., how would I even *begin* to assign part numbers to each >> of the software modules I create? > > I'm talking about electronic parts, not software modules. We use a > "telephone number", like 123-4567. The first three digits are the > class (103- is the class for 0603 ceramic caps for example) and the > last 4 digits are the specific part. 103-1300 is the 10 pF one. > > We have rules for *everything*. > > The best way to control software modules is to not have them: use one > monolithic source file for a given project. We do assign a part number > and a revision letter to a piece of software, just like any other > engineering drawing. I reuse modules often. It allows me to make "inexpensive" solutions (instead of having to reinvent the wheel each time). It would be quite hard for me to edit 5-50MB source files! :> And, incredibly inefficient having to compile all of that in one piece. (besides the drawback of polluting the namespace therein)
From: John Larkin on 21 May 2010 01:05
On Thu, 20 May 2010 21:38:45 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: >Hi John, > >John Larkin wrote: >> On Thu, 20 May 2010 19:58:07 -0700, D Yuniskis >> <not.going.to.be(a)seen.com> wrote: >> >>> Hi John, >>> >>> John Larkin wrote: >>>>> You developed this in-house? Why not use something off-the-shelf? >>>>> (OTOH, most OTS solutions force you to do business "their way") >>>> We tested some commercial packages and didn't like them. They clearly >>> Understandable. >>> >>>> didn't understand the electronics business, were slow (usually sat on >>> This ^^^^^^^^^^ is true of damn near all OTS software solutions, IMO. >>> It *might* work for the folks who wrote it. But, probably won't >>> for anyone else (since no two companies do things the same way) >>> >>>> top of a general-purpose database manager, a hazard in itself) and >>>> often had silly per-seat-per-year license rules. >>>> >>>> I wrote the skeleton of this myself and we hired a contract guy to do >>>> the detail coding. The biggest part wasn't the code, it was inventing >>>> and documenting a new part numbering system, re-describing all the >>>> parts in stock (close to 5000 of them) and moving/relabeling all the >>>> bins. It was worth it, and now we own the source code. >>> I don't believe in "part numbering systems" beyond: "How many >>> digits in the P/N?" (see other thread for my discussion). >>> >>> E.g., how would I even *begin* to assign part numbers to each >>> of the software modules I create? >> >> I'm talking about electronic parts, not software modules. We use a >> "telephone number", like 123-4567. The first three digits are the >> class (103- is the class for 0603 ceramic caps for example) and the >> last 4 digits are the specific part. 103-1300 is the 10 pF one. >> >> We have rules for *everything*. >> >> The best way to control software modules is to not have them: use one >> monolithic source file for a given project. We do assign a part number >> and a revision letter to a piece of software, just like any other >> engineering drawing. > >I reuse modules often. It allows me to make "inexpensive" >solutions (instead of having to reinvent the wheel each time). I have an editor with advanced "cut" and "paste" features. > >It would be quite hard for me to edit 5-50MB source files! YIKES! Nothing, not even an OS, should be that big! :> >And, incredibly inefficient having to compile all of that in one >piece. (besides the drawback of polluting the namespace therein) My PowerBasic programs rarely take a full second to compile. What's a namespace? John |