What Compsci textbooks don't tell you: Real world code sucks There’s a kind of cognitive dissonance in most people who’ve moved from the academic study of computer science to a job as a real-world software developer. The conflict lies in the fact that, whereas nearly every sample program in every textbook is a perfect and well-thought-out specimen, virtually no software out in the wild is …
Some years ago I was working with two others on a monitoring system for an ISP. It was a fairly major endeavour intended to
One of my colleages developed the subsystems which collected netflow data, crunched it down and put into a database for analysis and graphing for well over a year, and he went off sick and it looked like he wasn't coming back.
Our manager asked me how long it would take to pick up his work and I said I didn't know, I had specific APIs and data dictionaries but no knowledge of his code at all, so we agreed that I would look into his code and report back in a week's time how long it would take. The next week's meeting didn't take place, so a fortnight later we sat down to review it.
The Manager asked how well I'd picked up my colleague's work, and I said I hadn't, that I'd only agreed to work out how long it would take to get up to speed with his work. Manager tried to rewrite history but I stood firm! I was finally asked how long before I could start on the bug fixes and new features, and when I said about two months, he was aghast! I had to remind him that this was a complex system written by people who'd never worked on this kind of thing having spent months prototyping and experimenting.
Fortunately by the time I was expected to do something useful with my colleague's code he came back to work. I knew his code was a terrible mess so was very relieved.
Nearly six months later there was a big purge and we were "let go" despite being the only people who really understood how it all hung together. I heard that the people redeployed onto our project quickly turned it into a bug-ridden unstable mess in trying to add all the version 2 features and never got it to work properly.
In a typical semiconductor firm, test engineers code device tests to be performed on automatic systems 24/7, by non-engineer production operators at various worldwide locations. In our firm each test project can be subject to a random audit after release to production. The auditor inspects the code down to specific commands, and expects that the code is clear enough and well-commented enough for a disinterested engineer to understand and master it in reasonable time. Any exceptions to this rule are flagged in a written report to the test developer(s) and management. These exceptions are reviewed and can be challenged by the developer(s), but when found valid they may be noted on the next performance review. The experiences described in the article are typical for companies that don't have a clear accountability process for developers. In our case, we like to be profitable, and don't welcome test engineers who put ego above production-worthy project outcomes. (This is industry, not creative programming class.)
comments are just smelly crap that will not be maintained. I lose count of the number of times I've found comments that are out of date or just plain wrong. Plus they are localised, a useful comment in one locale is nonsense in another even in the same language.
Write succint, well-encapsulated code that makes good use of interfaces. Oh and some of you are talking about tests? Don't even get me started on writing tests. Every unit test failure I have ever looked into has resulted in me having to CHANGE THE TEST.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
