An old friend emailed me to ask:
“I wanted to get your response to some basic questions concerning technologies available for creating an enterprise level application that is built upon a Web Server, Web based applications, and a large distribution model and collection model. The project is starting from scratch and so there is no legacy code involved but other than that I won't bore you with the details...
“Would you head down the .NET route or J2EE?
“Which Web Server (Apache, IIS, or something else) should we use and why?
“Which Web development language (ASP.NET, Ruby, Ruby on Rails, Java, Python, etc.) would you recommend and why?
“What do you use at your company and why?”
Ah, an excellent question, simultaneously impossible to answer and very easy to answer!
Sorry, I should stop speaking in riddles. A while ago I wrote an article called Lord Palmerston on Programming in which I claimed that some of these programming worlds, like .NET and Java, were so huge and complicated that you never could really tell if they were going to be good enough for your needs until it was too late. In particular, a debate between the C#/.NET/IIS stack and the Java/J2EE/Apache/Solaris stack and the PHP/Apache/Linux stack could go on and on for years and years and you'd never find the right answer. That's because there are so many pros and cons of all these platforms that advocates of each side can debate and debate and never get any closer to the Truth, but it sure as heck is a fun debate.
You might think that if you could find someone with extensive experience in multiple platforms, they would be the right person to ask. I haven't found a lot of people like that. What I do know for sure, though, is two things:
Last summer when we had a group of interns build Copilot, we had to decide what language to use for new code. I know that typically on new projects there's a long evaluation period where you decide what technology to use, along with lots of debates that include some crazy person actually wasting quite a lot of time evaluating Squeak and Lisp and OCaml and lots of other languages which are totally, truly brilliant programming languages worthy of great praise, but just don't have the gigantic ecosystem you need around them if you want to develop web software. These debates are enormously fun and a total and utter waste of time, because the bottom line is that there are three and a half platforms (C#, Java, PHP, and a half Python) that are all equally likely to make you successful, an infinity of platforms where you're pretty much guaranteed to fail spectacularly when it's too late to change anything (Lisp, ISAPI DLLs written in C, Perl), and a handful of platforms where The Jury Is Not In, So Why Take The Risk When Your Job Is On The Line? (Ruby on Rails). Before you flame me, Ruby is a beautiful language and I'm sure you can have a lot of fun developing apps it in, and in fact if you want to do something non-mission-critical, I'm sure you'll have a lot of fun, but for Serious Business Stuff you really must recognize that there just isn't a lot of experience in the world building big mission critical web systems in Ruby on Rails, and I'm really not sure that you won't hit scaling problems, or problems interfacing with some old legacy thingamabob, or problems finding programmers who can understand the code, or whatnot. So while Ruby on Rails is the fun answer and yes I've heard of 37 Signals and they're making lovely Ruby on Rails apps, and making lots of money, but that's not a safe choice for at least another year or six. I for one am scared of Ruby because (1) it displays a stunning antipathy towards Unicode and (2) it's known to be slow, so if you become The Next MySpace, you'll be buying 5 times as many boxes as the .NET guy down the hall. Those things might eventually get fixed but for now, you can risk Ruby on your two-person dormroom startup or your senior project, not for enterprisy stuff where Someone is Going to Get Fired. Python get a half because it's on the border, about to cross the line from an "interesting" choice to a "safe" choice.
Oh and I know Paul told you that he made his app in Lisp and then he made millions of dollars because he made his app in Lisp, but honestly only two people ever believed him and, a complete rewrite later, they won't make that mistake again.
The safe answer, for the Big Enterprisy Thing where you have no interest in being on the cutting edge, is C#, Java, PHP, or Python, since there's so much evidence that when it comes right down to it zillions of people are building huge business-critical things in those languages and while they may have problems, they're not life-threatening problems.
How do you decide between C#, Java, PHP, and Python? The only real difference is which one you know better. If you have a serious Java guru on your team who has build several large systems successfully with Java, you're going to be a hell of a lot more successful with Java than with C#, not because Java is a better language (it's not, but the differences are too minor to matter) but because he knows it better. Etc.
What we ended up doing with the interns was just telling them that they had to build it in C# and ASP.NET. In particular, one intern, who wrote the website part of Copilot, had enough experience with ASP.NET to know what things to avoid (like viewstate) and knew to avoid the gotchas that make it impossible to have two <forms> in one page, etc. etc., so he did a beautiful job architecting the ASP.NET code exactly the right way to begin with so we didn't get into trouble later. And the benefit was that not one minute was spent debating the merits of programming languages, a fruitless debate if I've ever seen one.
I think some people thought I was joking earlier today when I said that we have our own compiler, Wasabi, for FogBugz.
Yes, Wasabi is real. Because FogBugz is sold to customers who run it on their own servers, it has to run on hundreds of thousands of web servers "in the wild," unlike most web apps where the programmer completely controls the deployment environment. We have to ship code that runs out-of-the-box, which means lowest common denominator.
This is kind of unusual. Most web developers are either building things for one customer, or they're building web apps that they will host themselves. That's a nice position to be in. But most FogBugz customers don't want their proprietary project data on someone else's servers, so we have to sell them the source code to install on their own server.
In most deployed servers today, the lowest common denominators are VBScript (on Windows), PHP4, and PHP5 (on Unix). If we try to require anything fancier on the server, we increase our tech support costs dramatically. Even though PHP is available for Windows, it's not preinstalled, and I don't want to pay engineers to help all of our Windows customers install PHP. We could use .NET, but then I'd have to pay engineers to install Mono for all our Unix customers, and the .NET runtime isn't quite ubiquitous on Windows servers.
Since we don't want to program in VBScript or PHP4 or even PHP5 and we certainly don't want to have to port everything to three target platforms, the best solution for us is a custom language that compiles to our target platforms.
Since we are not blub programmers, we like closures, active records, lambdas, embedded SQL a la LINQ, etc. etc. and so those are the kinds of features we put into Wasabi.
And since FogBugz goes back many years and was originally written in VBScript, Wasabi is 100% backwards-compatible with VBScript but includes obvious improvements. """Multiline strings.""" Dim a = 0. And so on.
Most people don't realize that writing a compiler like this is only about 2 months work for one talented person who read the Dragon book. Since the compiler only has one body of code to compile, it is much easier to write. It doesn't have to be a general-purpose compiler. It doesn't have a math library, for example.
And we have the ability to add any feature to the language that we want easily... this is the same power Paul Graham talks about in On Lisp, the power to invent new language features that suit your exact application domain. Lisp does this through a mechanism called macros.
It's very easy to add a new back-end to Wasabi. Our plan is that when .NET gets a little bit more predominant on our clients' Windows servers, we'll add a CLR back-end and generate bytecode or something which will run a lot faster.
That said, there are major drawbacks. The documentation is a little bit thin and disorganized, because we've only documented the diffs to VBScript, not the whole language. Programmers that join Fog Creek might take a little bit longer getting up to speed. Our edit-compile-test loop got slower because there's one more step.
Should you write your own compiler? Maybe, if you're doing something that's different enough from the mainstream and if there's no good off-the-shelf technology for your problem. There's a good chance that the domain you're working in could really use a domain-specific language. If you want to write a program for filling out tax forms, for example, you probably want to create a language optimized for describing forms with calculated fields, and then all you have to do is encode each tax form in your custom language. If you want to write a program for playing a 3D game, you'll want to create a language optimized for describing maps and levels and then design each level in that language. If there's something off the shelf you can use, by all means, use it, as long as you're not going to get yourself in trouble down the line when you discover that that the off-the-shelf tool doesn't work and you can't modify it.
Tomorrow's Cornell speech is at 5pm in Phillips 203.
August is the month where everything screeches to a halt. So many people are away on vacation that the people who are left behind can never get ahold of the people they need to do their own work.
But, alas, August is over. Labor Day weekend, which just ended, marks the traditional end of summer vacation on the American calendar. So today, I'm opening a new section on Joel on Software, a jobs listing page creatively named jobs.joelonsoftware.com.
The idea of a niche job board was not my own, and it has taken me a while to figure out why this is a better idea than those huge job boards bringing millions of companies together with millions of job seekers. A niche job board has modest goals, no grander than to bring a dozen or so companies that are great places to work together with a dozen or so great programmers.
The traditional way of applying for a job, sending a cover letter and a resume, just does not give the employer enough useful information to separate the "maybes" from the "maybe nots." Many employers despair of placing a job listing on Monster or Yahoo! HotJobs or Craigslist and getting the inevitable flood of undifferentiated resumes.
For the job seeker, the problem is the same: when they look on giant job boards they see a bunch of undifferentiated jobs, often posted by clueless headhunters that provide all kinds of information you don't need ("A leading provider of whatever") and none of the information you do need (what's the name of the company? Do they make nuclear bombs? Will they give me a private office and a big monitor? Free M&Ms? Are they sloppy hacks or quality hackers? Can I use Ruby on Rails?)
So it seems to me that both the employers and the job seekers would be better served by a quiet, more exclusive club with a few select listings that tell you the actual name of the company you'd be working for, and, if you're lucky, how they did on the Joel Test, combined with a community of the best software developers on earth, that being you.
And, yes, it's not for everybody, and no, you won't see ads on the sides of buses for jobs.joelonsoftware.com, but you will find great jobs and great programmers there.
That's the theory at least. There are a lot of these niche job boards showing up. 37signals has one with an emphasis on web design jobs. CrunchBoard is all about Web 2.0 jobs. There's even a company called JobThread that offers tools to set up your own niche job board, which Salon and others are rolling out. Do we need a scrillion tiny job boards? I'm not sure, but I do agree with JobThread's Eric Yoon that "while the big three job boards have 70% of the $2 billion online recruitment ad market, recruiters and companies have been fairly unhappy with their job posting experience."
Jason Fried over at 37signals has been evangelizing the idea. "Big sites take a shotgun approach. You post a job. Anyone can see it. There's no targeting, no like-mindedness. Our feeling is, if you want to hire the right people, you have to go where the right people hang out."
Credit also goes to Fog Creek summer intern Noah Weiss, who just would not shut up about job boards this and job boards that until we agreed to try it out. And to all my friends through the years who regularly pestered me to help them find great software developers for them among the regular readers of Joel on Software.
Now, for some details. In order to keep the quality of the listings high this is not going to be a free job listing board. Listings cost $350. That only gets you three weeks; my theory is that nobody wants to apply for stale jobs, anyway. Unlike every other job board I know of, I've decided to keep Fog Creek's usual 90 days, no-questions-asked money-back guarantee. If you don't find anyone, you can have your money back. If you find someone but they quit to join the Bolshoi you can have your money back. If you get a bunch of lousy resumes, you can have your money back. If you hire someone and they turn out to be really, really attached to their cat who comes to work with them and makes Lizza in Accounts Payable sneeze so hard that she goes to an allergist driving up your health insurance premiums, well, you should have asked them about cats in the interview, but, yeah, you can have your money back.
If you're a legit charity or educational institution, contact the kind customer service people (yes, there's customer service, with a toll-free phone number) and they'll work something out.
Now, about the rule we made that you have to post the company name. A lot of recruiters are working on a contingency basis. They don't get paid unless they fill an opening. These recruiters generally don't want to post a company name, because then applicants could go straight to the employer and the recruiter would be cut out of their commission. That's why you see so many job ads in traditional places like classifieds that are totally vague about the specific company where you'd be working.
That, unfortunately, is not going to work for us. Every good software developer I know has a choice of where to work. They don't want to work for a "TOP INVESTMENT BANK". Some investment banks are really nice places to work. Others are sweatshops. Some are ethical. Many are ethically challenged. Some require suits. Others are business casual. That's why we want to know the name of the company that's hiring, and unfortunately that means that recruiters who don't want to reveal the company name are really barking up the wrong tree. Try Craigslist, shugah.
Starting today, there are going to be small text links to the job board showing up in various places on the site. I'm going to experiment with showing one random job listing on the home page of Joel on Software, and links will be included in the discussion board, the RSS feed, and the email list. Also, there will be a gigantic flashing dancing hamster that appears on the home page singing the flashing hamster song and holding up a sign proclaiming the job board, and you have to find his little hat and click on it before you can go on.
Just kidding about the hamster.
Right now, as you can see, the software behind jobs.joelonsoftware.com is quite rudimentary. Yes indeedy what you're seeing here is AGILE DEVELOPMENT IN THE WILD! Noah and I designed and coded the whole site over the course of three weeks, which included two weeks of vacation--each. There's no searching or sorting feature. There's no easy way to post several jobs at once. I want to see how it goes yet, see if we get any interest, and mostly see if the revenues generated by this thing would support a programmer to make it better.
In honor of the new job board, I'm working on a series of articles which will collectively be known as The Guerrilla Guide to Hiring.
The first article, Finding Great Developers, is up now.
Quick reminder if you're near Cornell: my speech is Wednesday at 5pm, in Phillips 203.
“So my experience has been that a number of excuses all pile up until it’s virtually impossible to get private offices for developers in any but the most enlightened of companies, and even in those companies, the decision of where to move and where people should work is often taken once every ten years by a committee consisting of the office manager’s secretary and a junior associate from a big architecture firm, who is apt to believe architecture-school fairy tales about how open spaces mean open companies, or whatever, with close to zero input from the developers or the development team.”
-- from today's installment in the Guerrilla Guide to Hiring: the Field Guide to Developers.
It was only a matter of time before the new job board got its first policy violation: a recruiter posting a job without disclosing the name of the company that it was for.
The reason we require a company name, as opposed to a recruiter's name, is because I think that job seekers are sick of looking at generic lists of seemingly anonymous companies. The reason recruiters don't like to post company names is because they don't get a commission unless they refer the employee, so they don't want to take any risk that the candidate will go directly to the company and cut them out of their commission. Also, once the recruiter establishes a relationship with you, they can convince you to apply to all their other jobs, further increasing the chance that they'll get a commission. And they want to build up their resume-files so they can do their job well in the future.
There's a place for recruiters; many of them are very ethical and do great work for their clients on both sides. However, I think there's also a place for a more open market where people can look directly at jobs, then jump to the company's website and decide if that's the kind of company they might want to work for. As I wrote earlier, top developers have a choice of where to work, and they're not very enchanted with the prospects of working for a "leading developer of software products" that needs a "C/C++/XML/HTTP/HTML" to fill a slot.
This is something of a dilemma. I'm pretty sure that job seekers have no interest in a seeing list of pseudo-jobs that are often nothing more than invitations to call a headhunter. On the other hand, headhunters are probably the biggest single spenders on job boards, so I might be antagonizing my biggest potential audience of paying customers.
Wow, I have never seen such developers all over the world so unanimous on any issue. If anything, I underestimated how much people hate job boards clogged with anonymous posts put up by commission- and resume-fishing recruiters.
The jobs board policy will remain: We will continue to require a company name and take down posts that don't disclose the actual company.
Recruiters can use it if they post the name of the company that is actually hiring. This, I think, will only be of interest to recruiters doing exclusive searches (also known as "retained searches").
Finally, summer intern Noah has added a feature to display the Joel Test score on the main page for companies that choose to fill it out, which seems to be quite a lot of them. Thanks, summer intern Noah!
“To top programmers, the most maddening thing about recruiters is their almost morbid fascination with keywords and buzzwords. The entire industry of professional headhunters and recruiters is bizarrely fixated on the simple algorithm of matching candidates to positions by looking for candidates that have the complete list of technology acronyms that the employer happens to be looking for. It becomes especially infuriating to realize that most of these recruiters have no idea what any of these technologies are. ‘Oh, you don’t have MSMQ experience? Never mind.’ At least when real estate agents prattle on about Subzero refrigerators and Viking stoves, they at least know what these things are (although any stainless steel refrigerator counts as ‘Subzero’ these days). The easiest way to catch-out a technical recruiter is when they inevitably insist on 5 years of experience with Ruby on Rails, or refuse to consider someone for a ‘Windows API’ job when they only have ‘Win32’ on their resume.”
-- From today's third and final installment in The Guerrilla Guide to Hiring, Sorting Resumes.
If you are trying to install Windows Vista RC1 in VMWare Workstation, you may see setup appear to hang on the text-mode screen that says "Windows is loading files...".
Actually what has happened is that Vista Setup is already in graphics mode trying to do things, but something about the way it switches the display adapter into graphics mode is not working right on VMWare.
If I were VMWare I'd be pretty ticked off at Microsoft right now; since Microsoft makes a competitive product, Virtual PC, it is Highly Suspicious that they come out with a major new test release of an operating system that just happens to not work on VMWare Workstation, something which is practically the de facto standard for developers testing new operating systems. Shabby and slimy, Microsoft. They're probably testing Windows Vista with tens of thousands of applications; not testing with VMWare is inexcusable.
There's a workaround, for now, while VMWare works on the problem: edit the virtual machine's .vmx file to include
svga.maxWidth = "640"
svga.maxHeight = "480"
You can get Vista installed in VGA 16 color 640x480 mode (it will look awful) and then when you get everything running, install VMWare tools and take out those two lines and you'll be good to go. Thanks to anonymous user echelon9 from the VMWare board for this tip.
I'm assuming that the Aero/Glass UI's heavy demands on the graphic card may mean that it can't be tested under VMWare, but I'd love to be wrong.
Last year we set the application deadline for internships to February 1st, which was fine, and the deadline did a good job of forcing students to get off their butts and apply, but we made the mistake of not considering applications until they were all in, which we thought would be most fair. It was fair, but it also meant that by the time we even looked at the resumes, some great applicants had already accepted summer jobs at Microsoft. Grr...
This year summer internship applications will be accepted on a first-come, first-served basis, so basically, if you're a college student looking for an internship, you pretty much should just apply now, instead of puttering around indecisively.
Normally I use CityDesk to compose things for Joel on Software, but the long articles on recruiting were written from home where I have a MacBook Pro (CityDesk is Windows only).
I was trying to find appropriate software that I could use to compose long articles that felt smooth on a Mac, that generated extremely clean HTML, and that generated curly quotes (“”) which I've grown fond of, especially for longer articles.
The combination I found that made me happiest was TextMate in Markdown mode. It was a surprisingly good experience. TextMate is an "emacs inspired" editor for the Mac, with tons of build-in stuff for editing different types of text files that they call Bundles. Markdown is a very simple way to format text, for example, putting *asterisks* around text that you want italicized; it generates nice clean HTML. Even Markdown source is quite clean and still highly readable, useful if you need to post the same content to Usenet or use it in plain text somewhere.
I have a few complaints though:
OS X antialiasing, especially, it seems, with the monospaced fonts, just isn't as good as Windows ClearType. Apple has some room to improve in this area; the fonts were blurry on the edges.
Also, I don't understand all these people who say that Macs never crash. I probably had to reboot the MacBook Pro (hard reboot -- hold down the power button for five seconds) about every two hours. It was always the same problem: the Wifi network would go down for a second, something which happens to everyone, but on Windows, it just comes back, while on the Mac, I get a spinning colored ball and everything is frozen. Everything. Forever. If I try to wait it out the beachball will still be spinning the next morning. If anybody is aware of this problem and knows of a specific fix I'd love to hear of it. It was like a Windows 3.1 deja vu all over again thing.
I still have to say that composing large amounts of text with Word 2007 on Windows XP is a better experience, all told, because of the autocorrection and the better screen display.
One more note -- all the pictures I've published in the last few days are of the Fog Creek office, of course, taken recently by photographer Gregg Conde.
Jack Herrington emailed me, in reference to the issue of Ruby on Rails performance, to write:
I agree with you about unicode. And I agree that Rails needs some time to evolve. But I use a bunch of web technologies and they all have issues.
I do disagree with the scalability statements. I don't think Rails has scaling issues that can't be gotten around, and which don't have cousins in other technologies.
What I would ask is that you at least put some framing around your scalability comments. Tell us about the scalability problems. Even if we don't fix it for you, the entire community can gain from your experience.
David Heinemeier Hansson wrote:
Rails is for the vast majority of web applications Fast Enough. We got sites doing millions of dynamic page views per day. If you end up being with the Yahoo or Amazon front page, it's unlikely that an off-the-shelve framework in ANY language will do you much good. You'll probably have to roll your own. But sure, I'd like free CPU cycles too. I just happen to care much more about free developer cycles and am willing to trade the former for the latter.
By way of clarification, I'm not concerned with Rails performance, I'm concerned with Ruby performance, and here's why.
I've seen lots of comparisons of Ruby's performance with bytecode languages like Java which I would consider slow, and I see a lot of reports of performance claiming Ruby is 10x slower, 50x slower, etc. Besides the random blogobuzz, Ruby comes pretty darn close to dead last in the Computer Language Shootout Benchmarks.
Without knowing much about the implementation of Ruby, I would guess that the biggest issue is around late binding and especially duck typing, which prevents type inference or strong typing, which means that function calls will always be slow because you can never get something compiled down to the point where a function call is just a single CALL instruction (on x86)... you always have to be exploring the object, possibly even scanning a hash table to find the function you want to call. Calling methods on objects is really, really, really, really common, especially in pure OO languages, and that bit of the code needs to get down to at least a CALL indirect on the CPU for Ruby to offer the same performance as languages where the type of the object can be determined at compile time and therefore the instruction where you're jumping to can be gotten either at compile time (like in C) or with a single indirection through a single vtable (like in C++).
I understand the philosophy that developer cycles are more important than cpu cycles, but frankly that's just a bumper-sticker slogan and not fair to the people who are complaining about performance. Even though our product, FogBugz, seems like something that should be perfect for Ruby on Rails, we have several parts of code where performance is extremely important. In FogBugz 6 there's one place where we need to do literally millions of calculations to display a single chart on a single web page. We have gotten it down to 3 seconds or so in our current development environment with a lot of optimization, but frankly with a duck-typed function call I really don't think we could do it before the web browser gave up and timed out and the sun cooled down a couple of degrees. We also have to scan incoming email messages for spam using Bayesian filtering. This is compute-intensive can take 1 sec. per message. Receiving one email per second is not unreasonable for many of our customers so we are very close to being CPU pegged. That is using a language which we know to be orders of magnitude faster than Ruby at this type of code. We would be absolutely dead on Ruby.
Even classic, simple CRUD applications -- the kind of application that basically just shows you a table from a database and gives you operations to add, delete, and edit records -- often discover somewhere down the line that there's something enormously computationally intensive that they want to do, for example, blog software might want to add Bayesian filtering to eliminate spam from comments. This is where you suddenly realize that if your language of choice is 10x slower than the competition, you may be simply unable to add that feature, or you may have to call out to another language (with all the marshalling overhead that implies).This doesn't apply to everyone, but when people say they have performance problems with Ruby or that they just need to be able to run code faster than the core Ruby language engine can run it, it doesn't help to have Ruby advocates singing hymns about developer cycles vs. CPU cycles. Even if you aren't doing compute-intensive things, if you find yourself needing to buy 100 servers instead of 10 servers, you may suddenly revisit the whole developer cycle vs. CPU cycle equation.
I understand that there are plans for Ruby to address performance with some kind of bytecode compiler and that will be nice. When these things happen and when Ruby starts getting competitive benchmarks it will be a lot more appropriate for a lot more types of applications. In the meantime I stand by my claim that it's not appropriate for every situation.
Avi Bryant describes a method for making method calls really fast, even if they do happen to be duck-typed. Cool!
(Ruby's still slow. Film at 11.)
MarkDown is a simple processor that converts text to HTML. For example, it converts *text surrounded by asterisks* to italics.
SmartyPants replaces "straight quotes" with “curly quotes” and makes a few other typographic improvements.
EditPad Pro is a very respectable text editor for Windows. It’s fast and contains scrillions of useful features. It’s not the fanciest thing in the world, but if you’re still using Notepad for the occasional bits of text, it’s a fine drop-in replacement.
Here’s what it takes to get them all working together on a typical Windows setup:
c:\perl\markdown\Markdown.pl %1 > "%~dpn1.tmp"
c:\perl\markdown\SmartyPants.pl "%~dpn1.tmp" > "%~dpn1.html"
start "" "%~dpn1.html"
c:\perl\markdown\md.bat "%FILE%". You may want to check the box in the Files tab that says “Save the current file if it has unsaved changes.”
Over the last six months, Sprint has been trying to get bloggers (like me) to write about their new Power Vision Network by sending us free phones and letting us download music and movies and use the phones for free.
That’s rather nice of them, but honestly, I have a really strong aversion to writing about things just because some PR person wanted me to. Basically, there’s no better way to make me not want to write about something than to ask me to write about it. I accepted the free phone because, gosh, well, it’s a free phone, but I decided that I simply wouldn’t write about it no matter how much I liked it.
As it turns out, I had the opposite problem. The phone they sent me, an LG Fusic, is really quite awful, and the service, Power Vision, is tremendously misconceived and full of dumb features that don’t work right and cost way too much. So I’m going to review the dang phone anyway, even though if anybody from Sprint is paying attention they’re going to lose their lunch and some executive bonehead over there is going to go nuts and I sincerely hope that this doesn’t put an end to the entire free-phones-for-bloggers boondoggle, because I’d hate to get beaten up at Etech next year by all the other bloggers who would hate me for spoiling all the fun.
Now, on to the review. I was pretty excited to try out this phone because I’ve been longing for one that could double as a decent MP3 player. Most days, I get to work via a combination of subway and walking, which takes about half an hour, and listening to podcasts makes the commute much more pleasant. So I’ve been carrying a phone (a Motorola RAZR) and an iPod (Nano) with me everywhere. Merging the two into one device would be great.
When it finally arrived, the physical appearance of the phone was rather disappointing. If you’ve been spoiled by Motorola’s latest phones, or the seamless, screwless, elegant iPod, the LG Fusic will strike you as butt-ugly. Where a Motorola RAZR has a solid case made out of almost sensual matte-black steel that just feels great, the LG Fusic is made out of the cheapest kind of gray plastic, the same material you find on a $3 toy. Where Motorola goes to great lengths to hide the screws, and minimize bumps and seams, the LG Fusic has dozens of ugly protuberances, gaps, holes, screws, seams, etc. Worst of all, the LG Fusic has no less than three of those evil, flimsy, rubbery plug-caps that are connected to the phone by the thinnest of filaments. You know, those stupid rubber plugs that you have to pull away to plug anything into the phone, and then they just dangle there like chicken wattles (when they’re not getting in the way of the thing you’re trying to plug in) for a couple of weeks until they finally tear off. The phone is almost twice as thick as a RAZR. It comes with a break-offable front plate which can be used to change the accent color of the very front of the phone. Your choices are Barbie Pink, Barbie Green, Barbie Blue, and Black which would be the only stylish choice, if only it didn’t clash so badly with the rest of the phone. (Believe me, it is hard to make black clash with anything, but LG did it.) Overall this phone seriously looks like a Fisher Price toy, not a top-of-the-line cell phone.
OK, maybe you’re not so vain that appearances are a big deal. I tried to get over it. I really did. I promise I won’t talk about the style thing any more.
I opened the clamshell and turned on the phone.
The screen lit up instantly! Wow, something about this phone is nice.
Oh, wait a minute. What’s going on there?
The main screen shifts between pictures of Mount Fuji, the Eiffel Tower, etc. That’s charming. But what’s that bus?
There’s a cheezy little black and white child’s drawing of a bus bouncing up and down in front of the cheezy tourist pictures. Again with the Fisher Price Toy theme. The first thing I try to do is find a better screen saver. Everything looks like some kid’s 6th grade BASIC graphics project. Oooh, look, colored squares flying around. Terrible clip art of a “DJ”. One of the screen savers is called “Funny.” You get a silhouette of a lizard climbing around on a pink background. Bwa ha ha! That is funny. TO TWO YEAR OLDS.
OK, ok, I promised I’d stop talking about style. On to UI design.
The main menu was really, really confusing.
The first thing you see when you click on the Menu button is that you missed some alerts:
Although, it turns out, you didn’t, that's just the name of the menu item that comes up first.
You can’t see all the icons at once because someone had the bright idea of using a weird 3-D perspective, and the currently selected icon comes zooming out in front, covering up some of the other icons. All the unselected icons are shown in silhouette, so at first they just look like a background. It took me quite a while to figure out just what the menu was and how to find things I wanted from the main menu.
But don’t worry… there are random bits of sparkle that fly around on the screen. That’s the important part. The random bits of sparkle, again, a 6th grader’s BASIC graphics project.
Now, on to the whole reason I wanted this phone: the MP3 player.
There’s no desktop integration, no ITunes integration, no feature for subscribing to Podcasts, nothing like that. When you plug the phone into your computer using the supplied USB cable, it thinks you want to use the phone as a modem. Yes, one day I might want to do that, that’s true, but for now I just wanted to get MP3s onto the thing. Somehow, somewhere, I managed to stumble on a menu that made the phone act like a USB hard drive. Tada! The phone pops up on my computer looking like a hard drive. And then there was already a MUSIC folder there, and I could drag MP3 files in. Yay! I downloaded TWiT episode 69 manually and headed off to the subway to listen to it.
Wait… I need headphones. Ahh, here they are. Wait a minute. The headphone cord is only about 8 inches long. Am I supposed to hold the phone up to my chin to listen to music?
Oh, I see, there are two cords. You have to plug the headphone cord into the microphone cord and plug that into the phone. Now it’s long enough. OK, it’s awkward, but I can live with that.
To listen to the MP3s you’ve downloaded:
All right. TWiT is more than an hour long, and I only listened to half of the episode by the time I got home. Luckily, there’s a handy PAUSE button on the outside of the clamshell. Unluckily, it doesn’t work. Pressing it once informs you that the buttons are locked, and you have to press and hold the pause button to unlock. So you do that, and the key guard goes off, and you press the pause button again, and nothing happens, so you press it again, and finally you’ve paused the music.
In the meantime, if, say, hypothetically, you were pausing because you live in a country where the police brutalize people, and a policeman was brutalizing you, and you wanted to stop the music so you could try to figure out what the policeman wanted and perhaps there was some way if you could just hear him that you could get him to stop beating you with a riot bat, you’re already DEAD by the time you figure out how to make the pause button actually pause.
While the MP3 player is paused, the backlight on the external display just won’t go off. So inadvertently, the phone almost completely runs down its battery overnight staying in “Pause” mode.
Why not turn the phone off overnight? Well, because then I’d have to listen to the first half of TWiT all over again. Can’t you fast forward? No. Doesn’t it remember where you’re up to like an iPod? No. Pause is your only hope.
The next morning, with a single bar of battery juice left, I got into the subway and resumed listening to the podcast, and I’m a wise guy, so I decided to see what the battery looked like, and of course, the phone lost power, oops, lost my place in the Podcast.
Put back the battery. Turn on the phone. Go into the MP3 player again. There’s no signal, and, guess what? You can’t get into to the MP3 player unless you can establish a network connection to the Sprint Music Store. Even to play your own MP3s!
OK, so this is an MP3 player that doesn’t really work on the subway and won’t work on a plane, the two places I’m most likely to listen to MP3s. Not very appealing.
A little bit more exploring and I discovered that there’s another entirely separate MP3 player on this device. It’s hard to find. You have to go to Tools, then Memory Card, then to the Music folder, and another MP3 player starts up which you can use to listen to your MP3s. For this player, you don’t have to be on the network, so it works in the subway, but—get this—the minute you close the clamshell, the music stops! I am literally not making this up. There are two bad MP3 players on this device, neither one of which remembers where you’re up to, neither one of which can be used on the subway with the phone folded in my pocket, neither one of which has a fast-forward feature.
I have literally never seen such a useless MP3 player.
OK, onward. Yes, you can watch movies on this phone. For example, for $5.95 a month, you can get something called mFLIX. Until you pay the money, there’s no way to find out what mFLIX is or what it is you’re getting for your $5.95. I’ll tell you what you get: a bunch of garbage film-student videos that nobody would ever vote up on YouTube, in a tiny blurry window that reminds you of QuickTime 1.0 (“look! It’s on a computer but it’s moving!”).
That was disappointing. I thought this thing was supposed to have full length movies somewhere. Ah yes, how about “MSpot Movies?” It says I’m going to get “Full-length Hollywood movies.” Only $6.95 a month. Yes. Buy buy buy. (Thankfully Uncle Sprint is paying for this). Oh look… you can preview before you commit to spending! Clicking Preview brings up a page that says PREVIEW with a “Done” button. That’s it.
OK, maybe they don’t want me to preview. Fine. After you click Buy, you’re thrown back to a main menu somewhere and then you have to remember what the hell you bought and go find it again. Annoying UI, again.
OK, MSpot Movies. A menu comes up with a bunch of folders:
I don’t understand. Are these movie titles? Not movie titles I’ve ever heard of. Yep, it’s true. What you get for $7/month is about 10 movies that seem to be in the public domain. Literally nothing worth watching, least of all on a smudgy 1 5/8” (diagonal), pixelated screen. I did, actually, as a part of my sacred duty as a reviewer, try to watch a whole movie. I could only stand about the first 1/3rd of it, and the battery was dying, and the phone was getting too hot to hold. I cannot imagine anybody finding any value in MSpot Movies. If Sprint makes any money off of them, it’s probably by mistake. This service is literally as much of a scam as those X-Ray glasses they used to advertise in comic books to steal a few bucks from some little kids.
The only kind of content you might really want to watch on this device is the stuff you find on YouTube, or video podcasts like The Show with zefrank. But that’s not what Sprint gives you. Instead they give you $7/month, ripoff, non-previewable scammy garbage.
A long time ago, I was working on MSN 1.0, and there was a long line of content providers working to make deals with Microsoft to put their content on the Microsoft Network, but in those days, it wasn’t clear exactly who should be paying who, so hardly any deals got made. In the meantime, the whole Web thing happened, where anybody could provide content without signing a deal with a Microsoft executive, and there was tons of content, and some of it was garbage, yes, but some of it was good, and we found the good stuff, and it floated to the top, and all was well, but Sprint doesn’t get this. They relish their ability to serve as the gatekeeper to what they hope will become a new medium, because the gatekeeper gets to charge tolls. And it’s 2006, and I almost can’t believe I’m writing this, because way back in 2000 I wrote almost exactly the same thing about WAP, and how cell phone companies keep failing to insert themselves as toll collectors because they’re so darn clueless about how the Internet works, and about the value of many-to-many networks instead of broadcast networks.
And now suddenly someone at Sprint read some book by Scoble and then they read Malcolm Gladwell’s theories of tipping points in the airport and Hey Presto! Maybe we can make this work by finding the tipping point people! You know, the bloggers! And all the bloggers get free cell phones, and Sprint gets tons of publicity, but frankly all the publicity in the world is not going to help them foist on us a product that is utterly pathetic. The phones they send us are so lame there is literally no area you can go into without being disappointed and shocked at just how shoddy everything is and how much it costs and what a rip off scam they’re trying to run here with the music that costs too much and the movies that you don’t want to watch on the screen that makes them unwatchable and you just KNOW that if you call to cancel the extra $7/month, their customer service department is going to give you the phone menu runaround and then put you on hold for an hour and then you’ll get some cancellation specialist with an incomprehensible accent who will spend 15 minutes trying to talk you out of canceling the useless service until you just give up and let them have the goddamned $7 a month. No amount of pampering bloggers and calling them Ambassadors is going to get around the fact that you’re sending us plastic junk phones that look like bath toys. (Hey, does it float?) All the “tipping point” theories in the world won’t protect Sprint from the basic truth that the LG Fusic user interface could basically serve as an almost complete textbook for a semester-long course in user interface design, teaching students of usability exactly what NOT to do.
Wait a minute.
Wait just one minute.
Maybe I completely missed the point.
Maybe this phone is for four year olds!
It all makes sense now!
The nonsensical menus don’t matter—four year olds can’t read! The toy-like appearance—duh! The ripoff movies—who cares, as long as the kids press BUY by mistake and the parents keep paying the bills!
Now I get it.
So really the only stupid thing that Sprint did is to send this phone to a bunch of know-it-all, hipster-wannabe, pretentious early-adopter engadget-reading 41-year-old bloggers, with our pretentious black iPods and our sleek gun metal RAZRs and our MacBook Pros and our so-called “Podcast” listening habits, watching zefrank tell potty jokes about The Decider.
No no no no no. This phone is for 4 year olds, albeit spoiled 4 year olds with rich parents. They’ll love the colors, the plastic, the impossible UI, they can watch the one 1936 movie that inadvertently fell into the public domain in class when the teacher is getting boring, and they sure as heck aren’t going on a subway with that thing.
I gave the phone to a friend’s 4-year-old.
Remember when I complained that my Mac kept freezing with bouncing beach balls?
A lot of people suggested it might be a hardware problem, but the diagnostics on the setup disks didn't find anything.
Well, Daniel Jalkut over at Red Sweater Software suggested that I look in the console app to see what was going wrong, and lo and behold, there were lots and lots of messages that said:
Sep 19 22:56:39 joel-spolskys-computer lookupd: NetInfo connection failed for server 127.0.0.1/local
This totally corresponded to what I was seeing... suddenly any app that tried to do a DNS lookup of any sort would go into permanent beachball mode and never recover.
Some Googling around led me to a page by John Bafford that said "Lookupd has a bug (rdar://3632865) in its cache cleanup code that causes it to randomly crash. CrashReporter, the system crash log agent, does not properly handle lookupd crashes, and as a result, when lookupd crashes, the process is not terminated. Since lookupd has not terminated, mach_init does not respawn lookupd. From this point, any application that attempts to access lookupd, either directly or indirectly, will hang."
Hmmph. Kindly, John provides Unlockupd, a daemon that watches lookupd and restarts it if it gets jammed up.
I'll try this for a while and see if it helps. In the meantime, if it's true, it's odd that Apple hasn't fixed this bug in over two years. If somebody inside Apple wants to peek into that bug (link only works inside Apple) and let me know what they see there, I'll update this article!
Steve Yegge: “Up until maybe a year ago, I had a pretty one-dimensional view of so-called ‘Agile’ programming, namely that it’s an idiotic fad-diet of a marketing scam making the rounds as yet another technological virus implanting itself in naive programmers who’ve never read ‘No Silver Bullet’, the kinds of programmers who buy extended warranties and self-help books and believe their bosses genuinely care about them as people, the kinds of programmers who attend conferences to make friends and who don’t know how to avoid eye contact with leaflet-waving fanatics in airports and who believe writing shit on index cards will suddenly make software development easier.”
1110 posts over 13 years. Everything I’ve ever published is right here.
There’s a software company in New York City dedicated to doing things the right way and proving that it can be done profitably and successfully.