variable

Sorry, I just have to share this because it is so relevant.

Just to illustrate the "maintenance nightmare" issue using an example, and this is literally an issue I was asked to help with today coincidentally...

A client of mine who will remain nameless, is a "device" manufacturer. Their high-end parts are big and complex, having embedded CPU(s) and BGA packages with pin (ball) counts as high as 1704. The databook for this device is around 2000 pages. The databook contains pinout tables for 256, 456, 672, 676, 896, 1148, 1152, 1517, 1696, and 1704 pins (some pins missing in an otherwise regular "row" by "column" pin array). Some poor documentation fellow has to take the "source" package/pinout text documents output early in the IC design and packaging engineering process and verify BY HAND/EYEBALL that the PDF databook pinout tables match. For the big packages, these tables are upwards of 48 pages! Well guess what? A pin got dropped somewhere along the way in the databook creation process and a customer caught it. Oops. There you go. Now that's and error-prone maintenance nightmare! The documentation fellow has a remarkable attention to detail and ability to focus, but he's only human after all. He also gets to recheck all the other tables to verify that nothing has changed if there's an edit performed to another table.

So what we do is use those marvelous text processing software tools my forefathers created for me, write a surprisingly simple script (program) to parse out the pins from the the engineering source document and the PDF (or from old PDF and new PDF), process one against the other looking for inconsistencies, and BAM! that poor fellow's hair starts growing back in.

The moral of the story is that there is usually a way to make a complex problem simpler using the right tools. Since you are not likely to be the first one to encounter your complex problem or something very similar to it, there's a good chance that a tool exists to help you.

Sorry, I just have to share this because it is so relevant.

Just to illustrate the "maintenance nightmare" issue using an example, and this is literally an issue I was asked to help with today coincidentally...

A client of mine who will remain nameless, is a "device" manufacturer. Their high-end parts are big and complex, having embedded CPU(s) and BGA packages with pin (ball) counts as high as 1704. The databook for this device is around 2000 pages. The databook contains pinout tables for 256, 456, 672, 676, 896, 1148, 1152, 1517, 1696, and 1704 pins (some pins missing in an otherwise regular "row" by "column" pin array). Some poor documentation fellow has to take the "source" package/pinout text documents output early in the IC design and packaging engineering process and verify BY HAND/EYEBALL that the PDF databook pinout tables match. For the big packages, these tables are upwards of 48 pages! Well guess what? A pin got dropped somewhere along the way in the databook creation process and a customer caught it. Oops. There you go. Now that's and error-prone maintenance nightmare! The documentation fellow has a remarkable attention to detail and ability to focus, but he's only human after all. He also gets to recheck all the other tables to verify that nothing has changed if there's an edit performed to another table.

So what we do is use those marvelous text processing software tools my forefathers created for me, write a surprisingly simple script (program) to parse out the pins from the the engineering source document and the PDF (or from old PDF and new PDF), process one against the other looking for inconsistencies, and BAM! that poor fellow's hair starts growing back in.

The moral of the story is that there is usually a way to make a complex problem simpler using the right tools. Since you are not likely to be the first one to encounter your complex problem or something very similar to it, there's a good chance that a tool exists to help you.