Software bloat (Larkin was right)
in [Design]
|
Prev: OrCad/ question
Next: Capture hierarchy
From: Michael A. Terrell on 20 May 2010 15:28 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. :( -- 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 16:19 Hi Joel, 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. This extends far beyond just MRP systems. I am always amused when I hear some gung-ho accountant excited (as he heads off to "school") about the new computerized accounting system his company is buying. I politely and gently tell them they're going to have problems making it FIT their business, etc. I always get the "Oh, no! We looked at a whole bunch of them. We sat down with the sales rep and reviewed our accounting model, verified it would work in their framework, etc. (Don, you just don't understand *accounting*! Trust me, we KNOW it will work)" Then, a few months *after* the 6 month start-up phase, they inevitably come out grumbling about how it "doesn't do things right". I then (gently -- remember, *I* don't understand ACCOUNTING! :> ) innocently ask them, "You mean, it *can't* do ________________? <shocked>" "Oh, no. It'll *do* it. It just doesn't do it the way *we* do!" (At which point, I wish I could play back an audio recording of the initial conversation I had re; this exact issue!) >> 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. But, my point is, those limits were created by the wrong-placed ideas of the implementors. They looked at query speed, how long it took to create reports, etc. and said "My, that's just too slow! We'll have to cut some corners to speed it up!". Instead, they should have looked at the role of the system in the organization. Not just from the perspective of the guy running the reports, etc. It's like when bean counters decide how data should be organized... they think about what *they* need from the data and don't consider the data model as an abstraction that others relate to as well (e.g., how the data gets *into* the system, 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.). > > 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. Exactly. The place where I watched it "come in" had to deal with stupid, *naive* descriptions. So, sometimes it was a: 1K ohm resistor fixed 1K R 1000 Res. 1K resistor etc. So, the MRP system itself was "stupid" -- you *couldn't* find things in it unless you forced all descriptions to be consistent, etc. (this is what they eventually did -- had *one* person responsible for entering new data) >> 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. Exactly. This is an outgrowth of people wanting to be able to manage the data "in their heads". Or, clinging to "that's how we've ALWAYS done it". I worked for a large (hand) tool manufacturer when I was a kid. I had an interview with one of the big muck-a-mucks (I think this was one of those "create a job for this kid" deal -- the gentleman was from my alma mater). Very informal. I think he just wanted to "chat with the youngster" :> He asked me how to *design* a part numbering system (keep in mind, the company probably had 100,000 or more part numbers at the time -- SWAG). I came up with the (uninspired) solution "first digit(s) indicate the type of tool..." etc. I.e., encode information about the part in the P/N. Conversely, let the part determine its P/N! He smiled ("silly boy"...). "So, screwdrivers would be '1xxxx', hammers '2xxxx', pliers '3xxxx', etc.?" "Yes." "OK, so where do we put *electric* screwdrivers?" "Well, you could lump those things in '9xxxx'!" Without the smile leaving his face, he opened his desk drawer and pulled out a tool that was a screwdriver, hammer, pliers and hacksaw all-in-one (I don't recall exactly what it was; but, it was *really* weird -- remember, this is where they *invent* the tools) and said, "How about *this*?" Now the smile is a broad grin. "Don, what you will quickly realize is EVERYTHING ends up in the '9xxxx' category! The only rational way of assigning numbers to parts is *sequentially*!" The important lesson there was not that "part numbers should be insignificant" but, rather, that you need to think through what you are doing -- and why. If you want the number to be significant (why? so you can fabricate it in your head without having to look it up??), then *will* it ALWAYS be significant? Or, will there be exceptions that effectively render your "system" useless -- because you'll never be able to keep track of what the "exceptions" are... so, you WILL have to "look things up". You can *make* these approaches work. But, if you are honest with yourself, you have to admit that your initial goal is not being satisfied. (and, what do you do if someone else creates P/N's using some different system? i.e., you are better served to have a good *lookup* system than to waste effort trying to enforce structure on "numbers") >> 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. I do that with "documents" -- though usually just the date is sufficient (since documents don't get released that often WITHIN A DAY). I don't do it with software, though. I've been bitten by clock errors from one machine to the next, etc. (before I had NTP server running). So, I would look at some code weeks later and see "version Y" stamped with a date previous to "version X". Now, I just keep a "VERSION" file in the repository and include that in each build (makefile does this). That way, it doesn't matter which machine I am using to build the image (since the VERSION file is in the same place as the sources). If I ever get a second seat for my DTP tools, I will probably have to use a similar approach (currently, there is no issue with clock skew as there is only one DTP seat!)
From: John Larkin on 20 May 2010 16:58 On Thu, 20 May 2010 10:02:00 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: >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") We tested some commercial packages and didn't like them. They clearly didn't understand the electronics business, were slow (usually sat on 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. 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. John
From: John Larkin on 20 May 2010 17:10 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. 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
From: Michael A. Terrell on 20 May 2010 21:40
John Larkin wrote: > > On Thu, 20 May 2010 10:02:00 -0700, D Yuniskis > <not.going.to.be(a)seen.com> wrote: > > >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") > > We tested some commercial packages and didn't like them. They clearly > didn't understand the electronics business, were slow (usually sat on > 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. > > 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. Did she use a whip and a chair, or a pistol? ;-) -- Anyone wanting to run for any political office in the US should have to have a DD214, and a honorable discharge. |