Absolutes and Assumptions
In the past, I’ve said the final responsibility for good programming rests with management. True, but it’s time for a different question: Is bad code simply lack of professionalism?
Fifty years ago this summer, I began programming as an intern. That September, I got my first job. I had plenty of quality guidance, but no one ever examined my work in detail.
I don’t think it needed close scrutiny. I like to think that was because I worked hard at becoming a professional. I took the opportunity seriously and constantly tried to learn and improve.
Seeing the quality of work out there now, including major software companies, I wonder if many programmers aspire to professional excellence. Or care. Or even know what it means.
How does this relate to the title of this post? Programmers who use absolute references or make unwarranted assumptions cannot be considered, in my opinion, to be professionals.
Assembly language taught me never to make absolute jumps; i.e., don’t move a fixed number of bytes or instructions. All jumps had to reference labels, a place with a name. These jumps were always valid, even if the intervening instructions changed.
The last post talked of moving to a new operating system. More than half the software I’m installing has windows that don’t fit on the screen—regardless of the resolution. This is also true for operating system components. (Are you listening Microsoft?)
After all these years, I still see messages disappear before they can be read. If it’s important enough to display, then the coder must make sure it can be seen (or stored to be read later).
Bad windows and flash messages reveal wrong assumptions. Microsoft’s Object Linking and Embedding (OBE) still uses absolute paths. We knew better fifty years ago. What happened?