Brogrammer Test

I went on the web to google "brogrammer". One of the top links was a test to determine if you are a brogrammer. Here is a spoiler. I got a Broficiency Quotient of -90, making me a Standard Nerd. I must say that some of the banter based on my answers was hilarious.

For example, I said that soda is my coding fuel. The web site responded that this was weak. LOL. Then I chose RPGs as the most fun pastime. The response was for me to GTFO. LMAO. Who made up this test? Answer: John Polacek.

Fork, Dongle, Fired x 2

Check out this story of how an indicent at the PyCon conference blew up and got two people fired. Adria Richards attended PyCon as a developer evangelist for Sendgrid. She heard two guys behind her making inappropriate jokes about "dongles" and "forking". She took a picture of them, and tweeted about the behavior.

Pycon staff came and questioned her. Then they took the two guys aside. The one who made the joke apologized. You would think that would be the end of the incident. Nope. Turns out these guys worked for Play Haven. The guy who made the joke got fired.

Truly unfortunate. But wait. There's more. There has been a large Internet backlash against Adria Richards. She has received many threats. Her blog hs been the target of a DDos. And her employer, Sendgrid, has fired her.

People are referring to the incident as DongleGate. The PyCon code of conduct already states that offensive jokes are inappropriate. Seems the code of conduct has been ammended to prevent future nonsense. The sad outcome is that two people have been fired from their jobs. And that's a huge fail.

Critical Path Analysis

I had to estimate how long it would take to get our product ready for Windows 7. This was pretty easy since we had our test team smoke test our applications. They found some minor GUI alignment issues. Then there were some interproces communication troubles using FindWindow. All in all, I determined it would take one person about 300 hours to take care of everything.

Then I got the call from my team lead. We needed to come up with a new estimate. Why? Well he said some managers will see the 300 hour number, put 3 developers on the project, and schedule it to complete in 300 calendar hours. Oh no. That will not work.

You see, all the work cannot be done in parallel. Somebody needs to figure out the FindWindow replacement for Windows 7. Then that technology will be applied to the places in the applications that use FindWindow. There is a critical path which must be worked serially. Assuming everything can be done in parallel will result in a nasty schedule surprise.

My team lead told me to determine the criical path, then multiply those hours by the number of developers we think will be assigned. That will save us from anybody thinking they can divide the total hours by the number of developers to figure out how long the effort will take.

This feels wrong. Shouldn't we teach critical path analysis to whoever is doing the schedule? That way we don't have to do these estimate hacks? Apparently that task is harder than it seems. We got some managers who are looking to slash the schedule. Their angle is to slice and dice the work up amongst multiple developers to decrease time to delivery. They apparently do not want to know about the critical path. Go figure.

Memory Trouble

Our flagship application has the ability to query many records in the database. We limit the query results to 10k. However the user can decide to get unlimited extra batches of 10k records. When the user wants to view the details of one of those records, we load in a little information for all the records.

Part of the record is a set of subrecords. The way the memory layout was done was to include a fixed size array within the main record. Initially this worked because the maximum number of subrecords were capped. However that maximum was recently opened up. The result was that some queries resulted in an out of memory error. Ouch.

A lot of people pitched ideas on how to solve this problem. However those people were not famliar with the code. We have a lot of C-style code that accesses the array of records, as well as the subarrays of subrecords. Plus the database code is Pro*C, which is in effect the C programming language. You can't do things such as just stick an STL vector in there.

I gave this problem some thought. After I was assigned the task of solving the problem, I figured the simplest solution was best. Change the record structure to have a variable list of subrecords, whose size is dictated by the actual amount of subrecords. This is effective use of the memory we allocate. The implementation of this was a little tricky.

The app is a mix of C and C++ code. Some of the memory is allocated with a call to the C malloc function, while other memory uses the C++ operator new. These techniques are similar, but you should deallocate with the corresponding technology such as a free or delete. In the end, the only thing that caught me off guard was the application's subtle dependency on there being an empty unused subrecord memory be preallocated. Luckily a sharp coder can handle all such nuances.