Things ya hear at the office

Shepherd said:
The Holy Grail of job security: A million lines of spaghetti code and not one line of documentation.
Click to expand...

We've got that. And worse. Modules copied, code modified but not the documentation, so you've got code for different purposes all with the same documentation. I'd much rather be dealing with no documentation at all.
 
Don’t crush that dwarf, hand me the pliers.
 
Shepherd said:
The Holy Grail of job security: A million lines of spaghetti code and not one line of documentation.
Click to expand...


One of the best lessons I ever learned in college was in my Operations Research class. The prof gave an assignment to write a program to implement some algorithm or other (might have been a travelling salesman problem; not important). He then gave us a program that had been written in FORTRAN by one of his previous grad students, but it was never completed. Our assignment was to fix and finish it.

Of course, there wasn't one single line of documentation. Variable names were obscure, there was leftover ghost code that wasn't called, calls to non-existent subroutines he hadn't written yet,....

Making that thing work (and I did it) was one of the worst nightmares I ever had in school. I've long since forgotten the technical aspects; the enduring lesson was document, document, document.
 
Ghery said:
I remember a coding job when I was in college where I was given a data deck and asked to write a program that told you how many times each question was answered a particular way. Multiple guess answers, 1 to 10. In FORTRAN, that's easy. Except they didn't mention that some people didn't answer all the questions and the "no answer" questions were coded as "0". 0 is not a valid subscript. It took me forever to finally find that bug in the data.
Click to expand...

One of the most interesting bugs I've ever seen is the Facebook string null terminator bug that affected 128-byte strings:

21:26 to 26:00 in this video:
 
Half Fast said:
Variants of this conversation have been repeated many times over the years...

ME - I can't possibly meet this schedule.
BOSS - How many more people do you need so you can bring in the date?
ME - Can you make a baby in a month if you bring in nine women?
Click to expand...

I've used that one myself.
 
Half Fast said:
Variants of this conversation have been repeated many times over the years...

ME - I can't possibly meet this schedule.
BOSS - How many more people do you need so you can bring in the date?
ME - Can you make a baby in a month if you bring in nine women?
Click to expand...

Well, I could do my part.
 
Half Fast said:
One of the best lessons I ever learned in college was in my Operations Research class. The prof gave an assignment to write a program to implement some algorithm or other (might have been a travelling salesman problem; not important). He then gave us a program that had been written in FORTRAN by one of his previous grad students, but it was never completed. Our assignment was to fix and finish it.

Of course, there wasn't one single line of documentation. Variable names were obscure, there was leftover ghost code that wasn't called, calls to non-existent subroutines he hadn't written yet,....

Making that thing work (and I did it) was one of the worst nightmares I ever had in school. I've long since forgotten the technical aspects; the enduring lesson was document, document, document.
Click to expand...
Documentation is worthless in my opinion. The moment someone changes the code and not the document, it’s nothing more than a misleading lie. The only documentation that matters is the code that’s running in production.

Write the code in an organized manner with good method and variable names, functions that are single purpose, testable, and without side effects, and you’re good to go.
 
Last edited:
Holy cow I guess 90% of folks on PoA write code for a living.
 
Salty said:
Documentation is worthless in my opinion. The moment someone changes the code and not the document, it’s nothing more than a misleading lie. The only documentation that matters is the code that’s running in production.

Write the code in an organized manner with good method and variable names, functions that are single purpose, testable, and without side effects, and you’re good to go.
Click to expand...

There are a lot of times where I'd like to see the developer put in a line or two telling me what he intended to do. Usually if I'm reading someone else's code it's because it's not doing what it should. I can see what it is doing, but that doesn't tell me what it should be doing. I write a lot of SQL and it's a limited language, plus execution speed is super important, so abstraction is usually not an option sosome well placed comments help a lot.
 
Most of the stuff I’ve written has been numerical methods. Documentation is, err, well, ummm, something I guess. “Forward elimination” and “back substitution” aren’t real helpful unless ya already know matrix solvers. Transforms and inversions are worse - gotta read the dissertation to have a clue what’s going on. That or be a hell of a mathematician...
 
FormerHangie said:
There are a lot of times where I'd like to see the developer put in a line or two telling me what he intended to do. Usually if I'm reading someone else's code it's because it's not doing what it should. I can see what it is doing, but that doesn't tell me what it should be doing. I write a lot of SQL and it's a limited language, plus execution speed is super important, so abstraction is usually not an option sosome well placed comments help a lot.
Click to expand...
If you don’t know what it should be doing, how are you going to fix it? :p
 
I haven’t actually coded in years, but I still do code reviews and find bugs that others can’t. When I did code regularly I usually wrote my functions as commented pseudo code, high level first, then filling in the details and then it usually naturally broke down into function calls and class definitions and the comments removed as the code is implemented. It’s a similar pattern to what is popular now with TDD.
 
I’m an EE and an old servo geek. (You can’t spell gEEk without EE...) Many years ago I did quite a bit of simulation writing. I’ve done mostly engineering management for the past couple of decades, though.
 
Salty said:
I haven’t actually coded in years, but I still do code reviews and find bugs that others can’t. When I did code regularly I usually wrote my functions as commented pseudo code, high level first, then filling in the details and then it usually naturally broke down into function calls and class definitions and the comments removed as the code is implemented. It’s a similar pattern to what is popular now with TDD.
Click to expand...
“Class definitions” .... kids today ...
 
CC268 said:
Holy cow I guess 90% of folks on PoA write code for a living.
Click to expand...
Not anymore. But we have to do something to make life interesting. Can you imagine staring at a computer screen 8 hours a day...and it's not PoA?
 
Write the code in an organized manner with good method and variable names, functions that are single purpose, testable, and without side effects, and you’re good to go.

Sounds like you’re the guy who wrote the code I just spent a week debugging. The guys who wrote the code told the business owner the same thing you said.

I spent most of the week just figuring out what the code did. Function calls that had a name the might have made sense to the guy who wrote them, but since I wasn’t around, they make no sense to me. Conditional branching where it jumps to things like 'Dave’s formulas', or 'Handler'. Why? Print statements that only print when delay code is commented out.

I finally got it to stop crashing when I commented out the last function call in the stack. By this point I was in about eight layers deep. I have no idea why it stopped working—or even if the code ever worked with that function enabled. The code’s owner decided not to spend any more money on the bug and if someone complained that the function no longer worked for them, we’d revisit the issue. So far, no one has complained.

Moral to the story: I hate people like you from the bottom of my cold dark heart.
 
Salty said:
If you don’t know what it should be doing, how are you going to fix it? :p
Click to expand...

That's the problem. I have to reverse engineer the entire process if they didn't describe what it was they intended, then make any needed changes. Naturally, this has popped up as a bug and needs to be fixed right now, so I'm in a big honking hurry because it's putting me behind on what I'm supposed to be working on.

A couple of years ago, I was tasked with the complete overhaul of our receivables because of a policy change. It was one of those, "Here's what we want to do sort of, how long will it take?" things. I took their back of the envelope "requirements", put together a real set of what we were going to do and how we were going to do it requirements, then created a presentation telling them what they really wanted. As soon as I get through presenting it, they agree that what I was telling them was what they actually wanted, and how soon could it be ready? I told them I didn't want to answer because while I had a reasonable idea how long it would take to write the new code, as part of this I had to match 15 years worth of old receivable payments to invoices, and that would be like peeling an onion, you'll know how many layers you have once you're done. They kept pressing me for an estimate, so I finally gave them one, with the caveat that it was for what I could see, and there would be other things that popped up as I started creating procedures to match payments and discounts to invoices. Of course they held me to the original estimate, so I got to work all kinds of insane hours to make this arbitrary deadline. Hell, I was only working with receivables, nothing important, right? If I made a mess of it I could very well have sunk the entire company.

Anyhoo, there are a number of algorithms in the logic that matches payments to invoices that would be confounding to anyone who looked at the undocumented code. How it works is actually very simple but there are some seriously nonintuitive steps involved. A few sentences of "what this is doing" would save anyone days of trying to figure it out on their own, and that's why I do it. I don't care what Martin Fowler or "Uncle Bob" Martin think, there's a place for comments. And the next person who gives me a software engineering book where the entire project is written in one language is gonna get introduced to the real world, where software is distributed across C#, javascript, and SQL, and quite often interfaces with an external system.
 
I haven't written programs in over 20 years (writing stuff on Excel doesn't count). I spent a good 10 years upgrading and maintaining a program originally written by my boss to run our EMC labs at the company I worked for prior to Intel. He wrote it in HP BASIC (which HP really insulted by calling it BASIC, it's far more than that) and used highly descriptive variable names, along with comments. It was easy to follow and update over the years. No spaghetti code. I popped in for a visit a year after leaving. They were having a problem with the software and after a year away it took me about 5 minutes to fix their problem. Well written code with comments and descriptive variable names is really nice.
 
JScarry said:
Function calls that had a name the might have made sense to the guy who wrote them, but since I wasn’t around, they make no sense to me.
Click to expand...
And even if they appear to make sense sometimes they don't! We have (had) an SQL function that someone wrote once to calculate "business minutes" - which is great for us for our KPI reporting. After using this function for years we come to find that it defined the business day at 8am to 7pm.. not 9 to 5.. and fixing it was a headache as it called a number of other functions that defined the start and end times of days, holidays, etc.
 
JScarry said:
Write the code in an organized manner with good method and variable names, functions that are single purpose, testable, and without side effects, and you’re good to go.

Sounds like you’re the guy who wrote the code I just spent a week debugging. The guys who wrote the code told the business owner the same thing you said.

I spent most of the week just figuring out what the code did. Function calls that had a name the might have made sense to the guy who wrote them, but since I wasn’t around, they make no sense to me. Conditional branching where it jumps to things like 'Dave’s formulas', or 'Handler'. Why? Print statements that only print when delay code is commented out.

I finally got it to stop crashing when I commented out the last function call in the stack. By this point I was in about eight layers deep. I have no idea why it stopped working—or even if the code ever worked with that function enabled. The code’s owner decided not to spend any more money on the bug and if someone complained that the function no longer worked for them, we’d revisit the issue. So far, no one has complained.

Moral to the story: I hate people like you from the bottom of my cold dark heart.
Click to expand...
I hate people that write inaccurate documentation that is just as confusing as the code if you aren’t the one that wrote it and isn’t accurate as soon as the ink on it dries. Even worse, I hate people that assume the document is right and don’t go any further.

Don’t get me wrong, I draw diagrams of the big picture and how things fit together, but as soon as I hand them off to someone to maintain they usual go stale and become lies that often make things worse.

I’m the guy you come to when nobody else can figure out why some code isn’t working. And I don’t read the docs for more than very very high level understanding. I dig straight into the code because nothing else matters.

I just did it last week. I inherited a problem the team had been working on for over a month and couldn’t figure out. They all went on vacation and I got stuck with an angry customer. I had it figured out in 3 days with no access to documentation or any of the developers that wrote the code. there were three issues combining to cause the problem, two were operational, and one was a code bug. Without all three the problem wouldn’t happen. It would take reams of documentation to explain all that and months to figure out the problem using the docs. And the three fixes I made to resolve the issue would require 10 times more man hours in fixing the documentation to reflect what I did accurately than it did to fix the problem. and if that didn’t get done, then the docs are a lie, which happens more often than not. Heck, the two operational problems were results of reality not matching how the system was documented to run ( and I wrote those original docs years ago, and they didn’t appear to have changed since I did even though the team had been making changes I am unaware of all those years). If you used the docs for more than a quick reference, you’d never figure out the problem, which was in fact why the team was struggling. They were making assumptions without looking at the actual system as it was running.

Hate me if you like, but I’m right.

Ps>
I never said there is no place for comments, but I reserve them to explain code snippets I couldn’t find a way to make self expressive. Sadly, some my comments are //god help you if you have to change this, even I don’t understand it well enough to explain it. I apologize in advance. If you mess with this you will probably break “that thing over there” because there are side effects I can’t explain happening.
I’ve only done this when having to change code I didn’t write and didn’t have time to refactor, and I try to at least provide some insights into what I think is happening
 
Last edited:
The problem I see with too many developers is that they are far to eager to latch on to someone else’s thinking and run with it, so any mistake in the documentation leads them the wrong direction and wastes everyone’s time. I had to stop giving advice on how to fix problems unless I got directly involved. What would happen is they would take any guess I made on the incomplete information they gave me and run with it without verifying it fit the scenario. Days later they’d be in the same place with no new information. Making them figure it out themselves is the only way. You have to look at the code. You can’t avoid it.
 
Salty said:
The problem I see with too many developers is that they are far to eager to latch on to someone else’s thinking and run with it, ...
Click to expand...

Wow from my experience you must be right. I don't code for a living and my only experience coding was back in college. One was a class assignment to write a program that would calculate the critical speeds of a rotating axis containing various masses. It was a big long term assignment and constituted a large portion of our grade. We were standing in the hallway before class one day and someone came up to us and offered to sell us the solution that they'd gotten from someone from the last semester. I was surprised how many of my classmates jumped on that, but I didn't.

I remember sitting in the lab running my program over and over and over until it got the right answers, while others rewrote the one they'd bought and were done with it. Still others wrote their own but never could get it to calculate correctly. I got an A+ and if memory serves the teacher mumbled something about recognizing duplicated code as he passed out the papers.

I don't know whether I'm more ethical than that or just not stupid enough to think I could get away with it but in any case I did feel proud because I knew the teacher knew my code was my own.
 
No, no documentation. The code was hard to write, and by goodness, it ought to be hard to understand too.

Up above there was a link to "Things you should never do". I say BS to that. Because the author was able to string together some anecdotal stories about companies who lost out by re-writing their code, he asserts that it should never be done. I have seem code rewrites where they've made sense AND improved the product. Code that literally could not be upgraded anymore because there was nobody left who understood what all of the people have had their hands in the code did. It was strung together so badly that every attempt to fix something broke two other things and the most basic improvement would take months. In one case, they actually did it as a race, with one team completely rewriting the code before the other team could modify it to add a minor feature.

At some point you have to recognize that the 20 year old code that has turned into spaghetti through bad maintenance needs to be replaced.
 
Timbeck2 said:
New guy. A new guy that has been in training longer than most and just doesn't get it. He's on his second training extension with people backing up behind him and sucking the life out of everybody. It's SOGOTP* time for him as everyone is tired of writing evals and explaining things over and over again. Ain't nobody got time for dat! He approved a C-130 for a shallow beam approach with a helicopter directly in the C-130's path without saying a word to warn the helicopter. I told him to give traffic on someone...twice and he started talking to a medical helicopter that was 15 miles away.

*...or get off the pot
Click to expand...
No picture, no clue.
I’ve been in your shoes, biting tongue waiting for the trainee lightbulb to at least glow a little bit.
And there was the time, when he would not pay attention, not listen to advice. Best thing at the time was to pull his plug to get him off the airwaves and give me a chance to fire off three quick clearances.
 
Once upon a time, long long ago, there was a company that wrote engine control software in assembly code. And, in those days, I worked for said company. One of the "things" that the software did was diagnostics for the sensors / engine (self test) - I wrote the docs/specs for that. One day, management determined that the self test code took up too much room and assigned three programmers (not me!) to modify the code to make it smaller. They did.

One of the things the code did was check all of the sensor signals coming from analog inputs for "out of range" values. It also checked the same inputs during a couple different on-demand test modes to see if they were delivering reasonable values. This involved six limit parameters, and six fault codes. The programmers realized that the same code was repeated over and over. They also realized that the six limit parameters could always be arranged in the same order from smallest to largest (there was no requirement for this, but that's the way they were always calibrated by the engine guys). So, arranged the parameters in order (smallest to largest) in memory (score one for absolute assembly), arranged the codes in the same order, and essentially were able to treat them like an array even though they were never declared as an array. They would call a routine to check for faults by just inserting a call to a memory location along with the location of the first parameter in the code for each of the sensors. And it worked just fine as long as the parameters were set to the values in the usual order. This sort of trickery, along with a bunch of other similar stuff made a pretty good dent in the size of the assembly code, everyone was happy (more or less).

The software specifications (which I wrote) also doubled as the user documentation, so to make it clear to the users, the same if/then/else routine was carried in the docs for each of the inputs so the users could understand what parameters they needed to set and what were the corresponding codes. And, the disconnect between the docs and the implemented assembly code was not an issue because the guys who came up with all the shenanigans were also the ones that maintained the code.

One day, management again made a decision. Rather than have programmers that did control and programmers that did self test, they decided to re-assign tasks so that the control and self test for any subsystem would go together.

When the time came for changes in the self test, I would dutifully update the documentation, pass it along to the person who would be responsible for updating the assembly code. A day or two later, I would be informed that the code could not be changed because the code simply did not exist. The parameters in the spec did not exist in the software, the if/then/else structure did not exist, etc. And, over and over, I would have to sit down with the individual and explain the facts of life. The code did exist, the code executed, it just wasn't obvious. With much muttering and head shaking, they eventually sorted out where the code existed and were able to make the changes. After a year or so, word had spread and pretty much all of the programmers could make things work. But for some reason, I just wasn't that popular even though I had nothing to do with the assembly code "tricks". :)

Then there were the flag games with RAM and ROM parameters having similar names, getting set to the same value, but both existing in the software (it did actually save some bytes).
 
Chip Sylverne said:
Wow, that's a blast from the past. Don't make 'em like that anymore.
Click to expand...
I’m thinkin most readers are clueless on that one.
And remember that you are rapidly approaching the antelope freeway exit...
 
Half Fast said:
Making that thing work (and I did it) was one of the worst nightmares I ever had in school. I've long since forgotten the technical aspects; the enduring lesson was document, document, document.
Click to expand...

Looks like the profs work assignment achieved the intended result. Had he just told you to implement the algorithm in your own code, you would have learned something, but not the point about documentation and consistency.
 
weilke said:
Looks like the profs work assignment achieved the intended result. Had he just told you to implement the algorithm in your own code, you would have learned something, but not the point about documentation and consistency.
Click to expand...
Modern languages should be used in such a way that the purpose, function, expectation, and regression is all included in developer output and mostly as code.

/grenade
 
MadseasoN said:
Here's a positive one from a highly respected co-worker. It's a borrowed quote but I like it:

"Sometimes good is good enough"
Click to expand...

Reminds me of one that I absolutely hate: "Perfect is the enemy of good enough." True, but good enough is the enemy of great... And usually there's not a lot of effort to go from good enough to great.

Another one I love to hate is "analysis paralysis." Everyone I've heard use that phrase really just doesn't want to analyze something at all. Where it should really be used is if someone is trying to analyze beyond two essentially equal options - Once you've analyzed enough to reach the conclusion that two options have value that cannot be differentiated between, just pick one and be done with it. But yeah, usually when I hear "analysis paralysis" it could be replaced with "I'm too lazy to prove the direction I want is right and I'm going to spout these rhymes to try to get you to not consider any other options."
 
You must log in or register to reply here.
Back
Top