Programming error created billion-dollar mistake that made the coder ... a hero? Ah, dear readers, welcome once again to Who, Me? in which Reg readers confess the times their reach exceeded their grasp, technology-wise-speaking. This time meet "Francis" who was a bright young thing working on contract as a programmer to a largish organisation that was in the process of upgrading certain systems. Despite …
At a small on site lab, we had a centrifuge that was fitted with a head rated for half the maximum RPM the base unit could deliver. I pointed out that it should probably be hard locked to prevent settings beyond the head rating and even pulled up a manual showing how it could be done. This was left with the lead maintenance technician before I took a much needed holiday.
When I returned, there was a shiny new centrifuge in its place. Apparently, the technician had verified that the centrifuge could indeed be set higher but had then gone off to track down that pesky manual. In the mean time, a sample had been run and the head unit gave way. Fortunately, the shell contained the chunks but it apparently made quite a bang.
In my younger days my employer used a big-ass centrifuge to dry out acetyl salicylic acid in mass.
It had a diameter of 4m, all stainless steel, and was quite heavy.
I would not like to be near that thing should its governor decide to pack up and allow it to overspeed out of control....
Apparently[1], you could learn the history of experimental hardware, particularly the centrifuges, by reading the scars in the walls of the university basement lab: note how the 4 cm deep gash bisects that strange chemical stain...
[1] "apparently" 'cos I never went down to look - mad science is scarey!
I once rescued a trainee who had been backed into a corner by a rampaging centrifuge into which she had placed only one tube (NB my pet TV peeve is people only putting one tube in a centrifuge then not having to chase the beast across the lab.(my second pet peeve are these "naked" centrifuges -- yes I know they're cinematic, but they'd been phased out before Queen's College became Dundee University)). I could reached the power switch and just flipped it off...
--> labcoat
> I could reached the power switch and just flipped it off...
Something is just not quite right about that sentence.
Do we read it as "I could (and did) reach the power switch" OR "I could have reached the power switch (but was having too much fun laughing)".
Given the general attitudes of El Reg commentards, do we think John 110 was more likely to have been a gentlemanly hero or...?
"W0t? You don’t have a self balancing centrifuge?"
Not in 1973 we didn't. It was another 5 years before we had centrifuges that you couldn't open while they were spinning.
(NOTE: The preferred method for bringing a slowing a centrifuge to a full stop back then was to press a rubber pipette teat onto the hub. Not recommended if you want the buffy coat.)
I worked in a refinery and we did "lock out tag out". You had a brass name tag that fit on a pad lock. You used said pad lock to loch machinery in the "off" position. Thereby preventing an intense emotional events in the form of electrocutions or being sucked into large moving machinery. So if working on a system, lock it out because Mr. Murphy.
As a kid we lived next to a 'stately' home with 700 acres of woodland with its own sawmill - lovely old thing all belts and widgets and a 6' diameter saw blade that seemed to take forever to get up to an enormous speed. One day the blade decided to go for a walk and sheered off. It managed to get several hundred yards uphill through densely wooded rugged initially like a knife through butter and then after it struck some rocks and became unstable or bent it just shredded everything in its path for a couple of hundred yards. Its one of the few reasons I'd not advise using rotating masses as energy storage devices!
Well, even one used as a *data* storage device stores energy as a byproduct.
I heard a story 45ish years ago, from what were even then the old days, about just such an occurrence. It seems a multiple-foot-wide disk drive platter broke free of its moorings, and even without teeth it sliced through the drive enclosure and kept going. I wish I could remember more details.
I recall that tale - as a gap year job I started my computing experience at Harwell, and, as an early morning arrival, along with switching on the kettle, I had to turn on the vertical winchester disk as it took 20 mins(?) to get up to speed, before I loaded the paper tape system bootstrap. I was told to run like hell if the disk started making noises...
I heard of one steam turbine in South Africa where the blades decided to leave the building and get encrusted 3m deep into concrete columns.
Considering they were something in the 2 - 5m width range and were spinning at exactly 3000 rpm, their mass was just a multiplier.
When I started on the drawing board at a large steam turbine manufacturing company in 1974, my first assignment was to lay out the installation of a blade wheel in the vacuum overspeed chamber. About a year later, we were all busy at our boards when there was a loud bang and the whole building began shaking, as if we were in an earthquake.
After a while, the shaking slowed down and eventually stopped, during which time most of the inhabitants of the office block had exited and were milling around in the car park. My Boss, one Tom Heath, poked his head round the doorframe and said "That's one of your jobs, Iain, please get me drawing XXXXXXX and bring it into my office". With much fear and trembling I retrieved the drawing from the filing system and trudged reluctantly towards my doom.
We pored over the drawing, recalculating every dimension, stress calculation, and instruction, after which Tom said that he couldn't see anything wrong, perhaps we should go down and inspect the corpse. On arrival on the shop floor, we found that the overspeed chamber had been opened, and its contents were being shovelled out onto a portable workbench for examination. The Foreman was standing by with his arms folded across his chest, his foot tapping, and a face like thunder.
Tom searched through the metallic scrap on the table and suddenly his hand shot out and grabbed a mis-shaped bolt head. He showed it to me and asked "What do you think that is?". I replied that it appeared to be the head of a 3/4 inch black mild steel bolt, which was displaying a textbook cup and cone tensile failure on its underside. Tom unrolled the drawing over the scrap and pointed to a legend which called for 3/4 inch High Tensile bolts to be fitted.
The Foreman suddenly defated like a punctured baloon, and his face went an unhealthy grey colour. "Oh! Shit!" he exclaimed, as the realisation that the failure was down to him and not us, and that he would therefor be footing the bill for a new blade wheel, shaft, instrumentation, and radio communications equipment, all of which had been destroyed by the failure of the drive bracket counterweight.
Tom rolled the drawing up, tapped me on the shoulder with it, and said "Time for a cuppa, I think". We walked away across the shop floor, leaving the Foreman standing dejectedly beside the ruined chamber.
(PS, as well as Tom Heath, we also had a Ted Jones on the section, at a time when Ted Heath was PM and Tom Jones was big in the charts).
... was the one I wrote half a year ago. More or less. It happens less often as I got better. I think it is mostly ok now, except for the bits of code that I know I should have written differently and not under pressure, and I definitely should revise the code rather sooner than later.
I learned a long time ago: if the bug is so obscure that the only possible explanation is that the compiler is generating bad code, well, that just means I've done something *really* dumb.
(Except, of course, for the two or three times in a long career when the compiler really was generating bad code, or the moral equivalent in an interpreted language.)
OP did say "two or three times".
I've found a compiler bug or two m'self, and a number of errors in language-implementation and third-party libraries. But I too have learned to assume it's my error first, and then when I can't find it, assume it's still my error and I just haven't looked hard enough. Only then try to reproduce the problem in some other way to show it's probably not my code.
One C library bug I identified many years ago I demonstrated by instrumenting the large software package that originally showed the problem to log its malloc/realloc/free operations; then I wrote a script that converted the log into C code that just duplicated those operations, after validating them for obvious errors like invalid realloc and duplicate-free. When that program reproduced the problem, I cut it down by bisection until I had a minimal reproduction, which turned out to require only 16 mallocs and 3 frees in a particular pattern.
I used a little USB board that could be hooked up with a PC floppy drive to recover some Amiga formatted disks. These held source code I had written a very long time ago including an unpublished game and a couple of published games that ended up on magazine cover disks.
When I looked at the source I was actually surprised that the code wasn't completely abysmal - it was pretty legible for the most part and I could follow it even though it was invoking Amiga APIs. But I was shocked by how few comments there were in it compared to how many I write now. One of the games had a lot of vector geometry going on in it and it was almost impossible to figure out what was going on without any comments.
almost impossible to figure out what was going on without any comments
One of mine is currently "doing Python" in GCSE Computer Science. I've been impressed with how well it's been picked up, though of course I still get the occasional "hey dad, what have I done wrong here?".
But they haven't been told how (or why) to comment code. Everything written so far is almost completely comment-free. Granted, most of it is self-explanatory at the moment, but a few well-placed comments inserted now would get them into good habits for later methinks.
I have a similar gripe about keyboard skills. Nobody seems to teach "touch typing", despite the fact that most (all?) school leavers will be going in to jobs where typing is a major part of their daily lives. Recipe for RSI, carpal tunnel problems and the like.
M.
That was the problem I had when learning to code. My dad (a university lecturer) taught me first in Pascal, then in C and always expressed the need for comments. As the code I was working on originally was so simple and self-explanatory, plus each exercise was pretty-much standalone, it seemed pointless to me adding comments that explained code which was simple and obvious, and which I had never needed to refer back to so far.
Of course over time, the code steadily becomes more complex as I learnt new commands/functions and more advanced algorithms and techniques. Then we get onto the topic of reusing code when tackling a challenge that is similar to some code I'd written a month or two earlier. Being faced with a fairly complex algorithm and zero comments suddenly made me understand why comments are so useful.
These days I probably end up over-using them if I'm honest, but it doesn't half help when I rip-off some of my old code from previous years.
Then we get onto the topic of reusing code when tackling a challenge that is similar to some code I'd written a month or two earlier. Being faced with a fairly complex algorithm and zero comments suddenly made me understand why comments are so useful. ... Dave K
Would anyone else/many more agree that such is very true here on El Reg which makes the exercising of fairly complex algorithms here invaluable, and indeed much appreciated. It is a service par excellence.
Some years back I landed a job at a large event-management outfit. The role was on a greenfield project which had been running for a year or so, being built by a sizable 3rd-party systems provider. I was entrusted to the care of 'Ada' (for that was not her name) who was a hotshot contractor assigned by the aforementioned provider who had been on the project since its inception. They were in the process of handing-over to internal staff, of which there were few - I was a new hire to beef-up the crew.
After the usual corporate-standard fortnight of sitting around waiting for a desk, a laptop, email and security permissions setup, etc. I was finally given my 'intro to the system' session by Ada. Neither of us expected this to take long - she knew the code well, and I've been getting paid to write code for 30+ years. She walked me through the repo, pulled the source, and showed me some of the code she and her associates had created.
I noticed a distinct lack of comments. As in, zero. Not one, in any source file, about anything, no matter where in the object model we were or how specialised the business logic seemed to be. Nothing at all to give even a hint of what the oftentimes-complex code did, or why it did it, or when. I made an observation to Ada, indicating my surprise. Her reply, drawn from her vast well of commercial experience (2 years out of Uni and in her first contract placement) chilled my blood.
"Comments are a code-smell."
I resigned that day.
It depends. I usually have no problem reading other people’s code without comments in Java when I see a system for the first time provided it is well written. The average C code on the other hand is usually written in a way that requires comments.
But some people’s code is very difficult to read even if it is full of comments in any language.
I did experiment with writing code in HTML documents so the code was in between verbose comments and yet the build process stripped out all but the code before running make. Some editors now can call a URL so you can just add a URL in the code comments to take you to the bit in the documentation related to the following code. I still feel there is some option for hypertext in code so documentation (from sketching out the projects to completion) allows easy jumping to the right documentation is worth exploring but teaching old dogs new tricks is often counter-productive.
I know of plenty of algorithms that are very difficult for a maintainer to understand without additional explanation, even when implemented cleanly in a language with ample abstractions. Individual function points may be relatively easy to grasp, but understanding what they do in concert may not be.
I've read the arguments for "comments are a code smell", and it's an interesting philosophical proposition, but it utterly fails in practice.
The arguments are that code which isn't comprehensible itself needs to be refactored, and that comments don't get updated during maintenance (or even during initial development) and so you get skew between code and comments. More generally, it's that having different documents for different audiences – code and comments for developers, and just code for machines – increases the likelihood of error.
While these are all points with some validity, in the real world, there is always code which is too complex to be sure maintainers will divine its intention, regardless of how well it's structured; failure to update comments should be fixed by process, including code reviews; and humans can't perfectly emulate machines when reading code anyway.
"Comments are a code smell" is a sophomorism, the sort of reductive thinking you get from people who have some experience but not enough, and so still believe in elegant solutions to irreducibly complicated problems.
I learned the hard way. Coming from BASIC on a 32K micro, there were no comments as comments took space and execution time.
I started writing C like that.
Until I came back to revise a project several years later and eventually figured that rewriting chunks rather than try to figure out what was actually going on would be a quicker solution.
Gone are the short 1-2 letter variable names, and hello lots of commenting. It'll help down the line, especially if something is being done in an unusual way and you leave a note to explain why.
When I was doing some particularly involved kernel mode code on a VAX, I ended up with approximately a 80x24 screenful of comments per line of code. I also had a preface explaining what the code was meant to do, why a particular approach had been taken, and why other 'obvious' approaches had not been chosen, with links to extensive documentation elsewhere. When you are doing counter-intuitive stuff, you have to work hard to prevent other people making 'obvious' simplifications to improve what 'some idiot' (including previous versions of myself) has written.
I was working on early UNIX (pre-BSD) at Berkeley when one of the professors bellyached at me for including too many comments, as in his opinion it wasted paper.
"Yeah, well, get me a glass tty and I'll stop using the '33 ... "
I had a second-hand VT52 on my desk the following morning. JOY! :-)
The very same professor still demanded weekly dead-tree printouts. Naturally.
"I was working on early UNIX (pre-BSD) at Berkeley when one of the professors bellyached at me for including too many comments, as in his opinion it wasted paper."
Clearly the massive capital expenditure on the computer wasn't his problem, but looking after the pennies worth of paper coming directly from his budget was a huge concern :-)
In a previous life when I was doing more embedded work, I butted heads with a fresh-from-University co-worker who resisted my suggestion to replace the binary-on-the-wire protocol he was struggling to implement with a text-based one.
His reasoning was that everyone knows how slow it is to parse text and it needed to be binary for efficiency.
So instead of being able to sniff the traffic and dump it for his viewing using a terminal program which he already had, he had complicated the task of not only writing both ends of a new protocol, but using those same pieces to write a decoder to make the protocol human readable.
The problem he was running into was that as both ends were still being developed, the decoder itself was also being developed; he was verifying the tools with the same code that was in the tools themselves.
There are times when every cycle counts, but this wasn't one of them. This was two microcontrollers exchanging messages of 100 bytes or less, several times a second, and doing little else aside from busy waiting. I told him there was no bonus check to be had for having the microcontrollers sitting idle 70% of the time rather than 50% of the time.
I asked him to prove how inefficient parsing the text would be and asked: "Who's time is more valuable; you or the computer?" It's a mantra I still chant...
"Gone are the short 1-2 letter variable names, and hello lots of commenting. It'll help down the line"
Have an upvote just for the elimination of short variable names. That's one of the ways of making code illegible that I hate most. I remember one occasion vividly where this was a problem. I generally like Python as a language if performance isn't critical because it is often readable, or at least I think it is when I'm writing it. However, they have one syntactic mechanism I'd like to see stripped out. When importing things from other modules, you can rename it to something shorter. I had the misfortune to find a codebase where they decided to rename every external resource with a two-character name and then use more two-character names for all their variables, leading to lines like this:
if not (ri.open(fx, fn, enc(lt[xu:xv]), os.path.join(cd, n)):
This code wasn't even a normal program or script, but was operating some hardware over a serial link to a microcontroller that had a restricted set of communications. Instead of writing something to handle that protocol abstractly, they built error checking into everything they ran based on the serial error codes which were sometimes based on the command you just sent and sometimes not. Making any productive changes to this took a lot longer than other projects I had.
I hate it when people take that too far and insist on long names even for throwaway index counters in a for loop. Nothing wrong with using i & j for those if the loop is simple and the values are not used outside of it. Plus you end up with equally useless but now overly wordy variable names like "loop_counter".
It is annoying to see something like "loop_counter1" and "loop_counter2" leading to overly long lines when you have code that requires referencing those variables multiple times on each side of an assignment or comparison statement!
But yes for variables with context across a function that's longer than a page (including header & comments) and absolutely always for global variables, they need to have names chosen carefully. Not just 'longer' though, otherwise you aren't gaining anything by changing a variable called "pp" to "position_pointer". Position of what? Pointer meaning it is a C pointer, or pointer meaning it is an index into an array 'pointing' to a particular position?
No matter what coding standards you set up, people who don't engage their brains will manage to render it useless.
I remember the days of the original BASIC (I actually wrote the precursor for BASIC on the LGP-30). The reason for the short names was that then all variables could be permanently assigned to a storage location (26 for A-Z, and 260 for A0-Z9). It sped things up and was easy to understand and required less code. Now with more than 6K of words (pre-byte) of memory, faster processors etc. there is no reason for requiring short identifiers.
Related:
You start to run into similar issues with modern (but low specced) microcontrollers.
Not with variable names, but with strings.
If you declare a string literal to be written out over serial, (e.g. "Program got to here"™), the whole thing is written into ram before passing it on. When your dealing with 2k of RAM and no GC, a program that has lots of nice feedback soon fills up the available RAM. A trap for younger players, as it were.
The solution is to copy the string from flash/rom/progmem (which is usually in much greater supply). In the Arduino ecosystem, you have an F macro - so the above becomes:
serial.println(F("Program got to here"));
Many years ago I was involved in developing - from first principles - an item of test equipment. The bloke in charge was a hot shot analogue engineer and knew the type of equipment backwards. Practically everything else was left up to muggins, who was on a sandwich year from a degree in E&EE, knew which end of a 74LS04 was which (but little else), had programmed in BBC BASIC, Pascal, 6502 assembly, ARM assembly and about 6 weeks combined C, 6809 and Modula-2. Yup, team of two plus one part-time whose real job was elsewhere in the factory.
I designed and built a hand-held computer system built around Intel MCS96 parts (learning its assembly language from scratch) and knowing absolutely nothing about anything made a lot of design errors which weren't fatal, but of the "if I'd known then what I know now..." variety. The two chief ones were crafting my own integer division routine using - literally - repeated subtraction (how slow was that?) and the text messages / serial protocol issue described above.
I'd managed to squeeze space for 24k of ROM in to the 64k memory map, but some ridiculous amount - maybe 8k or more of that - was taken up with stuff that was to be displayed on the screen, menus, error warnings, status messages and the like. There was not much room left, especially once we worked out I needed a floating point routine and had to import a bulky (this is Intel, after all) FP library. And the serial protocol was essentially shoving a CSV file (or, at least, what I thought was a CSV file without any kind of reference other than playing with an ancient spreadsheet) over the link and hoping for the best. Listen, the internet didn't exist and the sorts of computer magazines sold in newsagents didn't cover that sort of thing.
After 13 months of this we had three working prototypes of varying utility (designed to be sold at separate price points) but I had to head back for my final year, so another student was brought in and I have no idea how much further the project went. I hope it didn't die because of silly things I'd done, but it did give me an awful lot of "well, I won't do it that way again!" experience.
M.
There's a very dangerous trait to consider comments a "code smell" and to remove them because "good code should be self-commenting".
I don't hold with that. Good code has good comments, and the comments act as signposts. They're your guides, especially in those fraught times when Something Has Gone Horribly Wrong and you're rooting desperately in code while They Who Must Be Obeyed are standing behind you, tutting, and calculating how much this is costing the company every second it's not working.
Icon because I think we all need it after the PTSD trigger I've just dropped.
Agree. Comments in code shouldn't cover the "how" as much as the "why". The code should, usually, show "how", but the "why" is often much more complicated.
Good variable naming helps a Great Deal, too. I find myself refactoring variable and method names all the time.
Definitely, variable and function naming is critical.
I feel that this is one are where coming from a writing background gives me an advantage. When we write code, we are writing it to be read by both humans and computers. The difference is, computers just need to know what to do; they don't need to understand why they are doing it. Variable/function names and comments are like a backchannel for just humans, a place to discuss issues that do not concern the computer.
Only those who think "agile means no design" think "code is self commenting": they've never worked on a system with some "proper" business requirements where the only sensible reaction is "WTF", but you still have the implement them.
To quote Refactoring:
Don’t worry, we aren’t saying that people shouldn’t write comments. In our olfactory analogy, comments aren’t a bad smell; indeed they are a sweet smell. The reason we mention comments here is that comments are often used as a deodorant. It’s surprising how often you look at thickly commented code and notice that the comments are there because the code is bad.
And then expands on this, including that extracting the code into multiple functions, even if they need long names (naming sections of code really helps, languages with local functions are particularly useful here), significantly reduces – but does not eliminate – the need for comments.
Agreed. I agree having the "#This adds 7 to x", then the next line of code is "x=x+7", that type comment is useless. But, having a comment *why* you are adding 7, where x came from, and what x (with 7 added) is going to be used for later (unless x was just used within a few dozen lines of code maybe) would be good. (And obviously I'd give the variable a bettter name than "x".)
I have plenty of code that is self-documenting, insofar as you can look at it and figure out *what* it's doing. But, why is it doing it? If it's either a modern "microservice", or a function in a larger program, or just a code fragment, what does it do for the larger program (or whatever you call a collection of microservices actually getitng soething done?) For instance, I have "time.sleep(0.1)" in a program. It's clear that sleeps 1/10th of a second, sure that's self-documenting. But without a comment you'd have no way to know that because the web site it accesses has a 10 hits a second fair use limit, and although the program usually hits the site far less frequently than that, it ensures back-to-back-to-back hits (which may happen occasionally) will never violate the fair use limit.
Yes the "adds 7 to x" is the perfect example of how people can defeat any well intentioned coding standard. I've seen code where every single line is preceded by a comment, explaining what the line does but nothing about why it is doing that or giving you any clue about the overall intent of a particular function - you get a function called "compute_checksum" and the comment will say "this function computes the checksum". Of what? For what reason? Using what checksum scheme, etc. etc.
This is the kind of case where comments are critical. "This operation seems backwards because against version 1.2 of the frobsticate library the order of parameters is the opposite of what logic would indicate" is absolutely the kind of knowledge that I would forget in the six months before I next looked at that part of the code or a new programmer coming onto the project would need to know.
How can you possibly make Not-Good-Code self-commenting?
Anyone (un)lucky enough to read my code will soon come across a comment that begins /*Wibble: ... */ which then goes on to indicate how this "could be done better" if there ever was the need (or you just have too much time on your hands).
For example "this does a linear scan through an array of strings 'cos it is one function call to do so and only gets called once per week; if this ever shows up over 1% of execution time in a profile run then the best thing is to use this search tree module that is already being linked into the app from over there."
I.e. I know it isn't perfect, today it doesn't need to be, it just needs to work - and, yes, I did consider the alternatives.
(The sub-optimal code is also self-commenting to the how and commented to the why as well, of course. Cough.)
Even a lot of good code isn't self-commenting. If you read a nice, clean implementation of Paxos with no comments, would you know its intent or understand the reasoning behind the algorithm? I'd be even many people familiar with the algorithm would need to spend significant time figuring out just what each piece did.
"Nobody seems to teach "touch typing", despite the fact that most (all?) school leavers will be going in to jobs where typing is a major part of their daily lives."
Here in Switzerland, kids are being taught touch typing starting in 4th grade (approx 9-10 yrs). Part of the mark given for German (or, I guess, French / Italian in the respective cantons) used to be given for neatness and clarity in handwriting, and that part has now been split in 2 with half the marks for handwriting and half for typing. I believe it's something quite new introduced in last year or 2, but it certainly seems focused on new realities. Useful skill to learn although to be honest I wouldn't put it as part of the grades.
My experience with self-learnt typing is that there is little to be gained in speed and accuracy by looking at the screen as opposed to looking at the keyboard. Just as someone touch-typing while looking at the keyboard knows what their fingers are doing on which keys without looking at the keyboard, I know what's appearing on the screen even while I'm looking at the keyboard because I know exactly what the result will be of all the keys I've pressed.
Far more importantly, kids need to be be taught to know WHAT to type, otherwise they're just very fast at producing rubbish prose or error-strewn code.
I know what's appearing on the screen even while I'm looking at the keyboard because I know exactly what the result will be of all the keys I've pressed.
No, you don't. If you're typing at any decent speed, looking at the keyboard doesn't let you know about accidentally double-struck letters, letter inversions, or skipped characters. That's why I look at my screen.
I don't know about your experiences, but I do know it's impossible to know exactly what happened just by knowing what keys you pressed. You can't be 100.0000% sure that the keyboard didn't accidentally swallow your key press (I have one where the S key doesn't always work unless you press it straight on, for example, and probably requires a cleaning). Or you could have a laptop with that annoying trackpoint in the middle of the keyboard (I know some of you like it, but I don't) or a trackpad that interpreted your palms as fingers and moved your focus. This doesn't mean you have to look at the screen, but it means that typos will remain a possibility either way.
Last time I did a typing speed test (with real words, not random characters) I clocked at over 80 words per minute. But I **HAVE** to be looking at the screen to catch all the mistakes! Many I can tell by feel - oops, hit two keys at once, so backspace twice and repeat, but some I'm not positive exactly what happened without looking at the screen.
I was about to type "Ironically, none of this happened in this comment", when I apparently didn't push the "I" quite hard enough. My finger says I did, but computer said no.
Looking for a fill-in job having finished university, my attention was drawn to a data-entry job at a local high-tech engineering firm. I applied via the job centre, who had to work hard to persuade the firm to consider me, and even then insisted that before being interviewed I had to make a trip to nearest Big City for a typing test as I didn't have any formal typing qualifications.
You can guess where this story is going. I passed the test with flying colours. In fact the person administering the test said it was the best performance they'd had all week even from school leavers who had typing / secretarial qualifications galore - perhaps not the absolute fastest, but accurate so time wasn't wasted making corrections.
Despite that, I wasn't even interviewed for the data entry job. A few weeks later I took a job as a caretaker (cleaner / odd jobs / security) covering sick leave at a local school, before finally getting my first "proper" job six months later.
M.
"that part has now been split in 2 with half the marks for handwriting and half for typing"
Surely not? They're still marking students on handwriting rather than content in this day and age? We haven't done that discriminatory shit in UK schools for... a quarter of a century or so. (God that makes me feel old.)
When I was at school - more than 25 years ago - my English teacher got sacked (and I believe barred from teaching) after someone correlated the grades given out with the races of his students. He'd used 'handwriting' as his excuse for marking down every single student of the races he disliked. It was always a stupid thing to mark, but it was also an opportunity for racists to racist.
"Surely not? They're still marking students on handwriting rather than content in this day and age? We haven't done that discriminatory shit in UK schools for... a quarter of a century or so. (God that makes me feel old.)"
Unfortunately, despite your example of a minority using it as a method of abuse, it shows in the very poor handwriting of so many people. Likewise, we don't usually mark down on spelling in the UK "so long as the intent is communicated". Also shown be the poor grasp of grammar and spelling exhibited by so many these days. "Don't worry, the computer will mark up all the grammar and spelling corrections with suitable Americanisms"
I was left handed when a child, but when I was in Junior School, we had a teacher who had an intense dislike of left handed people. If he saw you using your left hand, he would call you out to the front of the class, tell you to hold out your left hand palm uppermost, and proceed to administer four sound whacks with 12 inch wooden ruler across your palm, accompanied by his litany "You write with your right hand, it's why it's called your right hand". I would then return to my desk and clamp my left hand under my right armpit until the stinging ceased, and refuse to do anything at all for the duration.
I am now fairly strongly right handed, but do have the occasional ambidextrous episode, such as when I was up a ladder painting the guttering, and my next door neighbour said "I didn't know that you were left handed". I replied, "No, I'm ambidextrous, and I can't move the ladder any farther to the left or it will fall off the end of the wall".
Hmm. I had a bit of that. I am actually genuinely ambidextrous though,
For most tasks I have a preferred hand- just not the same one. But for writing I was forced to fix to my right hand- it would probably have been my left otherwise*. As a general rule I use right for strength and left for dexterity. And sometimes I use both together, great for sorting tasks But often I've just got used to using one, usually right handed - like the mouse- because that's what was available to me when I started.
*My left hand isn't much worse than my right, I just don't use it as much And in Hebrew I found that I wrote better left handed- partly because I learnt that separately as a young adult and it goes right to left.
I got my own back on him, though, when I took my 11 Plus exam. I had recently fallen off a piano stool (don't ask) and had a green stick fracture of the right Radius bone. I was in plaster from my palm up to just below my armpit, with the elbow set at 90°. I was allowed extra time to take the exam because I had to write left handed. Mr Currell was invigilating, and I could see the steam emitting from his ears as I was permitted to do the very thing he had beaten out of me two years before.
I naturally used to use the mouse in my right hand, but several years ago, I developed RSI, so I now use it left handed, which frees up the right hand for taking notes, etc.
While I agree with the punishment for the racist teacher, easily readable handwriting is still important. I'm in pharmaceuticals, where paper documents are very much still the norm. Whose initials are these? Rather, WHAT initials are these? Can anybody read the explanatory comment on this batch doc? "Legible" is a key part of the ALCOA principles.
"ALCOA stands for Attributable, Legible, Contemporaneous, Original and Accurate"
"I know what's appearing on the screen even while I'm looking at the keyboard"
Lucky you, all too often I end up finding out that some poorly-written program (looking at you, SAS EG) has silently stolen focus from the one I was writing into, and when I look up from the keyboard a bunch of text that was supposed to be there is nowhere to be seen...
Icon is my reaction when I then think about how mumble-ty years ago I knew how to touch type...
Umpteen years ago I was working as a data input monkey on an AS400 system. I used to switch my eyes between the paper data and the keyboard with an occasional glance at the screen as it was pretty common for the screen rendering to be lagging behind the input buffer and I could be entering the next screen of data whilst the display was showing the previous page (repetition is a brutal mistress). I could correct typos as I went without ever seeing them on the screen.
Thankfully I now do stuff where the thinking takes more time and effort than the key bashing, but it certainly did wonders for my multi-finger typing, which drifted naturally into touch-typing when I was no longer just re-keying stuff from a piece of paper.
I had a brief lesson in "proper" typing at around 4th grade, but simply did two-finger hunt-and-peck for several years. Then slowly and subconsciously switched to four-finger, then six, then eight... One day, I realized I was naturally keeping my hands in "home" position on the keyboard like they had tried to teach me over 20 years before.
What trained me the most was MUDding - you'd better learn to type fast, or your character will get killed!
"Here in Switzerland, kids are being taught touch typing starting in 4th grade (approx 9-10 yrs)."
...and a significant portion of them are probably wondering why they are being taught this since their only other interactions with computers are touch screens on smart phones and tablets outside of school. I wonder how long the keyboard will last as a primary input device? You don't see many keyboards in Star Trek :-)
"I wonder how long the keyboard will last as a primary input device?"
I've noticed my kids when they were younger trying to "swipe" a magazine or the TV screen, so certainly they're born into a world where touch-screen is default. Having said that, a proper keyboard ergonomically suited to the size of human hands will always work better than a smaller touchscreen, and even a keyboard-sized touchscreen will lack the feedback that a keyboard gives.
Yeah, my mum was a typist. And my handwriting was godawful. 50 odd years ago she taught me to type. I wasn't brilliant, but it was better than handwriting.
I had to wait for the BBC micro to be invented before everything suddenly improved for me.
These days my handwriting is still godawful and sadly my touch typing has deteriorated too.So that I end up looking at the keyboard more and more. For me touch typing only works if the position of the keyboard is consistent. And over the last few years this has just not been the case.
>Nobody seems to teach "touch typing",
When I went to secondary school (in the late iron age) they had just removed all the typing desks - cos we had finally abandoned all that "girls do secretary / boys do metalwork" stuff and in the future we would all do Craft-Design-Technology and nobody would type.
Ironically now when I'm not building prototypes in a workshop I'm typing code
I'm retired now, but I never learned to touch-type.
However, I did - and still do - type in a very unusual manner ... one of my methods for copy-typing was - and still is - to hold the copy in my left hand and to type one-handed with my right, at a reasonable speed. One witness to my (absence of) technique observed - correctly - that I play the piano.
Watching a friend two-finger type a few days ago, it finally dawned on me: *that's* why laptop keyboards have become so universally awful -- because most people don't have a problem with them. The forces driving the switch to chiclet keyboards are obvious -- cost and thinness. But the other half of it is the dwindling market of touch typists demanding keyboards suitable for touch typing.
When I was coding I often laid out the structure of a function/whatever just in comments, then went back and wrote the code to do what the comments said should be happening. That practice came from writing stuff that interfaced to a number of slightly weird libraries which it was easy to mis-remember parameter order/purpose - coding usually meant frequent reference to API documentation. Unless I laid out the structure in comments first, then by the time I was a few lines in I'd started to lose track of what my actual logic was.
Many is the time I've had a compilation error that's pointed to mis-formed loops, even though code looks OK on visual inspection. Select the offending code, count instances of "{", get a big number. Count instances of "}", get big number minus 1. Put head in hands and weep while mumbling "oh, FFS - not again..."
Macros, baby, macros.
For anyone lucky enough to have missed it, there was a craze in the 80s to write C that looked "readable", from all the coders who knew BASIC/Pascal/ALGOL/SIMULA and were suddenly presented with a C compiler on the IBM PC (Amiga programmers knew better!). Cue hundreds of headers starting
#define BEGIN {
Even using "FOR" instead of "for"!
The best fun was had with the slight changes in preprocessor behaviour - it seems that some would strip out comments whilst others just did the macro & include expansions, leaving comments in the output. So cue people writing
#define FOREACH(i,n) int i; for(i=0; i<n;++n) // C is weird, starts count at zero
FOREACH (j, k) BEGIN printf(" %d", j); END
Would the numbers appear on stdout? Maybe?
"Foot pedals, the only choice for a gentleman"
I fiddled about with a foot pedal input device way back when. Was a Moog Taurus originally[0], but I modified it so various chords became control, alt & shift keys, Fx keys, Sun's "L" keys, and a couple other key bindings depending on the computer it was plugged into. It was an attempt to bring sanity to EMACS, among other things.
Even when working well, it turned out to be more trouble than it was worth, so I never pursued it. A friend of mine took my breadboard rig and code & used the basic idea for an alternative input device for disabled folks while getting his Masters at Stanford.
[0] Don't swear at me, I didn't wreck it! Somebody else had cannibalized most of the electronics, I found the carcass in a pile of trash outside SAIL's DC Power building when we were moving out in 1980. The idea of making it an input device flashed into my mind as soon as I set eyes on it.
I'm a left-handed touch typist. Keys under the little finger of my right hand are always more difficult for me than text. Even upper-case number keys #$% are slightly slower and more difficult.
A proper language would use simple text that can be typed at for speed for common structural statements. .EQ. .LT, .GE. (For younger readers: the dots in those operators are part of the syntax)
I'm not opposed to functional languages, or significant white space, or multiple inheritance in it's right place. I don't yearn for GOTO or FILE 7.
But damn, I'm sorry that a language for right-eye-dominant hunt-and-peck typists who did their own code-entry with one index finger had so much effect on subsequent languages.
I count them both in one pass: starting at 0, add 1 for each "{" and subtract 1 for each "}". If the result ends up nonzero, you have a problem. (If it ever goes negative, you can stop early; not only have you found a mismatch, but have also somewhat narrowed it down.)
If it goes below zero, I *know* I have a missing "{". Which is precisely why I can stop counting; I've answered the two-part question "is there an imbalance, and if so, which kind?" and am ready to move on to the next phase of problem isolation.
(Obviously, if you start counting in the middle of a properly nested structure, the count can go negative. So don't do that; start at the beginning.)
Get your sword, Coding Style Heretic!
Always have your braces lining up vertically, indent one space (tabs are for barbarians!) inside the braces. Then use your editor's "mark column" and "jump to matching brace" actions to give you a nice vertical highlight when everything matches properly.
Barbarian here! My { always align vertically with } - Allman style - and are MISRA compliant with a line of their own. I'm not a fan of vertically dense code which I find difficult to read.
But I can't be doing with spaces instead of tabs; I hate it when I delete what I expect to be a tab and the whole line loses vertical alignment.
Back in roughly 1975, one of my Big Iron mentors had a bumper-sticker:
Tabs are for typewriters!
A woman from the typing pool who much preferred Fresca to Tab took exception to the comment, so he offered to buy her lunch in compensation for the perceived slight. They are still married.
A few years later, another mentor opined "Feelthy TABs are the devil's work, unless you are using them on your Smith Corona".
Personally, I prefer spaces, but I'll use tabs where required. When in Rome & all that.
RE "Coding Style Heretic" -- When jake said, "when in Rome", he didn't mean "... feed the Christians to the lions". Anyway my code editor finds the matching braces even when they don't line up.
RE "} # if (a -eq b)" -- Took me *decades* to learn that trick. I find it especially helpful when there are a bunch of nested closing braces very close together, with maybe one line of code in-between. Which one still needs closing, before or after that one line? But I make it even more explicit, for grepping later:
} # END if (a -eq b)
As for the Who, Me? it's a good thing the change from add to add-update wasn't worthy of a comment!
Upvoted.
But in most cases the best solution is to refactor the 80 lines of stuff to one or more well-named methods. The only exception I can think of is where it's 80 lines of essentially repetitive code, so there's little advantage in moving it to an 80-line method.
Sometimes extracting a method/function is a good approach. Other times I just rearrange to avoid the isolated statement. That's especially so for "if"'s:
if (cond) { 80 lines of blah blah blah } else { return ERROR; }
becomes:
if (!cond) { return ERROR; } else { 80 lines of blah blah blah }
That allows the reader to be done with the "if" more quickly -- to pop it off one's mental stack, as it were, before diving into the blah blah blah.
(Sorry for cramming those onto one line each; proper formatting, in whatever HTML subset El Reg might allow me this week, on my phone where every tag is torture, is more trouble than it's worth.)
This is good as long as you're careful always to make it look different from a real line that's been commented out when debugging. Lines like that lead a later viewer (it's always future me if I've done it) to think either that the code should be running, or more likely that it failed and was replaced, so it should be stripped out to avoid confusing future future me.
# Repeat: this means that a equalled b eighty lines ago and still should
is better than a line that might look like code.
Yes! I did that with node.js/Javascript code I had to work on. I can't believe the RECOMMENDED code layout with it is like:
for (let i=0; i<5; i++) {
...
}
instead of
for (let i=0; i<5; i++)
{
....
}
Despite Javascripts recommendations I tend to dot he second form, and indent the {} if I can, and do the comment at the end commenting what the bracket is for. As you say, I've spent FAR too long before I did this finding the missing bracket. (It's especially bad in node.js since the syntax includes functions where it's like x(parameter 1, {...90 lines of code..}).
I'll admit to having been lax in commenting code for a while - only I'm going to read it so there's no need, is there?
Well, yes there is! I've got to understand it if I have to revise it and as I wend my way towards retirement UI have to bear in mind someone else *will* have to support it in the future. Cue a rush of commenting as I migrate code for a new plant.
A friend of mine sent me a copy of some source code I had written in the 1990's that was used to schedule observations for a science satellite mission. Well commented - yes. Understandable - yes. Well structured - not even close. Maintainable - let's talk about that some other time.
Amazingly the software worked and actually exceeded its functional requirements by a significant measure; in doing so it contributed to the satellite also exceeding its science objectives. BUT, I am definitely cringing at looking at what I wrote all those years ago.
"BUT, I am definitely cringing at looking at what I wrote all those years ago."
Don't cringe. Pat yourself on the back instead. And have a beer! It did the job it was required to do, and more. Can't ask for more than that.
Besides, you should see the garbage code the other guy was cranking out.
It's likely that the other guy's code is in a rocket that did the big firework thing, so no evidence :-)
Examples that we do seem to know about, probably all of us, include "wrong arithmetic sign, tried to fly down instead of up" and "failed to convert metric and imperial measurements".
20 or so years ago we had a Perl programmer whose main script generated static web pages from the stuff (pseudo/simplified text and images) that the designers wrote.
It had exactly one comment in it. At its most incomprehensible core section, the programmer had added: // This is a skanky hack
To this day I have no idea what it was doing!
>"Some idiot," he writes, "had put an add-update where there obviously should have been an add."
... of fixing the problems you cause. And collecting brownie points into the bargain.
While some organisations will instantly sack the individual deemed responsible for such ballsups, there is a better way!
It is said that experience is the lessons learned from mistakes made. So what better way to gain that experience than by making mistakes. Combine with the other cliche of that which does not kill you, makes you stronger and a convincing argument can be made to retain all but the worst problem-makers: the people who always seem to be in the middle of every corporate disaster.
And in this case, had "Francis" been given the heave-ho, what are the chances that the replacement, would not have also spotted the same idiotic add and changed it to the obvious add-update?
And sometimes if people take you for granted, it WAS possible to reboot, a production server. Investigation will find that it "Blue Screened". People suddenly remember all the systems that are running like clockwork, and why you are there.
In our company it was always assumed that the ERP financial and ERP production systems were the most valuable and hardest to negotiate downtime for. But when yours truly was laid low for a spot of surgery and a junior admin decided to "improve things" on the Exchange Server., the 7 hour email outage lasted just about the entire surgery and recovery time, until the colleagues across the pond woke up. Much gnashing of teeth and wailing of hands proved that 7 hours without email was more upsetting to the company than not being able to produce in 3 factories for 7 hours.
Now days a properly configured SEIM will point the finger quickly. Luckily our security team are a Marx Bros v Three Stooges crossover.
If you foster a culture that allows you to make mistakes every now and then[0], you'll get employees that will 'fess up when things break, you can fix the problem faster and you'll have a learning experience. If you, on the other hand, turn anywhere else than "What went wrong here, and how can we prevent it from happening again?" in your post-mortem, your employees will clam up for fear of retaliation. This will in many cases lead to longer troubleshooting times and can have adverse knock-on effects. Red herrings encountered during troubleshooting may cause unnecessary changes to processes, for example; or permissions may be overly tightened. And of course, you'll wake unnecessarily many people to join marathon conference calls...
Make sure your processes support your staff. Automate recurring tasks if possible, but trust your people to know their stuff. And of course, as the AC above me pointed out, locate the ones that aren't learning from their mistakes on their own, and help them.
[0] This does not include companies whose CxOs says, with a big grin, to the press that "We EXPECT our staff to fail AT LEAST fifty percent of the time! That's how AGILE we are!". Because that's just dumb.
"Mine's the one with the jacket in the pocket of the jacket in the pocket"
That's known as the Droste effect.
Always a good idea to have a "brake" clause in a contract when doing upgrades, and force things to slow down, or pause for a couple of hours or days.
Because people will make mistakes when under pressure.
But beancounters don't like this as it'll make projects run over budget.
But mistakes make projects run far more over budget plus the extra costs involved should any specialized knowledge be required to fix things should it be required.
Currently shoveling large piles of stuff on a project which was procured with the exact opposite - a rigidly fixed delivery schedule that just keeps piling on more trouble while we try and recover from the flaws which should have been sorted on day minus one. Just another day in the public sector.
And then you suddenly find yourself explaining to auditors why things took so long, or you leave when you realise that the NAO has just described your project as irrecoverable? Or your project suddenly shows up in Written Questions in the HoC?
Not that _I_ ever ended up there, but I know of people who have (or projects that have - Yes, DEFRA, I'm looking at you!)
"Because people will make mistakes when under pressure.
But beancounters don't like this as it'll make projects run over budget."
If you're under pressure to meet a deadline, it's usually because the deadline wasn't properly specified in the first place, or was "adjusted" by the bean counters to fit a smaller budget than was originally planned for.
Don't worry, you'll live. And also eventually get over the horror.
Wait until you get hate-email from somebody lambasting code you wrote 40 years prior that hasn't been used for at least thirty years to your knowledge, and only runs on a processor that has been out of support for about as long.
Well, code CAN contain such credentials, but: They must be stored in a secure way, so they only work on this machine (or vm) with that specific account, else decoding the security token won't work. Though I only use that inline-credentials way only for small scripts. For projects they have to be stored in a different, more secure, way.
A version of it, “Never let a good crisis go to waste”, has also been attributed to Churchill, albeit without a source. The earliest sourced version might be the title of an article that was written in 1976 by M. F. Weiner in the journal Medical Economics : “Don’t Waste a Crisis — Your Patient’s or Your Own.”
This is what version control should absolutely not be used for. It's there to see what changes were made when (and why, if you have any sense), and allow reversion to older code. If you have to track down the person that wrote it to solve it, your code and documentation are of unacceptably poor quality and need improving.
To check quality of work, use code reviews and testing. If you start chucking blame around when errors are made, realise instead that errors are a fact of life, and use them as a learning exercise for general improvement. Flapping about in a panic or shouting at techies solves nothing, and is a sign that management needs to improve by being realistic and having processes in place to calmly deal with issues as they arise.
> This is what version control should absolutely not be used for
Uh, can't agree with that "absolutely" - you find an apparent problem with a recent code change and want some more info about it, going for a chat with the person who made the change is the best approach. You can check the issue tracker (linked to from the commit comment, wasn't it - if not, go for a chat...) and then back to the requirements first, of course...
Note that, despite the name of the Subversion command "blame" (which I also believed was chosen as a short command name when devs were capable of talking tongue in cheek), "going for a chat" does *not* mean "chucking blame around" (well, not until they prove themselves to be total &£@+%&).
If you're not sure why it's there but there might be a reason, find the person and ask. If you are sure it is not necessary, no need to find them just to blame them for having it. Unless it looked like deliberate sabotage, it was likely a mistake and their response about it will either be "I don't remember it" or "I don't remember it, but you're right it needs to be taken out".
> If you are sure it is not necessary, no need to find them just to blame them for having it
Not finding them to blame them, but more than once, having spotted something that doesn't belong, it was worth discussing it because we found that a misunderstanding had led to multiple occurrences, which the perp (!) was able to quickly correct (he knew where the bodies were) and the commits went under their name, showing that they'd taken responsibility.
I once worked at a place that had a mainframe from IBM that was charged 'per transaction'.
It was accessed via various layers of tooling i was responsible for, in an ASP.net front end, by field staff. They had to stay 'on site' while various batch jobs completed and tested configurations and such.
One of the processes I wrote was a batch job that queried the mainframe (via a Brand New High Throughput High Performance WS-* interface) for the results of those batch jobs, and when they were complete 'closed' the job and thus allowed the field staff to move on.
I kept the list of batch jobs in a SQL Server 2000 database. Every minute or so a small job would go and reconcile against the mainframe. It should only have reconciled the 'open' jobs, but some fool (me) had neglected to add the 'where' clause to omit the 'closed' ones; nevertheless this had all happily gone through integration test and gone live.
Months later, first I knew of the bug was when the beancounters who audited mainframe usage called me up and asked why this tool had cost £250,000 in mainframe charges.
A quick scan of the code, a 'doh' moment, and a hot fix, and the problem vanished. Overnight, the transaction hits reduced to acceptable levels.
I called back and explained the situation. I told them that field staff were so keen to get on to the next job, that they were hitting 'Refresh' on their browsers too regularly, and this was hammering the server needlessly. I told them I'd identified a quick caching solution that mitigated the problem, and deployed it.
I got a two grand bonus for creative and quick problem solving.
While this was well over 15 years ago now, 'Anonymous' for obvious reasons,
Where I work now, it was a common practice to just comment out code.
Horrible to start with, and a nightmare when it goes on for several pages. Especially annoying when you grep for something and you get false hits in the old commented out garbage.
My current co-worker and I have decided this is not acceptable and all this will be mass deleted as we make fixes/updates. There was a huge outcry from the old guard, but we stuck to our guns.
I look forward to the inevitable wailing and gnashing of teeth (yours) when in a month or two the whole thing grinds to a halt, and old guard say - 'oh yes - the new code works on the Widget 9700, but fails on the new widget 9701, but don't worry, the working code is in there - just commented out.'
In which case they go to the version control, rewind until the comments come back, copy them into the specifically-named files they always should have been in, and give a lecture about how to organize code that runs into files that compile and are labeled for what they do. For the same reason that printing out a copy of the code and putting it on your desk doesn't count as having it available for use, storing necessary code in comments that won't ever run unless an undocumented manual procedure is followed is also not the way to do it.
Not a programming error, at least not on my part, but a few years ago, I maintained a site that used a custom written back end API to access data.
Most of the site functioned well for years, but there was one page that was always slow. It was a simple equipment list, so shouldn't have taken more than a few seconds. Even on a gigabit ethernet connection (and the server was hosted in the next building, so no connection issues to slow it down. On average, it two 10-15 minutes for the page to load.
My colleague, who maintained the server, told me point blank it must be my crap code. I had already worked out the problem. It was the fact that thanks to his design, I had to make at least 5 calls to the API to get all the required info for each item. For some items, it was a lot more. Assuming the page contained 200 items, it was having to call the API >1000 times, and for each call, the Webservice was making calls to the SQL Server Database. I think with a few users using the site (it was quite heavily used in it's heyday), the queue of pending operations on the SQL Database could build up very quickly.
So, I added logging with timestamps to the code. I showed him the log, showing the hundreds of calls to the API, and how long they were taking.
After spending a few minutes looking at my code, and the log, he said "leave it with me". A few days later, he told me he'd created a new API. One that returned all the information my site needed in one call. It reduced load times from 10 minutes to less than 1 minute.
I recently wrote some SQL code that was pulling production data from a database. The system manual said to do it like this:
select (fields) from (table)
where parentid=(select equipmentid from (table)
where parentid=(select batchid from (table)
where batchname like '%yadda%'))
This worked just fine when run on test data. But on the full production data, it took upwards of 10 minutes to run! The solution was to run:
select equipmentid from (table)
where parentid=(select batchid from (table) where batchname like 'yadda%')
(Note the lack of wildcard at the start of the batchname!)
and store the result (i.e. "&equipmentid"), and then run
select (fields) from (table)
where parentid=&equipmentid
Not running the two inner selects a hundred thousand times each definitely sped things up a bit - down to about 0.5 seconds runtime.
The manual gives you a starting point, but don't go strictly by it...
For some reason this story reminds me of a particular lecture in a physics class I took in college. The topic of the day was thermal expansion, and so the professor had an cast iron ball and ring. He heated up the ring to show that it would expand and fit over the ball. Thing is, he got distracted and then the ring cooled onto the ball. Both of them are made of the same material, so heat and expand at the same rate, making him have a minor panic attack about having to tell the lab manager what he'd done.
Best example of thermal expansion was a manufacturing plant with a 150-foot-long machine. One end was attached to a wall, the other was attached to an I-beam sitting perpendicular to two floor-mounted I-beams. When at operating temperature, the machine was about 120 °C. Some servicing was done in the winter, at likely 5 °C.
The lower I-beams had rather impressive scrape marks from the upper beam's movement.
...I was tasked with getting about 10,000 pages of website from our old CMS to our new one. Having spent several months poking around in the piles of spaghetti code that tied together a few hundred modules that had been attached to the old site in order to get it to do the dozens of intranet things that it didn't really have any business doing, I came to the conclusion that the fastest way to get everything moved would be to get each page owner - and helpfully the pages had the owners name stamped on them - to simply copy-paste the pages in question into the new site and do some much needed update on the copy as they went along.
I was told in no uncertain terms that there was no way everyone had time for that, and we had to automate it. I said something along the lines of "OK, but I'm giving this a 50% chance of working at best, and given the number of interactions we might not find out exactly how bits of it are broken until it's too late to do anything about it.
It was decided by the website committee* that we would go ahead with the automated migration, and so one fateful morning I pressed the enter button on an utterly terrifying bash script calling various bits of perl, php, and in one instance piping an SQLdump through awk. It was not pretty.
It took about an hour to realize that it was taking much longer than it ought to and clearly something somewhere had gone wrong and we were going to have to revert to backup even if it did finally complete, and I informed the website committee of this. Again, the committee decided* that it would be better to wait for it to finish and then spend a couple of days cleaning up the errors on the new site than going back and doing it all again. I pointed out that this was a very bad idea since I didn't really understand how it was that it had broken in the first place because the code I'd written couldn't possibly cover every weird edge case that I suspected, but couldn't prove, existed.
Three weeks later everyone agreed that we needed to go back to the backup and start over.
*That is, no one is prepared to take actual responsibility for the decision, and the only person who clearly opposed it** was mysteriously omitted from the minutes.
**Me.
They don't listen do they? But sometimes it goes in the user's favour.
My client was a manufacturing company, about 150 staff, mostly on the shop floor. The board had insisted to one of the users, "Eric", a blue collar manager, that they must have a report generated from [my] system, ASAP-pronto-quick-sharp. So Eric asked me if I could produce code for the next day.
Of course, I'd give it a go, I said.
So, wanting to help Eric out, I pulled an all-nighter The reporting code was just hacked together, not pretty. It ran just fine, but it was slow, very slow.
I arrived on-site very early to install the update, before Eric was in, and returned home. When Eric ran the report, instead of the usual "It's working!" message, the pop-up read "Eric, go and make yourself a cup of tea...". When I spoke to Eric later he said he realised immediately that I wasn't joking and effectively had the morning off!
While not having an actual example of this, as an old long-retired programmer, THAT is the thing that made me very humble many years ago - that point where your own feelings of "I am so smart" got the better of you & you forever after KNOW that you will never do that again ! Nothing like having to admit to the boss man you were the one that 'did it' ! I think that is life's biggest lesson !
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
