Software bloat (Larkin was right)
in [Design]
|
Prev: OrCad/ question
Next: Capture hierarchy
From: John Larkin on 19 May 2010 19:38 On Wed, 19 May 2010 13:23:52 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: >Hi John, > >John Larkin wrote: >> Some of my PBCC utilities (Windows console apps) with basic screen >> menus but not official Windows gui stuff, compile to numbers like 32K. >> I have a test program for a digital delay generator, full of menus and >> RS232/ethernet access to the DUT, that's 44K. >> >> Our pretty extensive material control system is a 400 kbyte EXE, 18K >> line source file. The size isn't so important as are the speed and >> reliability. > >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. Here's our parts thing, home page. It's all single-letter keystroke commands and prompts. It a blast to drive. ftp://jjlarkin.lmi.net/MAX.jpg You can look at all parts, do searches, do where-used, browse parts lists, see datasheets/photos/links/engineering notes. Parts selected in one context are carried over into others... you can prowl a parts list, highlight a part, escape out, and the part is featured on the home page. Then do where-used, or open the part data file, or enter the total parts report at that point. John
From: D Yuniskis on 20 May 2010 13:02 Hi John, John Larkin 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. > > Here's our parts thing, home page. It's all single-letter keystroke > commands and prompts. It a blast to drive. > > ftp://jjlarkin.lmi.net/MAX.jpg > > You can look at all parts, do searches, do where-used, browse parts > lists, see datasheets/photos/links/engineering notes. Parts selected > in one context are carried over into others... you can prowl a parts > list, highlight a part, escape out, and the part is featured on the > home page. Then do where-used, or open the part data file, or enter > the total parts report at that point. You developed this in-house? Why not use something off-the-shelf? (OTOH, most OTS solutions force you to do business "their way")
From: Joel Koltner on 20 May 2010 13:31 "D Yuniskis" <not.going.to.be(a)seen.com> wrote in message news:ht3pie$ncb$2(a)speranza.aioe.org... > You developed this in-house? Why not use something off-the-shelf? > (OTOH, most OTS solutions force you to do business "their way") I've wondered the same thing, Don (see, there, I got your name correct :-) ) -- but I've now worked at two small companies that spent more than three years trying to get expensive commercial MRP systems fully deployed without success (...company #1 went belly-up, company #2 is still working on it), so I give John a lot of credit for solving the problem himself and just getting on with the core part of his business -- design engineering. The only small company I've worked for that had their MRP system "under control" was using Greapt Plains (now Microsoft Dynamics). No one really liked it, but it did at least get the job done. ---Joel
From: D Yuniskis on 20 May 2010 14:03 Hi Joel, Joel Koltner wrote: > "D Yuniskis" <not.going.to.be(a)seen.com> wrote in message > news:ht3pie$ncb$2(a)speranza.aioe.org... >> You developed this in-house? Why not use something off-the-shelf? >> (OTOH, most OTS solutions force you to do business "their way") > > I've wondered the same thing, Don (see, there, I got your name correct Actually, it's *Bob*... ;-) > :-) ) -- but I've now worked at two small companies that spent more than > three years trying to get expensive commercial MRP systems fully > deployed without success (...company #1 went belly-up, company #2 is > still working on it), so I give John a lot of credit for solving the > problem himself and just getting on with the core part of his business > -- design engineering. I worked at one (small-ish) firm *when* MRP was deployed. The most important aspect of the roll-out was getting everyone onboard -- everyone in the company "went to school" to understand the issues involved. > The only small company I've worked for that had their MRP system "under > control" was using Greapt Plains (now Microsoft Dynamics). No one > really liked it, but it did at least get the job done. 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. 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. 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.). 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.
From: Joel Koltner on 20 May 2010 14:35
"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. ---Joel |