SGI is Back

I missed this a few months ago. Silicon Graphics, that great company that gave us the hardware that generated visuals for movies like Jurassic Park, is trading on NASDAQ again (as of May, 2009). I just saw this on the cool site SiliconBunny.com. They are also the original creators of the OpenGL standard, a cross-platform graphics API which pre-dates and competes with Microsoft's DirectX.

Rackable Systems, Inc. (NASDAQ:RACK - News) announced today the completion of its legal name change to “Silicon Graphics International Corp.” The company also announced today that it will change its NASDAQ stock ticker symbol from “RACK” to “SGI.” The stock ticker change has gone into effect for the trading community on Monday, May 18, 2009.

And in September they released a new workstation, the Octane III, advertised to usher in "... a new era of personal innovation in strategic science, research, development and visualization." Whether the hype is true or not, it's nice to see the company trying to make a comeback.

Back in my days as a Unix Admin in the late 90's, I worked on Unix workstations from Sun (both BSD-based SunOS and the newer System V based Solaris), SGI (Silicon Graphics, running their IRIX OS), NeXT (Stephen Job's company after he left Apple that later got bought by Apple and whose technology melded into MacOSX), HP (HP-UX was the first Unix I ever used back in college), and AT&T (I had the "pleasure" of working on an AT&T 3B2). I can definitely say back then SGI was the coolest computer company around. Unix techies and scientists were well aware of SGI, but they only briefly managed to get much notice from the general populace due to their computers being featured in Jurassic Park.

They had everything from personal Unix workstations designed for 3D graphics better than anything a standard PC could do at the time (this was back in the days when PC graphics cards were comparatively primitive) to "low end" super computers (they eventually bought out Cray, the original super computer company).

The new machine will not run IRIX. It will instead run "Red Hat or SUSE Linux (which SGI’s excellent ProPack enhancements) or Windows HPC Server 2008". SGI actually IRIX on MIPS processors in favor of Linux on Intel a few years ago, so this is not really a surprise. I wish I had the money to buy one, but these are definitely high end machines.

Oh, well. At least I can try fsv on my Linux boxes at home for that SGI/Jurassic Park nostalgia. If you're a Windows user, you might want to try StepTree.

The Totem Pole

I got an interesting e-mail. Actual company names have been changed.

"I had some interesting news you should keep somewhat confidential. The contractor rates at [Client X] went up again effective [date withheld]. But here's the real catch: only some contractors were given this benefit. Apparently, the managers went through some sort of vote on who should be allowed to have their rate back to the [original date] levels. I'm not certain how high level these managers were. My [Consulting Company A] recruiter estimated about 80% of our staff got the nod. I don't know about [Consulting Company B], but there's a few from [Consulting Company C] I had lunch with on Friday that had the same news to share. The consulting firms and [Client X] have to keep a lid on it, so we're not supposed to tell. I think it's pretty crappy the way they are playing favorites, and secrets like that never really stay buried anyway."

I can't be surprised about this sort of thing. The company in question has been having problems and has been trying to save money, but undoubtedly they lost some good consultants when they dropped their rates, maybe some of their best.

The decision process they mentioned reminds me of an old way of determining raises that was used at a company I worked for in the past. The process was called the Totem Pole. Employees were ranked by managers, supposedly based on performance. Their names were then placed on a graph as the x coordinates in order of this ranking, and their salaries became the y coordinates. They then did some least-squares method to draw a line which represented what their salaries should be based on this ranking. If your salary was above the line, you were over-paid and didn't get a good raise (maybe cost of living). If you were below the line, you were under-paid compared to the other people and would get a raise.

The whole process of drawing a pretty graph was all to make the whole thing seem more objective and scientific. The ranking, was, of course, highly subjective. In any case, if you don't get a raise in such a system you know that either they think you're already over-paid, or you are at the bottom of the totem pole. Either way is not good. If they think you are over-paid, you can kiss any raises goodbye for the foreseeable future. If you're at the bottom of the totem pole, you not only can kiss your raises goodbye, but you may be on the short list for the next layoff.

Still, knowledge is power. Once you know you're at the bottom of the totem pole, you can try to improve your ranking somehow. If you don't think that's possible because you're already performing well, you can just hope things work out or you can start looking elsewhere.

Yeah, I know. Doesn't have much to do with programming, but it's it's just one aspect of life programmers have to deal with in the trenches.

Test Code Generation

Yesterday I started evaluating a product that claims to be able to generate test code for you. As a Java developer, I am mainly interested in JUnit test code. I am a big believer in test driven development, but I often find myself inheriting code with low test coverage. So, the question is, are there tools out there that can help one quickly and painlessly generate test cases for under-tested code?

In a past job I used a product called AgitarOne that purported to do just this sort of thing. The tests that were generated, of course, captured the current functionality whether correct or not. It could not produce truly intelligent test code. Also, it was big and expensive and required a lot of resources. Worse yet, generated tests extended a proprietary class, so the more you used it the more you were locked into their product.

I tried to use a free tool called testgen4j, but I didn't have the patience to make it work. Its user interface is a Unix shell script. I tried running it under Cygwin, but found the script didn't like being run with JAVA_HOME set to something with "C:" in it. I may eventually try it again, but what I really want is something that runs as an Eclipse plugin.

With that in mind, I started googling, and I found something called CoView. This product offers a Community Edition and an inexpensive Premium License. I downloaded and installed the community license file and the Eclipse plugin. However, to my disappointment, it simply did not work. It got errors whenever I tried to go to the preference page to tell it about the license file.

With a little more googling, I found CodePro AnalytiX. This is a much more expensive product, but I thought I might as well try the 15 day evaluation. It turns out that AnalytiX is just what I would like to have. It runs as an Eclipse plugin, it does a fair job of generating test code, it uses EasyMock, and it does not rely on some proprietary base class.

Unfortunately, when I set the CodePro preference to always generate mocks for all interfaces, this caused it to generate some code that wouldn't compile due to duplicate local variables. Selective use of mock objects worked better.

I had a number of classes that extend JdbcDaoSupport. Even after enabling generation of Spring tests, CodePro couldn't generate usable tests for these classes. The generated tests all had comments that said: "An unexpected exception was thrown in user code while executing this test...".

I guess the bottom line is that these kinds of tools can be nice, but even the really expensive ones will never generate usable tests for all code much less optimal, intelligent tests. They are largely a crutch for people who do not have the discipline to do proper test driven development, and, unfortunately, not a good solution to low coverage on legacy code.

OS Wars and Plugin Woes

Personally, I'm a fan of Linux/Unix. I have to use Windows at work, because that's what they give me. Otherwise, I'd be using Linux as most anything I do on the job I can do just as well with Linux.

I do use Linux at home, but even there I am still sometimes forced to use Windows even though it is more vulnerable to virus attack and it boots slower (at least on my computers). The latter is in part because of all the extra anti-virus and anti-spamware software I have to run under Windows. I have found that because I have multiple people using my computers and home, including for game use, I get a lot of malware. I have to have multiple scanners installed and occasionally do a registry clean in order to keep them running fairly well.

One reason I am forced to retain Windows at home is because the majority of PC games work only in Windows. There is other software that also only works in Windows, but for the most part it can be avoided by using open source alternatives. Games are different. Every game is unique, and most game developers don't develop for Linux.

Another reason I have recently been forced to run Windows is that I couldn't figure out how to get HDMI output working under Linux. This could be my own ignorance and deserves more research as I see other people on the internet who claim to have gotten this to work just fine.

However, increasingly the reason I am forced into using Windows is because of browser plugins. There are two important browser plugins that are not available under Linux. One is Shockwave and the other is Microsoft's Silverlight.

Personally, I could live without Shockwave, but my kids play games that use it. However, I recently became a Netflix user, and I've found that their "Watch Now" feature requires a browser with the Silverlight plugin.

In addition, I have found that the Linux version of Flash seems to be slower than the Windows version. So, I can watch Hulu videos under Linux, but the quality of the experience suffers.

Some day I may switch to Macintosh. With Apple's computers you get a Unix-like OS, better support from software developers and hardware vendors, and it's not a difficult sell to all the iPod fans who are already familiar with Apple. Of course, the downside to the Mac has always been that it's more expensive.

Linux, by contrast, is free and runs well even on older machines. I recently installed it on an old machine that had been gathering dust. I plan to use this as an experimental web server running Tomcat. I used Xubuntu Linux, and was able to easily install Tomcat. It seems to work fine.

Games and Netflix are certainly not important to everybody. If you want to get up and running on the internet just to stay connected with your friends and surf the web on a limited budget, an older machine running Linux will work quite nicely. I recommend some flavor of Ubuntu Linux for all Linux installs (I have tried several Linux distros and find Ubuntu to be the easiest to install and maintain). Personally, I like Kubuntu (which runs the KDE desktop, Linux Torvald's favorite desktop) for newer machines and Xubuntu (which runs the XFCE desktop) for older machines with less memory.

Scrum vs. XP

I have worked on both XP (extreme programming) and Scrum projects. There has been a lot written about the differences between Scrum and XP. Here are my personal observations.

First off, XP follows a simple set of rules and practices which can be summarized in a single page whereas Scrum is so complicated that there is a ScrumMaster certification.

There is a perception that XP does not scale well to large projects. XP projects should have one team maintaining a single code base, because "collective ownership" is one of the XP rules. Scrum projects, on the other hand, may have multiple teams working on a single application with several simultaneous branches working towards different releases. Developers are then only allowed to work on the branch that their team has been assigned.

I have found that in such large projects people are afraid to make changes for fear of creating new problems. So, opportunities for improvement are ignored. Although Scrum may scale to a larger team, it will not fix this problem. It should be obvious that a large team will be less agile no matter what methodolgy is being followed.

Scrum does not require TDD (test driven development) or pair programming. In point of fact, many developers don't want to do TDD or pair programming and will resist doing so even after they've been told to. The larger a team/project gets, the more trouble you are going to have convincing people to change the way they work.

I feel that TDD and pair programming should go hand-in-hand. Developers who don't want to write their tests first will not do so unless they are paired up with other developers who are in the habit.

Developers who aren't doing TDD will resent having to write unit tests, because it is an added task which makes it harder for them to get their work done on time. So, they will not put much effort into them. Without pair programming, nobody will know the difference until somebody later has to maintain code with crappy unit tests.

Developers who do TDD will be testing and coding simultaneously and finish both at the same time. So, the testing just becomes part of the process and is not an added step.

In addition to helping to encourage TDD, pair programming eliminates the need for separate peer code review since the peer review is happening simultaneous to coding. By contrast, formal peer code review meetings tend to nit-pick and make the developer feel that she is under the microscope intead of the code.

Unfortunately, most developers will resist pair programming as much as they resist TDD. One reason is that they may not like having two people crammed into a cubicle designed to fit one person. The ideal pair programming workstation will have two monitors and two sets of keyboards and mice. Another reason is that they cannot check their e-mails and such when they are at another person's desk.

So, TDD and pair programming require a real cultural shift and encouragement from the top down. Usually the project managers and architects will have to force the issue.

However, most people do not understand the benefits of these XP practices and the tendency of managers is to think pair programming will require twice the number of programmers to accomplish the same amount of work. I would simply counter that if pair programming requires more developers, why is it that XP projects usually have less devlopers as per the argument that it doesn't scale well to large projects?

The fact that XP requires team members to work more closely together should not be a cause for concern. The word "scrum" is a term borrowed from the sport of Rugby. Unfortunately, the way software development usually works with the Scrum methodology is that team members get together for the daily scrum, sprint planning meeting, etc. However, then they are sent out to work independently on their assigned tasks as if they are not part of a team. The result is that the success or failure of the iteration becomes dependent upon the weakest link.

I believe that XP teams can accomplish much more with far fewer people with less risk, and it is entirely possible to do both Scrum and XP so that you receive the benefits of both. Companies could save a lot of money if they would really embrace the XP practices, but in all honesty it is not the easiest path.