For the past few weeks, the summer interns at Fog Creek Software have been blogging about a top secret product they're building. Recently, on the JoS boards, someone revealed what the top secret project is: a remote PC assistance tool. Since I have nothing better to do with my life, I am practically compelled to write about it here.
Assuming this is not a hoax (and really, I have no idea), the idea is that you'd pay $9.95 for a day pass to this service, and once you've paid, you'd use the service to allow your techie friends to remotely fix your PC. There are a lot of products already like this, and I'm sure that other folks on the web are hashing out the weak points even as I speak. That's not what I want to do; instead, I'd like to point out an opportunity for a great feature.
Like a lot of other technically inclined folks, friends and family often ask me to help fix their system. Usually, they've done something silly, like replacing their video card with a grilled cheese sandwich. Usually I say no, just because there's nothing in it for me. There are absolutely no incentives to helping stupid people with their computers for free. If Joel wants people to use this service, he should include a method to compensate the person doing the work.
Rather than the service costing $9.95, it could cost $9.95 plus $X, where X is set by the technician in advance. (It'd be neat if, rather than depositing the money in your bank account, you could donate it to charity.) Suddenly, an incentive appears for me to help these people with their problems. Not just help to them, but to through one and only remote assistance tool. It's money for the company, money for me, and a functioning PC for the user. Repeat that enough times, and you'll have people dancing out in the streets in their underwear.
You could even take that one step further, and set up a marketplace where individuals would offer their time, and non-techies could read their reviews and then chose accordingly. There are lots of intriguing possibilities here. I think if you want something to catch on, there must be a compelling reason to use it. This definitely qualifies as one to me.
Last week, I went to the UML and Design World conference here in Austin and I completely forgot to write about it. Allow me to address this grievous error!
I only went to the conference for two days. This was not so much because I was busy, but more because a man can only handle so much UML. Once you subject yourself to an entire day of the stuff, you need some time off, lest you find yourself babbling about class diagrams on the roof of the post office later that evening. But I digress.
Alright, so the first day, the sessions I went to were both led by Robert Martin of ObjectMentor. The sessions were on Mastering Design Patterns and Advanced Principles of Object Oriented Design. The first session was great, with a lot of specific examples and implementations of design patterns, and I think I got a lot out of it. Also, he was a great speaker and a lot of fun to listen to. I also got a lot out of the second session, though not what one might expect. In that session, Mr. Martin presented some interesting ideas on OOD that riled a large part of the crowd. As one might expect at a UML conference, a few members of the audience turned it into a shouting match. The lesson from that particular interlude is to never let myself become one of those people. I'll save my shouting matches for important occasions, like when the cashier at HEB refusing to honor my Hot Pockets coupons.
I then skipped a day, and attended again on Wednesday. Then, I sat in on the Practical Application of User Interface Architecture Design Patterns (Underbakke), Estimating Effort Using Use-Case and UML Class-Method Points (Roetzheim), Documenting and Analyzing Enterprise Architectures (Vilot), and Managing and Measuring Functional Requirements (Herron). Factoring in all of the conferences across the entire universe, that may be the nerdiest slate of classes possible. Honestly, I was a little disappointed with these.
It seemed that some of the speakers were more interested in selling me their product/services or trying to impress upon me their credentials than they were in showing me a good way to solve problems. The exception here was Bobbi Underbakke's session on UI Design Patterns. He presented a really neat methodology for decomposing UI design, and I am glad I attended. The others? Ehhhh. At the very least, I had a really good turkey sandwich between the second and third speakers, so it's not like it was a total wash.
If you ask me, the only downfall to attending a conference like this is how specific it is. Since the topic is so slender, the speaker can lose the audience very quickly when they delve into the very specific. Since the topic is so well defined, any disagreements or debate can veer off into trivia very quickly. To illustrate, I need only ask you to imagine the sort of arguments one might hear at a conference devoted to Smokey and the Bandit 2. It doesn't take too long for those to go from amusing to infuriating.
Nevertheless, I had a good time and hopefully honed the skillset a bit. Even if I didn't, well, there's still that turkey sandwich.
Lest anyone ever accuse me of arrogance, let me declare it flat out: I don't understand structs. Not in C#, at least. One of the standard interview questions for a C# developer is to name the difference between a struct and a class. That's easy; a struct is a value type, a class is a reference type. However, the implications of that are totally mind-boggling. I learned this first-hand with an interviewee earlier today.
When I asked him that question, he gave the right answer. He went on to say that one interesting thing about structs is that you can't compare them with the == operator. I smiled and nodded at the time, but later on after the intervew, I began to think about it. A struct is a value type, just like an int. Both are created on the stack, and when you manipulate either, you're manipulating the direct instance, not a reference to it. I understand all of that, and I also know that you can use == on two ints. Why not on two structs then? Wouldn't you just go to the stack and compare them on a member-by-member basis?
I went around and asked a few folks. To protect the guilty, I will say that Coworker X saw my point, while Coworker Y decried us both as morons. "Ha ha," we cried haughtily, "we'll show him!" And so we promptly worked up a quick example, only to promptly be proven incorrect. I sank to my knees and cried at the heavens, "What the fudge?"
To complicate matters, structs inherit an Equals method from System.ValueType (I think) and that Equals method seems to work exactly as I thought the == operator would work. So what gives? Why does one work and not the other? Anyone, anyone? I am lost on this subject and I am in desperate need of guidance.
I was recently signing up for an account on groups.msn.com (mainly so I can participate in the ADNUG discussions held there. Well, I had to select a nickname to go by on their boards. My first choice was CodyP.
I plugged that in, hit Submit, and the site came back, saying that CodyP was already taken. Was I interested in one of the following?
WearableCodyP
DementedCodyP
FlabbiestCodyP
Uhh, no thanks. I tried Codypo, and here's what it suggested.
BroodyCodypo
CagiestCodypo
DuckyCodypo
ArchaicCodypo
My question: what's the algorithm like that derives these names? Is it possible that all it's doing is searching a dictionary, finding a ridiculous adjective, and then appending that to your name? Does anyone know how it actually works?
Good gravy, do I have a debugging tale to relate to all of you! If that's not a way to get an audience revved up, I don't know what is. I maintain some legacy code at work, and we were recently going through the last round of bug-fixes on it. I applied the fixes and tested them out on my machine, and it worked pretty well. Pretty well, of course, because it's legacy code and there's always one or two things in legacy code that make me stop and say, "Wait, do what now?" Anyway, shortly thereafter, I sent it to the tester so he could look at it. Immediately after he ran it, the entire thing exploded spectacularly.
Basically, the code interfaces through the serial port with these little manufactured devices; you use the code to transmit commands to the device. Well, when the tester began running the app, he noticed that one specific function didn't work for one specific device. If he tried another one of the devices, it worked just fine. I tried it out on my machine, and everything worked for both devices. I knew he wasn't just inventing the bug, so it was at this point I became very, very scared.
After tinkering for a little bit, we both huddled around his machine, hooked up the problematic device, and ran the code in the debugger. Surprise, it worked just fine. However, if I compiled the EXE and put it in another directory, it wouldn't work. I was now completely confused. Unless a master genius was at work, it just didn't seem logical how such an error could exist.
We butted our heads against this for hours. We had an idea of where the error was occurring, since we both knew the flow of the program. Knowing that, it was still very difficult to proceed, just because the code is so complex. What made it all the worse was that we couldn't step through the code in the debugger because the damn thing worked in the debugger.
What I chose to do was to open up the code and insert lots of sequential print commands (ie, lines like "Test 1", "Test 2", "Test 3"). Onced I compiled the EXE, moved it to the directory, and ran it, I began to see where the problem was occurring. Slowly, over hundreds of these statements, the noose tightened until I could figure out what the issue was. It definitely wasn't quick, but it proved to be effective.
It turned out that the error was in a function that I was completely unfamiliar with. Each time the app interfaced with one of these devices, it wrote a line out to a text file just for that device. For some reason, it wrote that line incorrectly once in the cursed directory and could never read from it again. That error, once found, was completely consistent with the situation we faced: it only happened on his computer, in one directory, with one particular device. It didn't happen in the debugger because the debugger was working from a different directory. Duh!
Had it not been for the hundreds of sequential print statements, I've no idea how we could've solved this issue. Sometimes, when our tools are limited, you can fix bugs like you fire a cannon. Shoot once above it, shoot once below it, and then adjust your scope accordingly.
Today at work, I was browsing Slashdot when I saw a story on a self-replicating, rapid prototyping robot. When I read it, I instantly thought back to the Intro to Astronomy course I took in college. Taught by the esteemed Gordon MacAlpine, he devoted a day to crackpot UFO theories. One of them was that advanced alien life does not exist because if it did, space would be filled with these exploratory, self-replicating agents sent out by these other civilizations. I remembered the theory just because it was so bizarre, but I had no idea what the terminology was.
Let's fast forward a few hours. It was only through consultation with well-informed coworkers I was able to stop screaming "AHHH!! ALIEN INVASION!" and start screaming "AHHH!! VON NEUMANN PROBE!" And they say a liberal arts education is wasted on a code monkey. Pshaw!
Two weeks from now, the Paddington Bear and I are going to the UML and Design World Conference being held here in Austin. Wahoo! I've never been to a fancy conference before; I've got the cumberbund at the cleaners now so I'll fit in with the rest of the luminaries. I'll be hitting up Mastering Design Patterns and Advanced Principles of Object Oriented Design in UML on Monday; I'm not sure yet about the other days. If you'll be there, just look for the guy in the aforementioned cumberbund, walk up to him, and give him a bag of money. It's that easy.
The cool thing about it is that we're being sent by our employer to gain skills we'll soon get to implement on our Project Tremendous. I won't get into all the deals of Project Tremendous except to say it's a huge application that we're rewriting. I've been doing the functional requirements on it for months now, so I'm grasping onto any signs of the approaching design phase like the last tatters of life itself. Requirements analysts, I salute you. That stuff is neither easy, nor fun.
Anyway, I'm looking forward to it. Both patterns and UML are interesting subjects, but they're difficult to grasp in a casual setting. That's not to say they're particularly complicated, they're both just abstract concepts that require a lot of attention. Hopefully by devoting several hours to the subject, my design-fu will increase geometrically. Maybe after the conference itself, I'll do a little write-up here. We'll see.