The world of display adapter types is an alphabet soup of options today. HDMI, DVI, VGA, UDI, DisplayPort? Which will become the standard in the next few years? HDMI looks like a sure bet in the consumer electronics space but it is failing to make inroads into the PC world yet. DVI is the leader today and UDI and DisplayPort are both making a run for the crown. ExtremeTech has a good article talking about each of the standards and their likelihood of becoming the overall leader. Their quick take on the situation: "With DVI so prevalent and UDI and DisplayPort on the verge of crashing the display party, it's unlikely that HDMI will become more than a footnote in the epic story of PC display technology."
Tuesday, February 13, 2007
Hiring Great Testers - How Important Is Testing Affinity?
When it comes to the increasingly important role of test developer, hiring managers have a choice to make. They must decide what is the controlling criteria for hiring. Which is more important, testing skills or development skills? Sure, you want both to be strong but often times, you don't get a perfect candidate and are forced to compromise. If you have to choose one skill as the more important, which should it be? There is no universal answer. Each situation will vary. However, it is my assessment that you are often better off hiring a good developer and teaching testing skills rather than hiring a good tester and trying to teach development skills. The reason for this is largely this one belief: it is easier for the average developer to learn to test than for the average tester to learn to develop.
When I say developer, I don't just mean someone who knows the syntax of a programming language but rather someone who really understands programming. That is, someone with computer science competencies. This is not necessarily someone who has a CS degree. The person can be self-taught, but they need to understand the sorts of things computer science students learn. They need to have familiarity with data structures and algorithms. They must understand complexity issues. They should be familiar with operating system concepts including concurrency. For a modern programmer, experience with object-oriented design principles is also necessary.
Two critical traits all testers must have to pay attention to details and being curious. A tester needs to be thorough. They cannot afford to leave any stones unturned in their quest to explore the product. Good testers also need to be curious. They need to have an instinct where to look to find the issues. They have to want to experiment.
Let us think about most developers. Are they detail-oriented people? The good ones are. Code is unforgiving. If you don't pay attention to details, your program will misbehave or even crash. Are they curious? More often than not, curiosity is what brings someone into programming. Is it the sense of exploration and later mastery that drives most of us forward. It would seem then that good developers have the basic traits to be good testers.
What about the average tester? Here I'm not talking test developer but rather someone who is less skilled in programming. Do they have what it takes to make a good developer? There is no way of knowing. While curiosity and thoroughness are traits most developers have, those are not sufficient traits to be a good programmer. To be the best programmer one must be a good problem solver. One must also be able to think in very abstract ways. Most good testers are also good problem solvers. However, I'm not convinced that there is a correlation between abstract thinking and testing. Testing can be done in a very concrete manner. Many who make good testers do not have the ability to become great programmers. It is often this trait that is missing.
Now let us consider the specific skillsets required for testing and programming. It is argued that testing is just as difficult as programming. That the skillset required is equally deep and varied in manner rather than scope. I reject this notion.
It's not that I think testing is easy. It isn't. I've interviewed many people who don't have what it takes to be a good tester. They have the wrong mindset. They aren't curious or thorough enough. Sometimes they just don't really grok computers. Often times the higher level skills in testing are enumerated to prove the difficulty. These include things like understanding equivalency classes or pairwise testing. The thing is, I've never found these to be too difficult to understand. Equivalency analysis--despite its fancy name--is something any competent tester should just intuitively understand. Pairwise testing is more complex but is something any CS student should be able to understand quickly. There is a lot of art in successful testing too. This can take a long time to develop well. The average developer isn't going to be a great tester overnight.
How about programming? How easy is it for the average tester to pick it up? As I argued above, good programming is not just knowing the syntax. I like to use the concept of writing to prove my point. Knowing the syntax of a programming language is like knowing grammar. You can correctly form sentences and can most likely convey your point to the audience. However, knowing grammar does not make you a good writer. What sets Mark Twain apart from your typical math student is not just a superior knowledge of grammar and vocabulary. It is understanding the larger process at work. Likewise, knowing the syntax of C++ or Java doesn't make for a good programmer. One merely needs to watch The Daily WTF for a short while to understand why such thinking can cause enormous trouble over time. It takes a long time and a lot of hard work to go from being someone who understands syntax to someone who can truly weave code.
Thus I think the gap between a tester and a developer is harder to cross from the tester side than from the developer side. A developer can become an adequate tester well before a tester can become an adequate developer. Given the choice between someone who is a good developer and someone who is a good tester and each lacking much skill in the other discipline, I'll take the developer nearly every time.
As always, your mileage may vary. There are some testers who go on to make amazing developers. There are developers who cannot grok testing. There are some jobs where you don't really need good development skills. Sometimes a person who understand syntax is enough.
That's my take anyway. Release the arrows.
A few related articles are Chris McMahon's discussion of developer-testers vs tester-developers. Also Elisabeth Hendrickson has a great post about the convergence of testing and development.
Saturday, February 10, 2007
Programmer Humor
A friend turned me onto this online web comic called XKCD. Some parts are really funny. Others, quite lame. Anyway, here are some of the funnier ones from a programmer's viewpoint:
Thursday, February 8, 2007
February Netcast Update
It's been a while since I posted my list of netcasts. I've had less time of late to listen to netcasts so my regularly scheduled netcasts have dwindled. Here is a list of those I listen to on a regular basis:
This Week in Tech - Leo Laporte hosts a roundtable discussion of the news of the week. Great one-stop-shopping for all noteworthy tech/geek happenings.
This Week in Media - Content creation and politics. Everything from discussions of DRM to the latest news about the Red camera.
Windows Weekly - Really more like Microsoft Weekly. Despite working here, there's a lot I don't know about. It's also fun to hear someone else's perspective on what we do.
The HDTV Podcast - The latest in HDTV news and equipment reviews. Only 1/2 hour.
A few notable mentions that I listen to when I have extra time:
The Dice Tower - Best board gaming netcast I've found.
Security Now - The world of computer security in layman's terms.
What Is Your Greatest Weakness?
If you've interviewed much, you've probably been asked this question. Art Vandalay examines some of the potential answers and their outcome on his blog. There's also an interesting conversation in the comments over there. The consensus of those being interviewed seems to be that it is a no-win question. The managers seem to find it useful. Which is it?
I've spoken to people who use this question and asked them what they get out of it. Their answer is usually "You'd be amazed what some people will say." True, but if they're really that badly behaved and that intelligent, couldn't you find out some other way? If you ask a question only to weed out the most incompetent, perhaps there are better uses for that time in the interview.
I see little value in this question. As Art points out, there are four possible answers:
- Lie/Evade - Claim you have no weaknesses or attempt to change the subject.
- Answer with a weakness that is really a strength - Say something like "I am a perfectionist"
- Honesty - Answer with your truly biggest weakness.
- Wiggle out - Give a true weakness but only a very mild one.
Given these 4 choices, the best possible answer is #4. The first will often upset an interviewer looking for "honesty". Unfortunately, this question is designed to get you to be dishonest so the interviewer should avoid the question. The second is lame and probably runs into the same problems as #1. The third will probably end the interview. Everyone has weaknesses and without context, your biggest weakness will often dominate the mind of the interviewer. Game over. The fourth has some honesty to it but isn't enough to get you thrown out of the interview room.
As an interviewer, I don't want to put my future employees in a position where they are struggling to find the answer I want to hear rather than the truth. Why should I put them in a position where lying by avoidance is the best answer?
What are your thoughts? Is there value in this question?
Sunday, February 4, 2007
The Sorry State of HD Television
I attended a Superbowl viewing party at a friend's house today. No, the screen wasn't larger than 55" so the NFL doesn't need to worry. I don't happen to have an HDTV at home yet so this is one of the few times I've seen the programming. What I saw doesn't make me want to run out and buy a set and upgrade to HD cable anytime soon. Sure, HDTV can be beautiful. We've all seen the 1080i demos running at the stores. It's gorgeous. The XBox 360 looks very beautiful on an HD set also. HD-DVD (and to a lesser extent, BluRay) also look beautiful. Serenity if HD is a wonder to behold. However, television--at least via Comcast cable--still isn't there. The content is often over-compressed and there seems to be no real desire to get it right.
I saw two football games in HD this year. The first was the NBC broadcast of the Seattle-Dallas playoff game. The quality of the video was terrible. When the picture was still, the quality was quite good. However, as soon as it started moving a little (which it tends to in football), the quality fell through the floor. There were all kinds of compression artifacts to be seen. The picture looked very muddy. I can't quite tell what the problem was but I suspect that someone was compressing the signal too far save bandwidth. The graphical cuts were, however, quite gorgeous. Still, this was definitely not something I'd go out of my way to experience.
The second game was today's Superbowl. This one they seemed to have good footage of the game. The pictures of the field were full of detail. No muddying here. However, whenever they overlayed graphics, they were upscaled SD pictures. Whether the picture was a cut scene, an overlay with a picture of a player, or even the score, the contrast in quality jumped right off the screen. The edges were blurry and there were obvious scaling artifacts. How anyone could let this happen in the Superbowl is beyond me. How hard can it be to author the graphics in HD and downscale them for SD? Several of the commercials too were upscaled 480i video and it showed. Why you would spend $2.6 million for a Superbowl commercial and then make the video look bad for your most affluent audience?
If they can't get the NFL playoffs and especially the Superbowl right, what does that mean? It means that it isn't worth their time. If it were, they wouldn't let this kind of garbage show on the air. HDTV is still very much in its infancy still. Too bad. I was hoping it would be better by now.
Saturday, February 3, 2007
Why Writing Software Is Hard
Scott Rosenberg just published a new book called Dreaming in Code about a project to create a new personal information manager called Chandler. As many software projects, this one is late. Rosenberg was recently interviewed about the subject of software projects falling behind. He has some interesting thoughts on the issue.
Are projects like Vista just poorly run projects? Were they late because they were undisciplined? Or was there something else at work? Rosenberg doesn't give a clear answer but he does seem to indicate that it's impossible to estimate software times because it has never been done before. He says,
"[A]s long as you are not trying to do something new -- if you are doing something that has already been done -- then you have a frame of reference to estimate how long it is going to take, and to guess how many people are going to be required, and so on. And of course in other fields of engineering where we do the same thing over and over, the same is true. If we are going to build a house, there are always imponderables, and every site is different, but you have a rough idea: two-story house, and such and such a set of features, it is going to take a certain amount of time."
This is true. If you've done it before, you can probably estimate it. However, if you haven't done it before--and with software you probably wouldn't be writing it if you had--there is really no way to accurately know how long it will take. I think this is largely true, as I have argued elsewhere. Software is unforgiving (the reason for most security holes). Writing a program is more like research than simple engineering. No one blames Monsanto for being late developing a cure for cancer (that I know of anyway) but Microsoft gets killed for being late with Vista. Part of that we, as programmers, bring on ourselves. To be a good programmer means you are smart. Mere mortals often have a difficult time understanding how to write even simple programs. Because of that, we often times overestimate our abilities and underestimate the size of the problem. We don't have the information to make an accurate calculation but we refuse to admit that. Instead, we insist that everyone else trying to write software was just undisciplined and that we can do it better. Unfortunately, we can't.
My takeaway from all this: don't try to estimate the whole project up front. Stay agile. Come up with a list of work and churn through it at whatever rate is possible. Have lots of checkpoints and don't be afraid to change your plans.
Subscribe to:
Posts (Atom)