Commercial Software Bugs

I have been talking about my trial software run of SmartBear's CodeReviewer tool. To me the meat of this software is the ability to view and annotate lines of code. The code viewer is an Internet Explorer window without the normal menus. I found this window missing any text search capabilities. Thus I had to rely on the default Internet Explorer find function which is lacking.

It was not difficult to enter a defect during the review. However I could not rate the severity of the defect. The main problem I encountered was entering multiple defects for a source code file. I would click a line of code and enter a defect. The line number was annotated in the defect. However subsequent defects seemed to continue referencing the line from the first defect. I emailed SmartBear's customer support for help with this critical issue. Update: SmartBear support helped me through this issue. I was clicking the wrong button to initiate a new defect.

There is a reporting functionality in the software. You can customize the contents of the reports somewhat by choosing different options. However our CMMi people want code review artifacts in a certain format. I wonder whether I can get the software to product such artifacts automatically. If so, the cost of the software may be worth its benefit. I hate manually generating those artifacts every time I review something on the project. For now I am going to continue trying out this software.

Software Installation

I previously wrote about downloading and installing a code review tool. It appeared as if the software was written in Java. The install wizard was created with Install4j, and the software required Java. Unfortunately the end of the installation brought me to an Internet Explorer page that could not be viewed.

Well I did not give up. After refreshing the web page, I got to the screen where I initialized the database. Then the software made me enter my company name, my name, and my e-mail. I don't like entering this stuff as I don't like to get spammed.

The first install screen that I got to work was a bit strange. There were two sections, one for the admin account, and another for users. Both sections had a button beneath them. This implied that you would enter information on each, then press their respective button. However it turned out you needed to enter information on both. I guess you choose one of the buttons to save everything. Very odd.

There were some interesting parts to my software configuration experience. The admin user cannot by default do code reviews. And some example bug tracking tools that integrate with the review tool are FogBugs and Buzilla. Also the server lets you configure the minimum build number for clients that try to connect. That is smart (no pun intended SmartBear).

Once I tried starting up some review, I encountered some more weird things. My user account had an immediate action item to enter my phone number. Why do I have to do that? I am still thinking that maybe the software phones home to the manufacturer and gives them my phone number. Left that one blank. When I tried to create a review, I could not attach any files initially. That was unusual. Maybe they need to set up a database record that the file attach process requires. It was still unnatural.

The code inspection process screen was busy. There were a number of sections highlighted in yellow. Not sure if those were just for the trial version of the software or not. There was also a splitter window for the actual code inspection. I could not figure out why there was a split. The bottom splitter pane seemed small in height. Maybe they want me to be able to see two portions of the code at the same time. Stay tuned for some more feedback on my experience with SmartBear's CodeReview.

Code Review Tool

Today I was contacted by SmartBear Software about the latest release of their code review software. Previously I had read and blogged about their book on peer code review. They offered me a sale on their software, and asked that I blog about it. Well I could not write about it unless I experienced it for myself. So I decided to download a trial copy today.

It seems SmartBear has two main lines of review software - CodeReviewer and CodeCollaborator. I decided to download the light version which is CodeReviewer. Their web site required that I enter my phone number. As I don't want any sales calls just yet, I entered the SmartBear technical support phone number. Let's hope the sales guys don't call. Heheh.

There was some initial confusion over the install software. I could not find a separate executable for CodeReviewer. So I just proceeded guessing that maybe there is one installer for all their software. I don't like guessing though. The EULA for the software stated that I had to agree to public use of my name as a customer unless I inform them otherwise in writing. Dang. Now I got to write them a letter.

I set up a unique port for the code review web server to run from. Then I chose an embedded database for my reviews as this seemed the easiest. However I might reinstall to see how hard it will be to hook up to my Oracle database running on my server as well. After installation was complete, the installer launched Internet Explorer. And the page showed "The page cannot be displayed." Ouch. We are off to a bad start here. More details on my experience will come in future blog posts.

In Case of Layoff

Like many others out there, a guy got laid off and asked for advice from the programming population. A number of people shared some ideas which seemed to have merit. One idea is definitely out of the box. That is you should always be looking for a job. Do so even when you are employed.

Other good ideas include having a LinkedIn profile. Occasional interviewing can keep you sharp for the time when you absolutely need to shine in an interview to get a job. Another out of the box idea is to always be saving up money. That way you can endure a lay off.

In general, developers dislike recruiters with good reason. However you might not want to always be brushing off recruiters. You might benefit from their services some day, however slimy they may be. I have a job right now. However it could not hurt to be prepared for an emergency.

Process Support

I read a sad story about a guy who was working for a company with little to no software development process. He was wondering how to get management support to implement some level of process to the madness. Reddit readers gave him a good deal of interesting advice. I thought I would summarize some of the best responses here.

This is the bottom line from the business. Management won’t change what already seems to work. If you are working a lot of overtime to make things work currently, you should stop. Then the problems will come to light. Hard core advisers would say you should even go as far as sabotaging the status quo to get your company to need some changes. I personally recommend against that. However the ends often justify the messy means.

You could also go ahead and demonstrate (not tell) the business case for process improvement. Tie the business case to money to be made by the company. Understand that your success in this arena may depend entirely on your attitude and personal skills to sell the process. Like most things, you should not try to change everything at once. Go incremental.

If you can convince your development peers of the need for the process change, then go ahead and do it. Show your peers how you can prevent disaster or pain for them. That will get their attention. I know it would get mine. You can also spin your ideas. Instead of software development process, you could call it a work flow process. That sounds more MBA.

I was disappointed to hear some veterans say they no longer care if there is no process. That is a bad sign. Fight the good fight. Try to get process improvement on your project. If you do not succeed, quit and join another organization. Then start again.

Slacker Tendencies

I read a humor piece regarding slackers at work. It talked down to go getters. They only work on high profile duties. These duties are not important for the company mission. The slacker on the other hand, gets work done on time. In fact, slackers normally get things done early. They just don’t tell anybody about the early completion date.

Slackers solve problems the easy way. These are not the guys that usually get promoted. But they do tend to have much lower stress levels. Strangely enough, they get paid more than managers on the average. A slacker will show up for maybe 30 hours a week. They are normally only working for 20 of those hours.

Here is a list of the humorous characteristics of the work slacker. They don’t volunteer for anything. They make request by email instead of in person. That saves lots of time. They don’t tell you if they finish tasks early. They are experts at sneaking out of the office.

Slackers eat lunch out. There is no need to eat at your desk. They do not let others take credit for their work. Since they don’t do much, they need to retain all the praise they can for a job well and quickly done. There is some contention over this trait. But the author believes a slacker must stand up for their work. Finally a great coup is to join up with other slackers and book a conference room for a whole day. Then you can browse the Internet all day.

Who Was Erik Naggum?

Today there were a number of links on Reddit about Erik Naggum. I had never heard his name before. I therefore read up on him. He recently died. Erik was a Norwegian Lisp programmer. He was also a USENET philosopher, celebrity, and legend. I read some of his essays. One declared that knowledge is more important than life. Another stated that intelligence is determined entirely by genetics.

Aside USENET, Erik Naggum was known for hating Perl, C++, and XML. You see this from some of his quotes on the subject. For example, he asserts that “part of any serious QA is removing Perl code.” Another is that “only 5 people on the planet know C++.”

Erik's claim to fame seems to be his USENET personality. It was both blunt and aggressive. He flamed everyone on USENET. Some call him cruel but smart. It seems a shame that he may be remembered as a troll who “ate newbies alive”. Here is another of his many quotes: “Some people are little more than herd animals.”

Dress Code

Today I was searching online for information about the Oracle Alert Log. One of the search results was a page from Burleson Consulting. Those web pages are distinctive because of the layout and the familiar picture of the founder Burleson.

There was a link on the Burleson results page that talked about employment opportunities. I clicked through and found that they pay a lot of attention to dress code. Apparently their clients have high expectations. Therefore they have an extensive list of dress code rules which seem unusual.

Here are some gems I found. You are directed to wear “no phony Rolexes.” Furthermore a Rolex is the “time honored, instantly recognized symbol of success.” I assume they pay well, but probably not well enough for me to buy a Rolex.

Even more striking is the specifics for female employees. One rule for them is “No pants allowed, ever.” Multiple ear rings per ear are also prohibited. Here is some guidance that baffles me: “The quality of perfume is inversely proportional to the price.” So they recommend you buy cheap perfume to appear high class (remember they say it is an inverse relationship).

I cringe about the dress code for me. They must always wear white dress shirts. That sounds like IBM. Also they state that people will judge you by the quality of your shoes. I guess I am not Burleson material as I wear sneakers (even though I wear a dress shirt and tie). Hey. My feet hurt.

One of the comments posted by Burleson is a bit disturbing. In response to a comment from a reader, they write, “What are you a communist? Here in the USA, we have the freedom to hire and fire people for any reason.” I seriously hope they don’t have to go to court to defend that opinion. Any judge will give them the beat down for that perspective.

Sure you can fire somebody because they don’t adhere to your documented dress code. But you can’t fire somebody just because they are a woman. That will get you into severe legal trouble. I hope this was just an oversight by Burleson. I now will read their Oracle advice in a different light. They are the dress code Nazis.

Saved by Review

Our team was busy. So we farmed out the fix for a defect to a DBA. He did not know the business very well. He only had good PL/SQL coding skills. This DBA coded up a fix and presented it to my team lead. He looked it over, and thought it seemed fine. However my team lead implored me to do a deep review of whether this actually fixed the problem.

Now I was a bit hesitant to take on this work because I was very busy. However I usually defer to the boss. So I started going through the solution. I was shocked to find that the code changes actually broke the general case. To add insult to injury, the changes did not even fix the original problem. I sent an email to the DBA, and called up my team lead.

I was glad this stuff got reviewed before it was shipped out to the customer. We would have had even more emergencies if this buggy code went out. I am not sure what the true lesson was here. Perhaps it is that you must do in depth peer review if the developer confidence level is low. I would hope the other lesson learned is that you need to get deep into the code and the business. Otherwise you won't even be able to tell if what you are doing is correct or not.

Haste Makes Waste

Some time this past year, a developer on my team completed some coding under schedule duress. It came as no surprise when the testers found problems with the resulting code. The trouble tickets got assigned to me. As usual, I got busy investigating the source of the trouble.

When I traced the problems to their source, I found a double jeopardy of errors. The first was a classic C mistake. There were problems converting int to BOOL values. The wrong int values were chosen. We follow the standard convention of FALSE being 0 and TRUE being 1. Sure you can pass an int value when a function is expecting a BOOL. Just make sure the int has 0 or 1, and that you follow the convention.

This was not the extent of the problem though. Not all cases were being covered in the code. I know how this can happen. I have been under duress myself before. You code a special case first. When that works, you plan to go back and cover the more general case. But when you are coding to a strict or unrealistic deadline, there is never time to go back to those lose ends.

How can you prevent problems like this from happening in the first place? A naive approach would be to make sure you have time to do a good job. Sometimes that option is not a choice you can make. The alternative is to prioritize features. Then you can make sure that the most important features get implemented well. However this technique does require extra work in getting the features prioritized. And customers and bosses don’t like it when you partially deliver. I still think delivering some functionality well trumps delivering everything with a lot of bugs.

Making the Best

I got a dreaded call from my team lead around lunch time last Friday. He said the customer had a high priority problem that needed to be solved. So the both of us took a look at what it involved. We figured we could deliver a solution in a couple days. Our manager asked if it could be done in one day.

Now I am used to this type of crazy inquiry. So I reiterated that it would take two of the best people on our team a total of three days. And there was no good way to get from three to one. The manager did not like that answer. He directed us to do some more analysis. And he asked whether we could work throughout the weekend.

In the past I had fallen for that trap. The manager promises we can just work through the weekend, then take some extra time off the next week to compensate. The only problem is that there are more emergencies the next week, and you get into a vicious cycle. So I declined the weekend work. You got to stick to your guns with these workaholics.

There is a lot more to this story. However I thought I would focus on a positive note. My team lead needed me to do a lot of work for this problem. The most difficult task was to generate some test data to simulate all of the necessary test cases. This was some code deep in our application. The code dealt with all kinds of weird test cases. Instead of just hacking around some data, I decided to code a script that would set up the test data. This probably extended the time it took to generate the test data by about 10%. However it gave me at nice boost as I love coding, even when you have to stay late at work to get the job done.