Slashdot Mirror

You should read another one of his articles Mainly the bit about pointers.

I few years ago I would have agreed with you but I don't any more. I now think that you can go one way but not the other:
*OO: C++ -> Java/C# -> Pascal -> VB.
*Procedural: Assembly -> C -> Pascal -> VB.

This means that if you understood C++ 100% you'd know about 90% of VB but if you knew 100% of VB you'd only know 40% of C++.

But apart from the minor differences the big difference is using the libraries. I wouldn't expect someone to be able to go from the Java libraries to the STL because they work differently or any one of the 1000 of other libraries.

Joel, as I'm sure you know, was one of the technical guys behind VBA in Excel, along with some other fairly big projects. He apparently made enough money from these gigs that he went off and started his own company, initially focusing on consulting (at the most unfortunate time to be in consulting...), and then moving into shrink wrap software. Apparently they're doing okay as they recently moved into a pretty impressive new office, still in swanky (and expensive) New York City.

Joel is a big advocate of treating developers well, and is respected for generally being pragmatic and insightful, with a humorous writing style that is informative while remaining entertaining. On the flip side, a couple of his recent posts have been blatant quid-pro-quos with some friends of his, and he's selling out a bit with the Programmer's Paradise gig.

His writings are always good for a laugh or two, and the content is always very insigtful. Here is one of my favorite passages from his series on Painless Functional Specifications.

Scenario 2: Cindy.
Cindy is a teenager in high school. She goes to a pretty pathetic public high school, and she's pretty smart, so when she gets home at 2:00 pm, it only takes her about 7 minutes (on average) to do her Algebra homework. None of her other teachers even bother to give her homework. Her baby brother (half brother) is vegged out in front of the only TV set watching Teletubbies, so she spends the afternoon (from 2:07 until about 6:30, when her new mommy serves dinner) surfing the net and chatting with her friends on AOL. She's always looking for exciting new web sites. As a result of typing "What Time Is It?" randomly into a search engine (by mistake, she meant to ask one of her friends using Instant Messenger) she gets to WhatTimeIsIt.com, and sets up a new account. She chooses a user name and "RyanPhillipe" as her password, selects her time zone, and voila -- finds out what time it is.

Joel on Software has an excelent article which is worth a read and is exactly on this topic(but written a couple years ago)...

Here's a much better article with a similar thesis: Joel on Software - Things You Should Never Do, Part I

There are parts of it that I've never agreed with:

"Well," they say, "look at this function. It is two pages long! None of this stuff belongs in there! I don't know what half of these API calls are for."

[...]

Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.

This should never happen! If you have all these bugfixes in your code and no way to know why they were put in, you've screwed up badly. You should have each one documented in:

• a bug number in the database
• a log message in your commit history (cross-referenced to the bug database) (which you should be able to pull up easily with "cvs annotate" or similar)
• if it's particularly weird-looking, a comment in the code

So the idea that you'd have all these important bugfixes without any way of knowing what they are should be laughable! Given a codebase like that, you probably would be better off throwing it out, because it was clearly developed without any kind of discipline.

Also, he's embelleshing a lot. If it's just a "a simple routine to display a window", it doesn't need to load a library, require Internet Explorer, etc., and thus can't possibly have bugs related to those things. He makes the situation sound a lot more extreme than it really is.

But in general, I think he's right. Refactor, not rewrite. That's the same thing the XP people say to do. They also have extension unit tests to make it easier to refactor with the confidence that you haven't screwed anything up. Which can help in situations like this:

I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked.

Ugh. I bet it would have been a lot less tuning if there were a decent way to test that the change to support #60 hasn't broken any of the previous 59 server types. Or that just a refactoring hasn't broken any.

I don't think this advice always applies, though. I rewrite one major project from scratch at work: our personnel system. Our database schema was hopelessly denormalized and broken. That's not something you can refactor easily - with a widely-used database schema, it's easy to make one big change than many smaller ones, because a lot of the work is just hunting down all the places that use it. That's easier to do once. So I believe there are situations this advice does not apply, but I also believe they are rare.

Here's a much better article with a similar thesis: Joel on Software - Things You Should Never Do, Part I

There are parts of it that I've never agreed with:

"Well," they say, "look at this function. It is two pages long! None of this stuff belongs in there! I don't know what half of these API calls are for."

[...]

Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.

This should never happen! If you have all these bugfixes in your code and no way to know why they were put in, you've screwed up badly. You should have each one documented in:

• a bug number in the database
• a log message in your commit history (cross-referenced to the bug database) (which you should be able to pull up easily with "cvs annotate" or similar)
• if it's particularly weird-looking, a comment in the code

So the idea that you'd have all these important bugfixes without any way of knowing what they are should be laughable! Given a codebase like that, you probably would be better off throwing it out, because it was clearly developed without any kind of discipline.

Also, he's embelleshing a lot. If it's just a "a simple routine to display a window", it doesn't need to load a library, require Internet Explorer, etc., and thus can't possibly have bugs related to those things. He makes the situation sound a lot more extreme than it really is.

But in general, I think he's right. Refactor, not rewrite. That's the same thing the XP people say to do. They also have extension unit tests to make it easier to refactor with the confidence that you haven't screwed anything up. Which can help in situations like this:

I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked.

Ugh. I bet it would have been a lot less tuning if there were a decent way to test that the change to support #60 hasn't broken any of the previous 59 server types. Or that just a refactoring hasn't broken any.

I don't think this advice always applies, though. I rewrite one major project from scratch at work: our personnel system. Our database schema was hopelessly denormalized and broken. That's not something you can refactor easily - with a widely-used database schema, it's easy to make one big change than many smaller ones, because a lot of the work is just hunting down all the places that use it. That's easier to do once. So I believe there are situations this advice does not apply, but I also believe they are rare.

Joel said this first, and better, in Things You Should Never Do, Part I.

This topic has been covered, with much better writing, by Joel Spolsky:

Things You Should Never Do, Part I

Rub a dub dub

This topic has been covered, with much better writing, by Joel Spolsky:

Things You Should Never Do, Part I

Rub a dub dub

I had to force myself to keep reading the article after the first case study. The simple fact that he cannot even get his facts straight (IPv6 has a 128 bit address space) does not help his argument.

For a much more coherent argument against re-writes see Joel on Software, where he argues throwing everything out and starting fresh is a bad idea. He argues for evolutionary refactoring away old code.

Things You Should Never Do, Part I

Things You Should Never Do, Part I

Joel on software has covered this point in a good article: http://www.joelonsoftware.com/articles/fog00000000 69.html.

Microsoft is never more dangerous than when they are losing to a competitor and everyone knows it. Look what they did to Netscape, fer chrissakes. Netscape went from 85% market share, to a stripped carcass in the dumpster behind AOL HQ. Took a while, but it happened.

Wrong. Netscape killed itself. While IE was evolving, Netscape decided to rewrite their browser from scratch (terrible mistake!).

Check out this article at Joel's site : Netscape goes bonkers

Face it : Netscape had a good browser, but they threw it away.

I think the responses here are typical. Typical of those who think "different is better" and that we all have time to devote to this.

I tried and tried to use Gimp over the years, I tried to read through the manuals online...it was PAINFUL. Even the easiest things escaped me. I just wanted to do X very simple procedure, and I spent hours trying to figure out how to do that. I even found newsgroup postings from people trying to do what I was doing and getting responses like "it's just a little different, you have to hold shift-alt drag the mouse and stand on your head to draw a box." Duh.

And then I picked up a trial copy of Elements 2.0, figured it out in about 30 seconds and was doing what I needed to do. I paid my $100 two days later and will never go back. It's super-fast on my machine too.

The lesson: Gimp is different for the sake of being different, which means it's a higher learning curve than I'm willing to give it. I'll gladly pay someone who's taken the time to make their software work in a way that users expect these days.

Take a page about design from Joel on Software, guys. The Gimp isn't worth my time.

if there was a consistent UI for linux. After all, there are many more Aunt Madge users and that's what linux on the desktop will need to succeed.

Read the article (I know, it will be hard to force yourself to do so if you are a slashdot regular :)) and then read this chapter from TAoUP.

I don't know if Spolsky didn't read this far, or if he's just a weak plagarist, or maybe this is the only part that made a big enough impression on him to merit rephrasing for his own column.

The only difference I see is POV, and substitute "mac" for "windows".

Yes, you can, but the point is whether you teach by building up or down...

JoelOnSoftware has a good piece on the 'Law of Leaky Abstractions' which for me sums up the problem with using Access as a teaching tool.

When someone doesn't understand that their "report" is returning no rows because they really don't understand outer-joins, then you have frustration. SQL at least forces you to think about those things.

Craftsmanship

No. Coding is design. When you are writing in Java you are writing very detailed specifications on what a computer must do. It's so precise that a computer can convert it into code that runs.

See: Joel on Craftsmanship" for example.

For anyone who's read it, is this book similar to Tom DeMarco & Timothy Lister's Peopleware? I really appreciated their keen understanding of the development process in that book and I'm always looking for additional books along those lines. (See also these quotes from some of the authors and this Joel on Software review to get a feel for the book.)

I've changed my mind over the years on this. I used to think anyone could do anything ( in terms of mental exercise), but I no longer feel this is the case.

The ability to think in the abstract is a blanket statement which can be further clarified into specific creative methods:

1. To create 3D art, you must be able to visualize a 3D model in your mind. You must be able to rotate the image, flip it, stretch it and contort it - mentally.

2. To create music, you must be able to hear the notes and chords in your mind, even if those notes and chords have never been played in the order you hear them. You have to be able to implement changes in a song standard just by closing your eyes and listening.

3. To paint or draw, you must be able to visualize how the picture will look before it's begun, down to the conveyed emotion.

4. To write a piece of program code, you must be able to visualize bits of memory in your mind as though it was a real object. If you are programming a multi-dimensional array, you must be able to flip that array around in your mind, go down a number of levels and locate where "variable x" is supposed to be. This is why so many programmers never get past pointers when learning to code. If you get pointers, it's a seemlingly easy concept, but as both Joel Splosky and several others have mentioned, even most C programmers don't understand them. Go figure.

a good read for any startups is Joel Spolsky's journey in building his company from scratch. Put aside your predjudices about his software origins or the market he is aiming at, but make sure you read and digest some of the ideas.

It's a cheap way to read how he's organised his company from 1999 to the present.

a good read for any startups is Joel Spolsky's journey in building his company from scratch. Put aside your predjudices about his software origins or the market he is aiming at, but make sure you read and digest some of the ideas.

It's a cheap way to read how he's organised his company from 1999 to the present.

a good read for any startups is Joel Spolsky's journey in building his company from scratch. Put aside your predjudices about his software origins or the market he is aiming at, but make sure you read and digest some of the ideas.

It's a cheap way to read how he's organised his company from 1999 to the present.

a good read for any startups is Joel Spolsky's journey in building his company from scratch. Put aside your predjudices about his software origins or the market he is aiming at, but make sure you read and digest some of the ideas.

It's a cheap way to read how he's organised his company from 1999 to the present.

Joel on Software's company, FogCreek, makes a very friendly, easy to use content mgmt software package, named CityDesk.

Very intuitive and easy to use...yet it is pretty powerful. Good for novice and knowledgeable users.

That's a "boil the ocean" solution. There are thousands of programs out there that know what legal DNS labels look like, and nobody will adopt i18n if some random subset of their apps and embedded hardware stops working. I agree we should revise the DNS protocol (IPv6 would be a good time to do it) but you have to maintain interop with RFC 1034 clients basically forever--this is a fairly painless way, when i18n-aware DNS servers or config file editors are available.

...OpenOffice.org has not been stellar. While I use it on occasion, it's always struck me as so horribly slow. It seems to me that we *dont* want to be imitating all the feature bloat and general crap that seems to hang on to MS Office like cheap wallpaper. Honestly, who really needs all the features in Word anyway?

XML is not 'just text'. It is encoded in a text-based format, agreed, but so what? The data encoded will not be used/processed/displayed as text. XML offers flexibility and a degree of naked-eye readability, but storing data in an implementation-specific manner can offer significant optimisations.

A key example is relational data. Here, XML is inefficient, not because of verbose tags or other bloat, but because of its flexibile structure.

Take it away, Joel:

How does a relational database implement SELECT author FROM books? In a relational database, every row in a table (e.g. the books table) is exactly the same length in bytes, and every fields is always at a fixed offset from the beginning of the row. So, for example, if each record in the books table is 100 bytes long, and the author field is at offset 23, then there are authors stored at byte 23, 123, 223, 323, etc. What is the code to move to the next record in the result of this query? Basically, it's this:

pointer += 100;

One CPU instruction. Faaaaaaaaaast.

Now lets look at the books table in XML.

<?xml blah blah>
<books>
<book>
<title>UI Design for Programmers</title>
<author>Joel Spolsky</author>
</book>
<book>
<title>The Chop Suey Club</title>
<author>Bruce Weber</author>
</book>
</books>

Quick question. What is the code to move to the next record?

Uh...

What a pathetic story! Congratulations to the Wired writer for an evocative description -- the litte red wagon was a perfect detail.

And for a reality check, the Bionic Office!

I hear a lot about people going to universities with video game degrees. I don't hear much about how the video game industry in general views these degrees. Do they respect them?

No, not really. Which you're not going to hear from anyone employed by/who's been through one of these places, but it's the truth.

The modern games industry is structured around two basic concepts - a continual cycle of cheap and keen labour ("I write games" sounds a lot sexier than "I submit databases queries to a machine I've never seen down in the basement", so there's always demand) coming in, and making money on 1-2 hits from big names (Will Wright, Warren Spector, Peter Molyneux, etc) to pay for the other 8-9 titles that flop.

From a publisher's point of view, if you've signed up your sure-fire/franchise hits for the year then you can afford to take a gamble on your 8-9 other titles - and you really don't care where the people developing them went to school, you want to know their track record. If they've actually shipped something in the past they have a good chance of doing it again, and so even if the game isn't a blockbuster you will at least get it delivered. This means, even if the game sucks, you will probably sell enough to break even - and may even get lucky and have a surprise hit.

From a developer, the same applies. First and foremost you're looking for people who've actually shipped things in the past. Failing which you're looking for cheap new hires (from anywhere), who're a)keen and b)smart (the second one being optional, depending on how good the company is). These places are attempting to set themselves up as almost trade schools, but they're missing the point - although the application of computing science is what both they and the real world "do", the real world only cares about the real world.

If you haven't actually got that "I shipped this title" on your CV yet, what you do have on your CV is less interesting to an employer than how you've conducted yourself. If you've continued your education then that's encouraging, but if you want to distinguish yourself then either a)do something like a challenging degree (CS, maths, philosophy, medicine, law, theology - the subject isn't particularly significant) or b)skip academia and achieve something independently.

A lot of what he writes is tripe, but you should assume that your prospective employer is looking for people who are Smart and Gets Things Done. Neither of those are contingent on having a degree in Pokemon.

If I'm going to be spending 8-hours-of-my-life somewhere, I want it to be a plesant experience. Spending a third of my life in an environment that's just a "means to an end" sounds depressing.

There are good work environments out there, where people actually enjoy the culture, the company, and the experience while getting paid:

• Google
• Pixar
• Joel's company

Why not make work plesant enough that people enjoy it.

• Cool benefits like Google has massages
  
• Laptops for everyone -- they'll work even when not at home; and even lower-level employees feel better when they have as cool a laptop as the sales guys.
  
• A weekly wine-tasting in the office -- get people to know each other.
  
• Better office chairs, etc; if yours aren't comfortable.
  
• Better lighting, etc. if your office has poor lighting.
  

And improving can be done even if your environment is extremely good

We're not talking about compiling the kernel here, just Internet, Office, mail and IM (which covers 99% of usage).

I don't think the poster actually meant 99%, or does he really think that gaming only constitutes 1% of computer usage? So, I'll parse this as 80%, as in the 80/20 rule.

This 80/20 rule is one of the great myths of computer usage.

See this article for a fascinating breakdown of this gilded golden rule.

Even if you figure the 80/20 rule is accurate, the question is... WHICH 20% are you going to implement? To satisfy which 80% of the users?

It just doesn't work that way. 99% of users are NOT going to use just a browser, office, email, and IM. Plenty will want to do HTML Editing, or use TurboTax, or play GTA Vice City, or any of a zillion things that Linux isn't quite up to.

Now, before you lught up the torch, realize that I'm typing this on Moz 1.2.1 on RH 9. But, in sincerity, as an independent software developer, I use VMWare to boot Windows 98, Windows 2000, and Windows XP on this computer system - often 2 or 3 at a time. I also use one of these VM sessions to run DreamWeaver
to edit HTML templates for client sites. I'm still using DW 4.0, if they come out with a newer version for Linux, I'll buy. (anybody listening over there?) I have 10 of my 160 GB of HD space set aside to run Win98 so that I can play games on the weekend. (Try getting GTA working under Wine....)

In short, even while I'm a big Linux fan, and maintain dozens of Linux systems, I claim that while Linux is (almost) ready, the world is not. Here's what I'd like to see done to your standard GNU/Linux distro to accellerate the inevitable switchover:

1) Binary API for hardware drivers in the kernel, and good, complete documentation of this API should be open and public. NVidia and Creative should be able to distribute binary drivers for their hardware without causing people to age prematurely. This binary API should be as similar to WinXX's PnP driver API as possible to minimize the cost and expense of maintenance.

2) The OEM contracts that MS has with the various vendors should be outlawed, or at least forcibly modified so that there are no penalties for including competitors' software.

3) Something OPEN that will interface with MS Exchange Server, and/or something OPEN that will provide the same functionality of MS Exchange Server. There are some projects that have *some* of the functionality, but nothing has yet jumped out and ahead that really covers either base.

4) X11 is about to be obviated. Quartz/Aqua on the Mac, and Longhorn both provide a much better UI experience. X11 is based on 1970's technology. Unfortunately, I'm not the guy to provide this in *any* way. But we need a good, 3D capable UI/API that can communicate with the X11 protocol. Probably based on OpenGL.

I'm not worried. I deploy on Open Source platforms all the time. I've seen enough improvements in the last 4 years (RedHat 5.2 is my starting point in the OSS world) to give me extreme amounts of confidence. I would've s--t my pants 4 years ago at the RH 9 desktop in front of me, and I'm well aware that it's not even the best desktop!

That means it should have all of my annoyances worked out sometime in 2006!

PHP is certainly cool, but there are some fairly major gaps to be filled.

From the Joel on Software story, it seems the C compiler for the Excel team dates back to the 80's. And this news releases states that Microsoft Business Solutions CRM "is the first Microsoft business application built on .NET infrastructure."

Trolling a bit there - are they biting?

I think their point on patterns is equally valid for UML, or TechnologyX in fact...

UML usage is often seen as an end in itself. Robin (intrepid co-author of this article) was once asked during a job interview: "What's your favourite UML Diagram?" What's the correct response to that? "Oh, Use Case Diagrams every time! Yeah, I use it for everything!"

However I think "Robin" should have read Joel On Software's Guerrilla Guide to Interviewing for the 'correct' response to that. If it was a smart interviewer, it wasn't a question designed to get an answer, but to elicit discussion about patterns and see if Robin really knew what they were and how to apply them. If they weren't a smart interviewer, and were really looking for an answer, then he/she is probably glad that the interview didn't go so well. :)

Of course they're clever bastards (but they're not the first, nor the last company who prices for market penetration). But that alone just does not cut it, I think. Joel Spolsky wrote a bit on how Excel squashed Lotus. And I don't think they had a monopoly back then.

I'm convinced that's how Open Office etc. should work. Flawless im- and export, and I mean real fucking flawless.

And I wish people here would quit putting out/modding up extremities as if Microsoft acted like a monopolist from day one. Because that's just not true, or at the very least not really a balanced view.

I had the same reaction. Of course I haven't read the book, so I don't know if Spolsky is being reported correctly either.

Considering that I often do agree with Joel's commentary on aspects of programming and programmer thinking (for example his concept of leaky abstractions) I am wondering if it was something he was saying for effect that got took out of context.

OTOH Joel is quite aware that not all programmers are equal. So it could be that this new book is aimed at non-creative types who want to make the transition. Something that, I suspect, is a lost cause from the start. This reminds me of the people who say to you "Forget all this theory crap, let's get to the code." -- You just know they will never understand why the theory is important. I expect the same is true of someone who thinks creativity and logic are opposite poles of thought.

There is a shorter online version (nine chapters) of the book available on Joel's site (excellent stuff, btw.)

There is a shorter online version (nine chapters) of the book available on Joel's site (excellent stuff, btw.)

http://www.joelonsoftware.com/

You can read nine(!) sample chapters on Joels website

Looks like I need to bring Joel Spolsky's excellent article, Things You Should Never Do, Part I, to a new readership.

The article speaks for itself, but essentially Joel's point is, "If it ain't broke, it's going to take you a heck of a lot longer to rewrite something inferior than you could've ever expected." Old code has tons of lessons learned that you'll never tease out. New code is easy to read and can implement every buzz word you'll find on O'Reilly Net right now, but it won't be battle-tested.

If you're still able to even think about throwing out your old investment and moving to CGI and BSD, however, I'm thinking your site isn't doing much very fancy. If you don't have much customization invested in your propriatary system, what Joel and I are saying is moot, especially at the licensing fees you're mentioning.

I'd also point out the title is very misleading. It's not Java that's the issue -- it's your system's architecture. Java is just as capable as creating a, "largely static site that is generated (written out to cache) from a new, simpler content management system," as language X. This is quite similar to the discussion we had about whether Java is an SUV just a while back (if it is an SUV, btw, that's not a bad thing). Your programmers' skillset is what's most important. If they already have a familiarity with Java, why ditch it?

So, keeping true to the post that says the recommendations here come out our arse, here's another pulled from the same place:

I'd recommend trying to refactor your current codebase to do two things. First, try to implement your static page idea using your current system. Two, take out as much of the crappy, non-scalable system that happens to be written in Java as possible. You don't name the system, but the whole advantage of Java is that it doesn't need to be platform-specific (if done right). Ditch Solaris. Create a server-farm of cheap x86 hardware with Linux or BSD with a JVM installed. Reread your license -- if you have thirty "clients" (new Linux servers) making static pages from one legacy server's dynamic content, can you pay a lower fee?

PS -- Who said Java was good for prototyping? Visual Basic (and vbscript/ASP or *gulp* ColdFusion), sure. REALbasic, sure. Java? Are you folks mad?!! ;^)

Instead, try to improve your current solution an bring its cost down:

1. If you are scaling up by adding servers, see if you cannot add something like two Linux servers instead of one Sun (for a fraction of the price, naturally).
2. You haven't said which software packages bring up the license cost (besides Oracle, of course). But for most, there are open source alternatives. Sure, they might take more work to set up in some cases, but certainly less than rewriting the whole application, no?
3. You might even want to evaluate if you can replace your Oracle by a SAP DB instance if that is not your bottleneck (Hint: Caching! Caching!).
4. If, as you say, hundreds of KB are used up for every logged in user, then, in all likelihood, there are big inefficiencies in your code. You should profile it / have it profiled for both CPU and memory efficiency. Then tune the 5% of the code that use 95% of the resources, instead of throwing away 100%.
5. Are the outsourced programmers up to snuff? Maybe have the code checked by a third party (who could also do the profiling / tuning). Because a bad programmer can bring down any infrastructure, be it J2EE, .NET, PHP or whatever. It's the man, not the machine.

AFAIK, there's no VC money behind Fog Creek. They do consulting work to allow them to develop shrink-wrap applications. Also, it's not a new company - they've just moved offices.

They've been profitable (see last para) for some time, so the answer is that they can probably quite easily afford it as a natural part of the business growth.

But it's not that expensive. He write that the price per developer is 700$/Month.

According to Joel the $700 figure is for a fully staffed office. Since Joel coyly avoids more detail, we can only guess what his current cost is. FogCreek is a young company. Assuming that their new offices are 50% full (which I don't get the impression they are), that rent-per-head figure is more like $1400/month at the moment. And who knows how long it'll be before their business justifies hiring more people to fill up those empty offices.

Well, if the snazzy digs don't motivate them, then their bills will -- or at least it'll motivate the person who has to pay the rent, i.e. Joel, to crack the whip harder! :-)

From Joel's Guerilla Guide to Interviewing:

Some signs of a good programmer: good programmers have a habit of writing their { and then skipping down to the bottom of the page and writing their }s right away, then filling in the blank later.

Sounds great, Joel! <smile, nod amiably, back slowly toward door>

They also tend to have some kind of a variable naming convention, primitive though it may be... Good programmers tend to use really short variable names for loop indices. If they name their loop index CurrentPagePositionLoopCounter it is (a) sure sign that they have not written a lot of code in their life.

Or that they just like long variable names. The most annoying programmers to work with (and the ones I'd be least likely to hire) are the ones who use names like "i1", "i11", "ii1", "iii1", "a2", "b" for everything.

For example, if you ask them to reverse a linked list, good candidates will always make a little drawing on the side and draw all the pointers and where they go. They have to. It is humanly impossible to write code to reverse a linked list without drawing little boxes with arrows between them. Bad programmers will start writing code right away.

Okey-dokey, then.

Occasionally, you will see a C programmer write something like if (0==strlen(x)), putting the constant on the left hand side of the == . This is a really good sign. It means that they were stung once too many times by confusing = and == and have forced themselves to learn a new habit to avoid that trap.

There are good interviews, bad interviews, and then there are a few things you can do to get me to call security to escort you out of the building:

1) Start a fire for no obvious reason.
2) Make fun of all the old-school Duran Duran songs in my phat MP3 collection.
3) Call strlen() to see if a string is empty.

From what I can tell, what Joel considers the "99.9th percentile" is actually a level of competence I'd expect from a bright high-school kid who skipped some, but not all, of his introductory computer-science class. It's not exactly hard to hire people at this level; most of them are, or should be, brushing up on their Hindu grammar to help them train their replacements.