coworker rants

A place to discuss the implementation and style of computer programs.

Moderators: phlip, Moderators General, Prelates

nachumk
Posts: 3
Joined: Fri Aug 20, 2010 10:09 pm UTC

Re: coworker rants

Postby nachumk » Fri Aug 20, 2010 10:33 pm UTC

Regression tests - Only print out errors, never return them programmatically. Then you can grep through log files to see what happened.
Regression tests - Use 'golden' files as your compare source to see if later regressions are passing (by comparing them to the 'golden' files).
Regression tests - Script copies over different tests onto a single test file which is the one compiled for each test. Same file pops up in the tool every time it hits the end command in the test. The file is then overwritten by the next test. This causes a dialog to come up asking if the file should be reloaded or ignored. This stops the test from running. Instead of fixing the regression script (to not copy the file over), the engineer filed a bug with the tool maker to stop it from asking to reload or ignore the file changes.
Error codes - An enum was created to handle error values, SUCCESS, TIMEOUT, ... In the language we are programming in, the enum is a strongly typed variable and in order to call the functions you must include the package that defines the enum, and create a variable of the enumerated type. This confused the engineer. The engineer replaced the enum with defines. The engineer also decided that it would take too much time to fix all the function calls to receive the error code. (There were 6 files calling these functions at the time, and even now maybe there are 10.) So the engineer replaced function local error codes to a library global error code. (Multiple threads is now out of the question.) The engineer also made the type a 1 bit array, and therefore the code is now fixed to have either SUCCESS or TIMEOUT. Adding in a new value will require fixing all locations that use this 1 bit array (by converting them to a 2 bit array!).

Comment from software programmer with 10 years of experience -
Me: Why can't you solve the problem with some simple semaphores?
Programmer: Semaphores are dangerous, you can cause deadlocks.

Comment from Senior Verilog Engineer:
Me: Current hardware tools can't infer a hand coded FIFO.
Senior Verilog Engineer: Of course they can!
Me: A hand coded single or dual ported RAM, you mean?
Senior Verilog Engineer: No, a FIFO - why shouldn't they be able to infer one?
Me: Umm...

Comment from Senior Software Lead:
Me: Are 64-bit accesses to the 32-bit bus atomic? (Meaning guaranteed to happen high then low without possibility of being interrupted.)
Senior Software Lead: I asked my boss and he said they weren't. And 32-bit accesses (to the 32-bit bus) are also not atomic.
Me: Perhaps I didn't explain the question.

Some people are extraordinarily stupid.

PS - I have written some really bad code in my life, and I've made lots of mistakes. The great thing about realizing you made a mistake is that you've also just learned something new. If only others would see it this way too. I love to learn new stuff and I love to teach people everything and anything I've learned.

Being too stubborn to learn is very aggravating for those who have to work with you. Even worse is having to work in an environment that encourages people to never make waves. Better to get along than to improve things.

kmatzen
Posts: 214
Joined: Thu Nov 15, 2007 2:55 pm UTC
Location: Ithaca, NY

Re: coworker rants

Postby kmatzen » Sat Aug 21, 2010 4:37 am UTC

nachumk wrote:Senior Software Lead: I asked my boss and he said they weren't. And 32-bit accesses (to the 32-bit bus) are also not atomic.


Does the architecture support unaligned accesses? I've worked with the MPC823 and MPC555 that supported 32-bit unaligned bus transactions with a single instruction that take up to 3 bus transfers to complete on the 32-bit bus. (It breaks the 4 byte transaction into byte, halfword, byte, transactions if the address is congruent to 3 modulo 4.)

What does it mean to infer a FIFO? Is that like writing verilog so that the design compiler infers a latch, register, or memory? The tools report these things, but I never really cared (this was just school stuff and I'm not in that field anyway.) I don't even understand what it means to make a compiler recognize a FIFO and why you wouldn't just keep a solution and instantiate it. I just don't understand the terminology.

nachumk
Posts: 3
Joined: Fri Aug 20, 2010 10:09 pm UTC

Re: coworker rants

Postby nachumk » Sat Aug 21, 2010 11:34 pm UTC

You are right, I should have been more clear. The accesses are all 4 byte aligned (or 8 byte aligned for the 64-bit registers). That was a given... Forgot to mention it.

Sad thing is that the software lead couldn't comprehend the question. When I tried to explain he started to get annoyed. He asked his boss who assumed he was referring to something along the lines of:
Is
*(uint64*)p = (*(uint64*)p) + 1;
atomic?
And this isn't what I was asking anyhow (something I made clear to the Senior Software Lead when I asked him the question). Once I went to his boss and explained the actual question, he immediately agreed that 32-bit is atomic, and that he has to check what happens for 64.

Inferring a FIFO is to say that if you use an FPGA that has built-in FIFO logic, then the tools can recognize when you've written a hand coded FIFO and move that logic into the FPGA's built-in FIFO. This is possible for built-in RAMs, but I've never heard of any tool that can do that for a FIFO. The simple reason is that it's unlikely that you'll code the FIFO with all of the same latencies that the built-in FIFO use (not just data, but also all of the flags), and even if you did, it is very very difficult for the tool to recognize such things and therefore to move the logic to the built-in FIFO. For RAMs, it is much simpler to see that your logic mirrors a built-in RAMs funcitonality. And even for RAMs, you must code the RAM in very specific ways to make the tool infer properly.

That isn't to say that inferring a FIFO at some future time would be impossible, but this Senior Verilog Engineer didn't even understand why this should be a problem. Perhaps some future version of Quartus or ISE would manage this, but such a thing doesn't exist yet. You can see that by looking at any manuals for any RTL compilers and read up about inferring RAMs and see if any of them talk about inferring FIFOs.

It would be even more difficult to infer a dual clock FIFO for even more reasons.

kmatzen
Posts: 214
Joined: Thu Nov 15, 2007 2:55 pm UTC
Location: Ithaca, NY

Re: coworker rants

Postby kmatzen » Sun Aug 22, 2010 12:38 am UTC

nachumk wrote:You are right, I should have been more clear. The accesses are all 4 byte aligned (or 8 byte aligned for the 64-bit registers). That was a given... Forgot to mention it.

Inferring a FIFO is to say that if you use an FPGA that has built-in FIFO logic, then the tools can recognize when you've written a hand coded FIFO and move that logic into the FPGA's built-in FIFO.


No, I think assuming transactions are aligned is somewhat logical. I mean, you can save space in some cases, but we are always taught to align data in memory anyway just in case we port the software to another architecture that does not support unaligned accesses. I was just trying to imagine what your coworker must have been thinking.

Thank you for explaining what it means to infer in RTL tools. I had guessed what this meant since we were taught to construct things in a certain way to avoid having the tools produce a latch instead of a register, but I wasn't quite sure. I have absolutely no idea how you could infer a FIFO from just looking at it. Registers, latches, and memories have patterns that I was taught and I can imagine several patterns for FIFOs, but if you go through all that work following a complex pattern that the FIFO requires, you might just as well instantiate it.

nachumk
Posts: 3
Joined: Fri Aug 20, 2010 10:09 pm UTC

Re: coworker rants

Postby nachumk » Sun Aug 22, 2010 6:50 am UTC

I was a bit annoyed on Friday which is why I ranted so much.

Truth is that most people are really not so stupid. People are stubborn and afraid of admitting that they don't know something. They also fear looking stupid in front of others.

I'm not an authority on the human condition, the human mind, or human behavior, but this is how it seems to me.

I have recently had to work with many people of this sort. It is the least enjoyable work experience I have ever had to endure. The idea of 'not making waves' is organizational, and not just a few select people. Don't call anyone on anything. Don't push anyone to defend or explain their opinion or position. Let everyone live with the mediocrity that is their safety blanket.

I most enjoy working with people that can teach me stuff, and people who are starved to learn stuff. That is how you do the best possible work.

Regarding the alignment - this was part of the specification. Since the registers have fixed addresses and are located off processor through a 32-bit bus, the only sane way to access the registers is at their exact addresses which are 4 and 8 byte aligned (depending on their specific register size).

Regarding the FIFOs - Compare it to a RAM (in Verilog)

wire [9:0] a;
wire [7:0] d_in;
reg [7:0] d_out;
wire w;
reg [7:0] d [1023:0];

always @ (posedge clk)
if(w)
d[addr] <= d_in;

always @ (*)
d_out <= d[addr];

This is a very simplistic RAM. It could be synthesized as logic, but it may be possible to infer a built-in RAM. Here's the key:
The reason why it may or may not be possible is due to these reasons:
1. Perhaps the compiler doesn't understand the syntax as I wrote it. Perhaps the logic is exactly right, but the compiler needs it to be written out slightly differently.
2. Perhaps the built-in RAM has registers on input sampling the address / data / write enable, or alternatively registers on output for the data. If that is the case then this can't be converted to the built-in RAM b/c it would change the synchronous timing.

Taking this example should show why trying to infer a FIFO would be many times harder, and from what I know, not at all possible with any tools out today. Inferring a dual clock FIFO would be even more difficult because you would have lots of cross clock domain logic that would have to match exactly how the built-in FIFO works. And you would need a compiler that would have to recognize and logically understand the timing and be able to match it up (to see that the timing is the same) before it converted it to the built-in FIFO.

To not understand this is typical for a person who hasn't worked with RTL FIFOs. For a Senior Verilog Engineer to not understand this is also OK, but for that same engineer to be unwilling to discuss and defend his point of view is just plain unacceptable. Perhaps (I don't think so, but perhaps) I am wrong, and I would LOVE to know why!

User avatar
Pesto
Posts: 737
Joined: Wed Sep 05, 2007 5:33 pm UTC
Location: Berkeley, CA

Re: coworker rants

Postby Pesto » Wed Sep 08, 2010 12:13 am UTC

Grr. People on my team are screwing around in the repository again.

Someone deleted some files, and didn't know how to roll back a commit. Instead of asking for help, she added files back one by one, making commits without commit messages.

User avatar
Xeio
Friends, Faidites, Countrymen
Posts: 5101
Joined: Wed Jul 25, 2007 11:12 am UTC
Location: C:\Users\Xeio\
Contact:

Re: coworker rants

Postby Xeio » Wed Sep 08, 2010 2:49 am UTC

Pesto wrote:Grr. People on my team are screwing around in the repository again.

Someone deleted some files, and didn't know how to roll back a commit. Instead of asking for help, she added files back one by one, making commits without commit messages.
It's like puppies and sunshine were thrown into a woodchipper and committed to your repository! :mrgreen:

kmatzen
Posts: 214
Joined: Thu Nov 15, 2007 2:55 pm UTC
Location: Ithaca, NY

Re: coworker rants

Postby kmatzen » Wed Sep 08, 2010 11:50 am UTC

nachumk wrote:Someone deleted some files, and didn't know how to roll back a commit. Instead of asking for help, she added files back one by one, making commits without commit messages.


Yup. This happened to me as well a couple of years ago. I think I threw a plastic spoon at the person since it was 8am and I just bought some Cinnamon Toast Crunch. The LSQ wasn't working and then this happened. The thing is, after he deleted the files, I gave him a command to effectively rollback the commit. When I found out what he was doing, he said, he didn't like the command.

WORST. NIGHT. EVER.

User avatar
Steax
SecondTalon's Goon Squad
Posts: 3038
Joined: Sat Jan 12, 2008 12:18 pm UTC

Re: coworker rants

Postby Steax » Wed Sep 08, 2010 2:36 pm UTC

Scenario: One happy morning, sitting in front of my computer, checking out stuff for the day, a bajillion emails flood into my email account. All of them from clients of a web application I made. Uh oh. Skimming through them, they all had one complaint: being unable to log in. I try logging into the admin account. Not working.

Attempt to fix: Open up PHPMyAdmin and check the Users table.

Heart-stopping moment: "Passwords" field is now a VARCHAR(1). They're supposed to be hashes. The entire table is empty.

After some digging, it turns out the other system admin, aside from me, who is only tasked with looking after the clients and making sure everything goes well, doing log cleanup and maintenance and everything, strayed into the 'Database Administration' interface (which I left available for her in case she had to do something while I'm unable to access a computer), and, out of curiosity, looked into the Users table. She thought the long fields of hashes were 'corrupt data'. I had an SQL Query interface just in case. She thought it would be interesting to try emptying the table. Apparently realizing her mistake, she tried to fix it by removing the 'corrupt' field.

Thank god I had a backup of that table handy. And that she never went into the more... interesting... tables.
In Minecraft, I use the username Rirez.

User avatar
Thesh
Made to Fuck Dinosaurs
Posts: 6579
Joined: Tue Jan 12, 2010 1:55 am UTC
Location: Colorado

Re: coworker rants

Postby Thesh » Wed Sep 08, 2010 3:54 pm UTC

Steax wrote:Scenario: One happy morning, sitting in front of my computer, checking out stuff for the day, a bajillion emails flood into my email account. All of them from clients of a web application I made. Uh oh. Skimming through them, they all had one complaint: being unable to log in. I try logging into the admin account. Not working.

Attempt to fix: Open up PHPMyAdmin and check the Users table.

Heart-stopping moment: "Passwords" field is now a VARCHAR(1). They're supposed to be hashes. The entire table is empty.

After some digging, it turns out the other system admin, aside from me, who is only tasked with looking after the clients and making sure everything goes well, doing log cleanup and maintenance and everything, strayed into the 'Database Administration' interface (which I left available for her in case she had to do something while I'm unable to access a computer), and, out of curiosity, looked into the Users table. She thought the long fields of hashes were 'corrupt data'. I had an SQL Query interface just in case. She thought it would be interesting to try emptying the table. Apparently realizing her mistake, she tried to fix it by removing the 'corrupt' field.

Thank god I had a backup of that table handy. And that she never went into the more... interesting... tables.


Well, deleting the data is good for security. Also, deleting all the data in your database is great for performance.
Summum ius, summa iniuria.

User avatar
Pesto
Posts: 737
Joined: Wed Sep 05, 2007 5:33 pm UTC
Location: Berkeley, CA

Re: coworker rants

Postby Pesto » Wed Sep 08, 2010 10:27 pm UTC

Exactly. Not being able to access the system becomes very very fast.

User avatar
Pesto
Posts: 737
Joined: Wed Sep 05, 2007 5:33 pm UTC
Location: Berkeley, CA

Re: coworker rants

Postby Pesto » Fri Sep 10, 2010 9:11 pm UTC

More source control fun.

We've been developing in our own subversion branch for a couple months and are merging our code back. Now, subversion merges are painful enough as it is, but we have the added fun of there being a botched repository migration right in the middle of our project. None of the history from the old repository is accessible from within the new repository. Now we're doing the merge by hand. We were diligent (at my insistence) about merging code from the trunk into our feature branch, so we don't have much to worry about in the way of code clobbering.

Fortunately, the guy that did the migration has been canned, but for completely unrelated reasons.

I'm working on getting up to speed on git-svn so we won't have this merging headache in the future.

0xBADFEED
Posts: 687
Joined: Mon May 05, 2008 2:14 am UTC

Re: coworker rants

Postby 0xBADFEED » Sat Sep 11, 2010 4:26 pm UTC

Pesto wrote:I'm working on getting up to speed on git-svn so we won't have this merging headache in the future.

Git-svn can have it's own merging headaches if someone forgets to play by git-svn's rules. It's better but doesn't completely solve the branching/merging headaches with SVN.


Return to “Coding”

Who is online

Users browsing this forum: No registered users and 4 guests