|
|
|
|
|
by kabdib
3557 days ago
|
|
I've had long turnarounds (other than the artificial punchcard hell that is really just economics surfaced by IT budgets) in many projects. The ones that come to mind: - Burning EPROMs for the hardware bring-up of a consumer 68000 machine. Download and burn time for six EPROMs was well over 45 minutes. Things got better when we wrote a downloader, but initial bring-up was kind of painful for a couple of months. - An unbelievably crappy and development-hostile environment for set-top boxes. Getting 900K of code to a device could take 20-30 minutes, and the transfers often just abjectly failed. "Working as designed" said the people running the head-end. If you wonder why set-top-box software sucks so hard, this is one of the reasons. The whole TV industry is a fractal of shitty practices. Not that I'm bitter. [I did a work-around that let us do dynamic code loading over a different pipe that we theoretically weren't supposed to use "for network stability purposes" and got a biiig bonus after our team's productivity went way up] - Game development using a cross-assembler on a minicomputer,. The mini was also used as the department's email and office memo system. 45 minutes during the day turned into less than 5 minutes at night, so you can imagine the hours I kept. - Working on some Windows internals, the less said about this, the better. The common thread: When bad decisions and designs were institutionalized, things never got better. When it was possible for individuals to improve things, they did. |
|