Software bloat (Larkin was right)
in [Design]
|
Prev: OrCad/ question
Next: Capture hierarchy
From: krw on 23 May 2010 15:46 On Sat, 22 May 2010 13:05:41 -0700, John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >On Sat, 22 May 2010 13:52:36 -0500, "krw(a)att.bizzzzzzzzzzzz" ><krw(a)att.bizzzzzzzzzzzz> wrote: > >>On Sat, 22 May 2010 10:45:39 -0700, John Larkin >><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >> >>>On Sat, 22 May 2010 09:52:14 -0500, "krw(a)att.bizzzzzzzzzzzz" >>><krw(a)att.bizzzzzzzzzzzz> wrote: >>> >>>>On Fri, 21 May 2010 22:49:48 -0700, John Larkin >>>><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>>> >>>>>On Fri, 21 May 2010 23:42:17 -0500, "krw(a)att.bizzzzzzzzzzzz" >>>>><krw(a)att.bizzzzzzzzzzzz> wrote: >>>>> >>>>>>On Fri, 21 May 2010 19:27:11 -0700, John Larkin >>>>>><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>>>>> >>>>>>>On Fri, 21 May 2010 17:40:55 -0700, D Yuniskis >>>>>>><not.going.to.be(a)seen.com> wrote: >>>>>>> >>>>>>>>Hi John, >>>>>>>> >>>>>>>>John Larkin wrote: >>>>>>>>> On Fri, 21 May 2010 09:40:00 -0700, D Yuniskis >>>>>>>>> <not.going.to.be(a)seen.com> wrote: >>>>>>>>> >>>>>>>>>> Hi Phil, >>>>>>>>>> >>>>>>>>>> Phil Hobbs wrote: >>>>>>>>>>> On 5/20/2010 2:03 PM, D Yuniskis wrote: >>>>>>>>>>>> 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. >>>>>>>>>>>> >>>>>>>>>>>> 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". >>>>>>>>>>>> >>>>>>>>>>>> Data should largely be free-form -- except where it *can't* :> >>>>>>>>>>>> This applies to part numbers, object (file) names, etc. Once >>>>>>>>>>>> you start imposing artificial structure, you start forcing >>>>>>>>>>>> things to be "done your way" -- which, typically, exposes >>>>>>>>>>>> some *flaw* in "your way", later (once you are *very* pregnant!) >>>>>>>>>>>> >>>>>>>>>>>> Put smarts in the system to be able to *understand* the data. >>>>>>>>>>> It's sort of nice to be able to look at a part number and see whether >>>>>>>>>>> it's a capacitor or a BNC connector, though. That doesn't have to have >>>>>>>>>>> descriptions embedded in the part number, but it does need a bit of >>>>>>>>>>> thought, e.g. numbers starting with '0' are subassemblies, '1', >>>>>>>>>>> resistors, '2', capacitors, and so forth. Takes an extra couple of >>>>>>>>>>> digits but makes life a lot easier. >>>>>>>>>> I don't think it works, in the long run. And, I think >>>>>>>>>> the effort spent trying to figure out *how* to do this >>>>>>>>>> (and codifying it and ensuring everyone uses the same >>>>>>>>>> rules) is better used getting better descriptions, better >>>>>>>>>> search capabilities, etc. >>>>>>>>> >>>>>>>>> It is convenient to have all the 0805 resistors in the same part of >>>>>>>>> the stockroom, and not mixed randomly with transformers and sheet >>>>>>>>> metal and shrink tubing. Even more convenient to have them in order by >>>>>>>>> resistance. >>>>>>>> >>>>>>>>There's nothing that says part numbers have to be positioned >>>>>>>>on shelves in sequential order. You track the *location* >>>>>>>>of a part as part of your inventory control system. So >>>>>>>>that you are free to put things wherever is most convenient. >>>>>>> >>>>>>>Cool. Every part gets a location number that determines their location >>>>>>>and order on the shelves. So why isn't that the part number? >>>>>> >>>>>>...and if you change the inventory location you change all your schematics. If >>>>>>you obsolete a part you can never use that shelf again? >>>>> >>>>>A schematic is a reference drawing that doesn't control anything; it >>>>>refers to parts by reference designator. Assembly drawings and their >>>>>associated parts lists control product configuration, and they use >>>>>part numbers. I'm surprised I have to explain stuff this basic. >>>> >>>>Our schematic controls the BOM (guarantees that they're in sync). The >>>>"assembly drawings" are for inspection use only; pick-n-place machines can't >>>>read them. >>> >>>We make dash number versions of assemblies, which includes functional >>>variants and customizations for particular customers. So the values on >>>a schematic are not guaranteed to be correct, and all the shown parts >>>may not be stuffed. Schematic 22S470B is a reference drawing for PCB >>>fab drawing 22D470B and assembly drawing 22A470B. The assembly drawing >>>may in turn have multiple associated parts lists for different dash >>>numbers, a parts list being a file like 22A470.12B for the physical >>>entity 22A470-12B. An ECO or test procedure or manual states which >>>assemblies it applies to. Everything lives on a server. >> >>We use BOMs to do the same. > >Parts list and BOM are the same thing. Ok, but a BOM has a lot more information on it other than a list of parts. It also has information for pick-n-place, and in our case, customization. You indicated that your assembly drawing carried this information. > All of the information for variants is encoded in >>the schematic. > >How do you know in advance that there will be variants? We generally do, but in any case the component properties can be added in a later ECO, if they're not carried in by copying a component from another schematic. > The schematic->BOM utility spits out the BOM, which is >>filtered based on component parameters. Both the BOM and the schematic that >>generated the BOM are housed in the ECO database. > >So if you have 7 stuffing variants of one PC board, you have 7 >schematics? And if you change a part value, you change the schematic? >I assume you use a version control system for schematics, so you know >what was in vogue 17 months ago. Actually eight schematics, one for the raw board. All are in the ECO database, along with the BOM for that variant. >Do you know the configuration of BlueWidget_revE-sn1708? Manufacturing does. ...or they're supposed to. BlueWidget_revE might be RedWidget-sn1708, but S/N 1708 would point to the ECO (and any deviations) that controlled that part. "RedWidget" because the variants get separate assembly and catalog numbers. >>Again, the P-n-P machines can't read drawings. They need BOMs. > >Sure. We have some software that gobbles a coordinate file from PADS, >and the parts list, and some exceptions files, and makes the PnP >control file. That needs some hand editing for how manufacturing >prefers to stage things. Manufacturing makes things their own way; >in-house or out; anything goes as long as the result conforms to the >released drawings. We back-annotate placement back to the schematic (something I force them into - took a while) and then use Crapture to produce the BOMs, as needed. Usually there is some post-Crapture manipulation on the BOM, but there are no manual processes after the back-annotation. <snip> >>>If a part might be needed for a repair, we keep some in stock. One of >>>our selling points is that we will build or repair anything, no matter >>>how old, as long as we possibly can. >> >>So you keep a complete inventory? A whole reel of parts? Boxes of boxes? > >If it's a reel, why not? If it's a pallet of old front panels, we may >keep a few. People make judgements. What do you do if the part comes on a reel this month, but in a tray next month. Do you put 1N/2N JECED numbers on the shelf, in order? Don't get me wrong, 0603 resistors in order makes sense, with the value encoded into the P/N, but there is no reason to have 0603 resistors be between the 0402s and 0805s, or to have nothing between their P/Ns. >>>If a part is truly dead, we physically "retire" it to a section of the >>>basement. You never know if engineering will want to play with one. If >>>it's a real klunker, essentially scrap metal, we get rid of it. >> >>What do you do with the hole? > >A 2" wide gap on a shelf? We ignore it. Or push the guy on the end to >tuck things together. Who cares? Things will settle on their own. If you come up with a series of resistors that is between two others? >>>Libraries stash books on shelves using an almost-as-good system. They >>>don't randomly mix cookbooks with mysteries [1] with DVDs, and they do >>>manage to keep the shelves in order. Books are worse, actually, >>>because they don't get stored in bins, and can float between branches. >> >>I've never seen a library that keeps them in ISBN order. I doubt even Amazon >>keeps them in ISBN order. >> >>>>Why isn't your street address your name? >>> >>>Why do you want to force dogmatic catagorizations when practical >>>things work better? >> >>You're the one who is forcing dogmatic categorizations. I'm asking why your >>name is different. > >I am not a house. Parts are all parts. They don't care where they live, either.
From: krw on 23 May 2010 15:51 On Sun, 23 May 2010 11:46:05 -0700, "JosephKK"<quiettechblue(a)yahoo.com> 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? > >Software is usually kept track of with a version control system. Which >may or may not be (directly) part of your development environment. The object files, or ROM images, are generally stored as part of the ECO system, at least for embedded systems. <...>
From: JosephKK on 23 May 2010 16:02 On Fri, 21 May 2010 11:05:37 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: >Hi Phil, > >Phil Hobbs wrote: >>>> For a lean, poor man's "GUI", consider using a manu system >>>> atop curses. *Very* fast (even over a serial link!) and >>>> has all the "feel" of a GUI without the G. >> >> Curses is well named--it _almost_ does what you want, but never quite. > >Aw, c'mon... that's not fair! :> If you get the termcaps >correct (!), it should behave quite well. (avoid the lower >right corner, etc.) > >I think it is slick as snot! Some of the implementations >have pretty lame optimizations. But, I've seen some that >really had me scratching my head: "How did it know it >could *do* that??" I have to agree, please remember that it was one of the earliest hardware abstraction layers.
From: John Larkin on 23 May 2010 16:07 On Sun, 23 May 2010 14:51:33 -0500, "krw(a)att.bizzzzzzzzzzzz" <krw(a)att.bizzzzzzzzzzzz> wrote: >On Sun, 23 May 2010 11:46:05 -0700, "JosephKK"<quiettechblue(a)yahoo.com> 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? >> >>Software is usually kept track of with a version control system. Which >>may or may not be (directly) part of your development environment. > >The object files, or ROM images, are generally stored as part of the ECO >system, at least for embedded systems. > ><...> I don't mind if my guys use a VCS (I don't use one personally) but they must formally release standalone source files and make files and readme files, using archived tools, so that anyone can come along later and type "GO" or "MAKE" and rebuild everything, even if the VCS is dead and gone. We release firmware as a drawing number and rev letter, just like any other drawing. None of this 7.04.12b version nonsense! John
From: D Yuniskis on 23 May 2010 16:27
Hi Joseph, JosephKK wrote: > The idea of user interface as a FSM surprised be but made immediate > sense. IMO, it is the only *practical* way of doing a user interface! User interfaces are inherently stateful. And, a bunch of ad hoc code to implement them (which conceptually serves the role of an FSM) is awfully hard to debug. "What is valid, *here*?" "What if *this* happens, now?" These sorts of things are really hard to *guarantee* when you have an ad hoc approach to the UI. OTOH, you can almost mechanically verify the proper operation of something that uses a more structured FSM approach as it breaks the problem down into nice bite-sized pieces that can be validated separately. |