Slashdot Mirror

It's also because they're too stupid to read Joel on Software regarding offices and his own office. Instead, many of them keep doing things that are poison to "knowledge workers," a phrase I hate but that nonetheless describes the kind of people discussed here.

Private offices with doors that close were absolutely required and not open to negotiation.

I don't think he'd want to be lumped in with most of those. One of the most important aspects to developer productivity is privacy and being free of interruptions. When Joel had his office space developed he made sure to stick by that. In most of the pictures in TFA you see a bunch of open space with a bunch of people with laptops crammed in. Good for social lives, bad for software development.

They missed Fog Creek.

I am in a similar situation as you...15 years in the industry and burnt out. I try and try to put myself in the mindset of "just work your 8 hours and collect your paycheck" but I can't. I WANT to have passion and excitement for my work, but just can't seem to find that anymore.

So what can we do about it? :-)

A lot of this depends on your life circumstances. Since you're married with kids the career change can be a scary challenge. However, perhaps you and your wife have an excellent financial position (i.e. low debt) and can afford to scale down your quality-of-life a teeny bit and you can take a pay cut. Or, if you're totally insane you can start your own company. Start a Subway franchise or something.

So here's some of the options as I saw them:

-Complete career change: The problem here is that this is kind of the same solution as "rewrite all the code from scratch". Read this to realize why this is a bad idea. You are throwing away *TONS* of sunk costs in experience and education.

-Go back to school (maybe at night) and learn another trade, then transition to that. Safe, but slow. Initially expensive.

-Get a hobby, part-time night job, or something that peaks your interest. I started teaching adult algebra classes at night and I love it! Yes, IT during the day still sucks but teaching at night makes it way more bearable.

-One-off career change...can be difficult but doable. Maybe hire a professional career counselor or resume writer.

The closest I've come to solving this dilemma is getting hobbies and part-time night jobs that scratch my itch. Also, I try to force some of the fun back into my day job. For example, once a week I'll take a few hours and just play with a new language or tool just for fun (although my boss would probably get mad if he found out I was on-the-clock).

Unfortunately, its hard to find a practical solution to career burnout. I believe in a lot of ways this is a spritual problem. i.e. "true happiness is wanting what you have not having what you want", etc. See if you can find satisfaction in your family, in making a salary to feed and care for them, and in focusing on fun stuff outside of work (camping, sports, gaming, arts&crafts, reading, whatever...). Difficult, I know. But be happy that your job is Mon-Fri 9-5 and you're not roofing houses or something REALLY sucky.

Hope this helps. Good luck.

This is an interesting discussion for me because I've experienced the whole thing in real life. My cousin has run a large, free, web-statistics tracking site. When he started it, it was running on PHP+apache-- He was just to the point when he was able to start making money off it, and I gave him some bad advice. I told him that if he was having performance issues, he should re-engineer the entire thing himself.

After 2 years building a web-server from scratch, he's in beta now. But during those 2 years that he wasn't improving (or maintaining) the existing code base, he lost all his thousands of free customers. He has no regrets, and his code behind it is awesome! It's fast, efficient, and modular. As far as code is concerned, it's like Michelangelo's David. From a purely coding perspective, it was the right decision. From a business perspective, it was a very poor decision. He could have a thriving business right now, but unfortunately for him, all he has now are a few prospective customers in beta.

I (on the other hand) have built a technology to enable certain kinds of web-apps for my personal site. It's in java so it's slower, and eats memory a bit. I could spend a year or 2 re-writing it in C, and know for certain there were no memory or performance issues. But that's not worth it to me. I can start getting paying customers now. From a business perspective it's more than enough. As my business grows, I simply need to upgrade my hardware.

My cousin spent a total of 3 man-years getting to where he is now (1 year for the original code-base, and 2 years for the current code-base). I've spent 1 man year for my current code-base. Assuming our time is worth only $30/hr, and that these part time, off hours man years are only 500 hours each, his cost was $60k more than mine was. I can buy a lot of hardware with that difference, and I'm collecting money at the same time.

From a coding perspective, it makes sense to spend an infinite amount of time to make your code-base perfect. In the real world, the right language is often what is most practical.

Note: This post was heavily influenced by Joel Spolsky's article Things you should never do

If you haven't read this already then you really need to: http://www.joelonsoftware.com/articles/APIWar.html

How many times have we blamed the poor performance of Windows on legacy code? How many times have we wished they just redesigned large chunks of their operating system? Well we finally got what we wanted and now we're realising it's not actually that good.

Driver issues? Surely that's a hardware manufacturer's problem (in most cases) but who gets the bad PR?
Improved security, but this breaks lots of existing programs, again it's the application developers that need to adapt but it's Microsoft who will get the bad PR.

I certainly wont be using Vista yet, it'll take time for everyone to get use to this new platform, but if they hadn't released it do you really think they'd have got things moving?

That's assuming that the best engineering decision is constant over time. Often the biggest messes are a result of a long sequence of people making the best decision at each stage.

Yes, it forces coders.

However, if you're a windows user, and you just upgraded to vista, you see these warnings/questions. What's your first response?

1. Man, I wish these crappy coders would learn when to require root access
2. Stupid Vista... I should go back to XP

Upgrading the security model from a non-visible one to one that requires user attention can be a bitch. MS has a lot of difficult decisions to make these days.

Just see http://www.joelonsoftware.com/items/2008/03/17.html.

(Now, if only someone could show me how to embed nice links here... :) )

P.S. I use Gentoo.

http://joelonsoftware.com/articles/fog0000000319.html

A bit long, but well worth it.

Looks like things are playing out as Joel predicted. It should be interesting to watch.

Since you live in the Bay area, it should be easier for you than if you lived in a lot of other places. You should try to look for internships. Talk to your college guidance/job counseling service. They may have some connections. Also talk to your classmates, you never know when someone's family may have connections. In other words, do some networking in the job sense. My recommendation is that you find a company where the software development pays the bills rather than serves a support role to the other parts of the company. Joel Spolsky of Joel on Software has some good recommendations. Paul Graham has his own opinion as well.

Since you're interested in software development the world of open source has lots to offer. Pick something that dovetails with your interests and start contributing to it. You'll only learn by doing and there's are plenty of opportunities to do that with free/open software. You'll be doing this for free, but you'll be gaining valuable experience. Pick a community that is active and has good developers so that you can learn some good practices.

I think Joel Spolsky was right about the eventual antidote to "messing with HTML/XML/Javascript/Ajax/etc." when he suggested that eventually these things would simply become the "instruction sets" that compilers target. GWT is an excellent example of that right now. Browser developers can continue to refine support for these standards and we can both use them and insulate ourselves from minor deviations from one browser to another. And, I dare say this is a much better idea than 'checking out xaml'.

It's market segmentation. people who own cd players generally have more money than those that only have cassete players. by selling the casette at a discount they can still sell enough to make it worthwhile and since for the most part no one with a good cd player is going to buy a cassete, it is not going to cut into their cd sales and they still come out ahead.

Joel on software wrote a nice overview of market segmentation on his blog:

http://www.joelonsoftware.com/articles/CamelsandRubberDuckies.html

The changes in UI between MS Office XP (which they're mostly using now), 2003 and especially 2007 are big enough that I have to retrain my users to use them, and frankly the cost of training my users to use 2007 is enough that I've been seriously considering moving them to OpenOffice.org.

I'm calling bunk on that for two reasons:
1) Office 2003 was virtually identical to Office 2000. Cost of retraining: $0.
2) Office 2007's UI is a better interface among every single Office user I've talked to. And that's in a company that has no training on Office at all. Of course determining this involves getting out of your little IT Manager office and actually talking to your users... why not try a pilot program with a couple secretaries and see how it works out?

I think the real reason is one of:
* You really, really hate Microsoft
* You're cheap and don't want to pay for upgrades.

Those are fine reasons, but at least don't delude yourself into thinking you're doing your users some kind of favor by keeping them on Office 2000. Tell your accounting department that Office 2007 supports a million rows in Excel and they'll be knocking down your door.

And BTW, if you move your users to OpenOffice, they'll hate you. It has crappy Track Changes support and Mail Merge, it has no "Normal View" for typing documents, it fucks up the Word Count feature in languages other than English, it won't run any of the VBA scripts they've built up over the years, and that's ignoring the horrible performance issues.

And also BTW, there isn't a standard file format because none of the formats proposed for standardization, except Microsoft's own, actually support all the features of Word. Joel On Software covered this recently: http://www.joelonsoftware.com/items/2008/02/19.html ... to be able to read Office files 100% correctly, your program needs to support every feature Office has and every feature Office *had* in the past. That's millions of man-hours worth of coding, and right now there's pretty much only one product that can claim that kind of feature-parity: Office.

Are you seriously an IT Manager? Do you make your users jobs easier or harder?

10 Never throw old code away.

20 If code is broken, GOTO 10.

MS Word used an intentionally obscured binary format that actually included random data from the hard disk (sometimes including "deleted" files that were recoverable using third party tools).

Actually, it was a feature of MS WORD's "Quick Save" function. Instead of writing the entire file to disk, it just wrote the delta and appended it to the file to speed up the file saving process.

Read the link for and interesting article.
http://www.joelonsoftware.com/items/2008/02/19.html

Indeed: the problem has been discussed extensively by Joel on Software.

More generally -- this isn't really a direct response to you -- I think the problem with articles like this one and many of the comments in this thread revolves around what people mean by shortage. I've got no doubt that there's a shortage of amazing developers at the pinnacle of software skill who also have the other skills employers demand: the ability to read and write well, mesh with others, etc. There's a shortage now... and there always will be. The same is true of virtually any intellectual profession, including law, architecture, writing, etc. Companies who need the all-stars will naturally have trouble finding them because there aren't many of them, as Joel explains, and most of them won't put up with much of the bullshit that comes from many workplaces. So you get articles about the "shortage" of talent, and people on /. refuting them, and no one paying attention to what the other means.

Anyhow, this is late in the discussion and unlikely to be modded up, so I guess the yelling-fest can continue.

I'm not taking that statement on faith. Everyone thought the entire Mozilla project was doomed to failure at the time. I remember trying to convince my employer at the time that our new project had to support netscape ( mozilla was always just supposed to become the next version of Netscape). But I lost that argument because it sucked, didn't support much css or work correctly with most websites in existence. Take a look at Joel's assessment of mozilla in 2003 when he first switched to firefox.

> And, it would give Microsoft
> developers, many of who are members of national bodies,
> an important forum where Microsoft has
> been shown to listen and respond to their concerns.
>
The conciliar tone of this response makes some fundamental errors:

1) The fallacy of lowering the bar: We could ensure that almost everyone has a medical degree by changing the medical degree exams to a potty training exam. Of course, if that were to happen, a medical degree wouldn't be worth the paper it was written on. Similarly, if a poorly documented, incomplete, sparsely reviewed (ODF's review took *years*), heavily manipulated standard proposal, is allowed to pass ISO, how credible would ISO standards be? If Patrick is sincere in wanting OOXML to pass as a proper standard, he'd propose that OOXML be sent back for a complete review.

2) The fallacy of appeasement to encourage reform: If Microsoft is unwilling to have OOXML go through at least as rigorous a review as ODF before standardization, then how on earth can Patrick expect that they'll hang around after standardization. One OOXML is standard, the pressure is off. If he *really* believes Microsoft is serious about standardizing OOXML, then disapproval would do nothing other than allow for OOXML to undergo a *real* review to iron out all the details.

3) The fallacy of "Let's just do this once...Never again, I promise": If you let Microsoft off the hook this time, how on earth can we turn them or any other major company down again?

4) The fallacy of assuming that OOXML is any good. Joel (a key former Microsoft developer) justified why OOXML is so complicated ( http://www.joelonsoftware.com/items/2008/02/19.htm l) and why no-one, even Microsoft is able to implement it from scratch (they use code from old versions of Windows). If OOXML is virtually impossible to implement, then what good is it?

5) The fallacy that OOXML solves any real need. There are virtually no OOXML documents out there (even if you include the various OOXML-like formats exported from MS-Office) so the "backwards compatibility" mandate. OOXML presents no other mandate other than getting the ISO stamp so Microsoft can get contracts that require ISO standards. If there's something legitimate missing in ODF, then it should be added to ODF, otherwise OOXML is pointless. And if "backwards compatibility" required, then DOC would make a *much* better thing to standardize for legacy data given that it's been frozen since Office 2000, it's been reverse engineered to death by OpenOffice and many other Office competitors, and most documents out there are (unfortunately) in the DOC format. Why isn't any effort spent on fixing a *real* need as opposed to a fake one?

Being "fair and balanced" is often the most popular position, but if a thief comes into your house and claims all your money, you'd be a fool or a wimp to settle on the "fair and balanced" approach of choose to splitting the difference. If ISO doesn't have the backbone to reject OOXML from fast track so it can be resubmitted for proper review at least as thorough as ODF, then ISO *will* be broken....which is just fine according to Microsoft since when you have no standards you can trust, defacto market standards win.

I completely agree with the above post. When hiring developers it is much more important to look for smart people, who get things done. Not for someone with a lot of keywords in a resume that match your particular environment. Smart programmers will be able to pick up the languages, concepts, methodologies and design patterns used in your current application whatever platform it's on.

A smart developer will be able to tell you whether your application is built in such a way that it can be maintained and expanded upon or if it's such a mess that it may be better to abandon it to re write on another platform. So the real answer to your question is to hire someone who is smart and let them have a lot of input into the decision about platforms, technology and such.

That being said if you can find a smart programmer who also has experience in your platform and in your business domain, that's the cats behind ;)

I do a lot of hiring of developers at the company I work for and I've found that my favorite person to read about hiring and interview practices is Joel Spolsky, check out http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html, it's a great article that I've used as the basis for my own interviewing technique. Also check out his archives at Joel On Software. He comments on interviewing and hiring practices a lot.

[i](silly thought - did you consider recruiting someone without the skills, then training them?)[/i]

Bad idea.... BAD IDEA.

Our company did this last year. We needed someone who could step into a web application role; the technologies were ASP.NET 2.0, MS-SQL 2005 and Visual Studio 2005. We hired someone (as a favour, not based on best-person-for-the-job merits) that had web application development experience using Java, Oracle and who-knows-what as an editor.

The company spent [b]almost $50,000 worth of salary[/b] while this guy went from complete fucking ineptness, to near-complete ineptness, to argumentative ineptness, to mere inetpness, to... oh, hey, you know how to edit an ASPX file now, good for you!! This was NINE MONTHS after he was hired.

Fifteen months in, he's still learning, and treating our software product like a research project, as opposed to something we need to ship updates to every few months. It's brutal.

I appreciate that developers need to be able to continually learn on the job, but [b]hiring someone with no skill will cost you money and give you no benefit[/b]. Don't do it. There are plenty of places out there where you can go to take lessons and write exams to help you become skilled at something, before you go get a job. That comes first. If you don't have money, chances are fairly good that your government will help you pay for it. ....

Joel Spolsky has written what I consider to be the definitive guide for hiring good developers: The Guerrilla Guide to Interviewing. Any software developer who is thinking about switching jobs, and anyone who finds themselves in a position of having to interview developers, should read it.

Before switching platforms, you need to consider this can imply a costly rewrite.
And this can be worse than you think:
    http://www.joelonsoftware.com/articles/fog0000000069.html
But yes, sometimes a platform can doom your ability to hire, when there is a very limited community community supporting it in your application domain.

I once joined a company developing 3D graphics+physics simulations, which somehow chose to use Borland Delphi as a programming platform (a Pascal dialect, quite competitive in some contexts, but not a popular choice for this type of applications).
This choice made it very difficult to hire experienced and competent graphics developers - who would dislike switching to a different language, and see it as a bad career move in a C/C++-centric industry. And I wouldn't blame them.
So what do you do then?

Switching can be a painful job ... the company went into serious trouble, but we fortunately recovered through the development of new applications, which were based on a more ubiquitous platform (while porting some libraries from the original code - see http://ivan.vecerina.com/code/delphi2cpp/ .

just my 2 cents worth --Ivan

Have you considered that you may be hiring wrong? i.e. hiring based on a bunch of keywords that represent the past rather than evaluating a person based on their ability to adapt to the future.

http://www.joelonsoftware.com/items/2007/06/05.html

As Joel Spolsky pointed out on his blog JoelOnSoftware, 99.999% is pretty much fictional.

99.999% over a year is 31.526 seconds.

No matter how good your staff, no matter how many people you have on site, no matter how robust your systems, no matter how many failsafes you have standing by, ready to be plugged in...

IF something does go down, even the fastest tech on earth is unlikely to identify, pull out, replace and have fired back up whatever the faulty item is in under 30 seconds.

99.999% uptime is essentially fictional. It's simply an impressive sounding number that says, "We'll do everything realistically possible to keep you up 100% of the time. In a typical year, you won't see anything bring you down. You can now tell your investors/clients this and make them feel warm and fuzzy."

It ignores the second part, "But, honestly, if it does go down, we won't have it back within 30 seconds, 100% of the time. Sorry, but welcome to reality. But, for what it's worth, our board's happy to pay you outage fees because it's a small enough risk and the amounts are capped enough, that we're happy to take the risk and costs in exchange for advertising a service we know no one can deliver."

Let's look at regulated phone service, the example in the original post. Can anyone point to a major carrier that hasn't had a major outage at some point? Be it an idiot in a switch room, a power outage affecting a whole side of the country, an anchor ripping up an undersea cable? And how many of them have actually been back within the mandated 30 seconds?

It doesn't happen. That two hour outage is going to take quarter of a millenium of absolutely no more faults to earn back at 30 seconds/year. With luck, it only hit one in 250 customers so you can pretend you're well within your 99.999% uptime but that 1 in 250 isn't really going to agree they got 99.999% after they were down for 1:59:30 more than their contract said they would be.

So, no, 99.999% doesn't exist. It's just a really cool story we tell ourselves whilst being willing to pay whatever the penalties are for missing it, on rare occasions, in exchange for great advertising.

But there are some problems with SLAs. The biggest one is the lack of statistical meaningfulness when outages are so rare... The proverbial "six nines" availability (99.9999% uptime) means no more than 30 seconds downtime per year. That's really kind of ridiculous... Think of it this way: If your six nines system goes down mysteriously just once and it takes you an hour to figure out the cause and fix it, well, you've just blown your downtime budget for the next century.

http://www.joelonsoftware.com/articles/fog0000000043.html

The Joel Test

      1. Do you use source control?
      2. Can you make a build in one step?
      3. Do you make daily builds?
      4. Do you have a bug database?
      5. Do you fix bugs before writing new code?
      6. Do you have an up-to-date schedule?
      7. Do you have a spec?
      8. Do programmers have quiet working conditions?
      9. Do you use the best tools money can buy?
    10. Do you have testers?
    11. Do new candidates write code during their interview?
    12. Do you do hallway usability testing?

Instead of thinking as recruiting as a "gather resumes, filter resumes" procedure, you're going to have to think of it as a "track down the winners and make them talk to you" procedure.

I have three basic methods for how to go about this:

      1. Go to the mountain
      2. Internships
      3. Build your own community*

It also helps if you decide how you're going to compensate them too.

Now that you've done the recruiting, do the interviews, which he's also discussed.

Further questions? Read his website. Mine's about books, so it's not likely to be all that helpful for programmers.

It also helps if you decide how you're going to compensate them too.

Now that you've done the recruiting, do the interviews, which he's also discussed.

Further questions? Read his website. Mine's about books, so it's not likely to be all that helpful for programmers.

It also helps if you decide how you're going to compensate them too.

Now that you've done the recruiting, do the interviews, which he's also discussed.

Further questions? Read his website. Mine's about books, so it's not likely to be all that helpful for programmers.

It also helps if you decide how you're going to compensate them too.

Now that you've done the recruiting, do the interviews, which he's also discussed.

Further questions? Read his website. Mine's about books, so it's not likely to be all that helpful for programmers.

I seem to remember Joel having good ideas.

Hire people who want to program. Hire the people who would program in their spare time if you didn't pay them. Those are the people you want.

For some reason I keep thinking Joel Spolsky has already shown that lines of code is a poor performance measurement metric. Of course now I can't find the exact article, but he shows how easy it is to game that measurement system.

Maybe MS does now want to move away from their old proprietary formats into new open ones. But the old formats were built over decades without that goal.

If you read Spolsky's analysis linked from this Slashdot story summary, you'll see how the formats "evolved" ("devolved" more like) withing MS goals often dictated by their unique marketing position.

The summary also points out with links to why this release might not actually indicate MS is really releasing their formats to break with that past after all.

When Excel started importing 1-2-3 documents, the right way to do that would be to create an importer to your own native format. Not to munge a new slightly different format into your existing structures.

I agree to some degree, but as a slight contrary point I find his silly insistence that Hungarian is a "good thing" and his constant pimping of FogBugz (especially the "this is usually a bad idea, but it's alright when we do it!" attitude of some of the posts to be a little annoying. He's definitely smart and makes a lot of sense though.

This is a good move.

They have recently also given away books, with similar goal: get as many people programming for their OS'es as they can.

Like several guys have pointed out, OSes don't sell themselves, the applications that are developed for the OS does.

[snide]Besides, students are just going to pirate the stuff anyway. Might as well win some much needed brownie points[/snide]

I feel that C++, *.NET, Java, etc. is the entire reason that computers need to be consistently faster and have more cores.

they simply are paid to get the programs out the door as quick as possible, regardless of the performance. Embedded Engineers have to do things a completely different way.

The reason, being Object Oriented programming.

I think by "Object Oriented Programming" and "C++, *.NET, Java" you mean "programmers who overengineer their designs." In that case, then you're right, embedded programming is one place where overengineering is deadly. In server and applications development, a certain amount of overengineering is rational, especially when you don't have an agile development process. In embedded programming (at least in my experience) a successful product release does not result in the deluge of feature requests that are the real reason for "bloated" software. A programmer who assumes that version 1.1 will have twenty times as many features as version 1.0 will design in a bunch of hooks and architecture so that version 1.1 can be released in a timely manner. Agile/XP programming provides a way to avoid overengineering to a certain extent, but one thing that agile/XP doesn't address is that it's much easier to delay version 1.0 than to delay version 1.1, because you don't have customers breathing down your neck yet.

They all wanted to become GAME PROGRAMMERS!

I dont buy either argument.

Has anyone profiled the code. Actually looked at where the slowdowns ARE. You know 'function x is called 18% of the time'. Then reorganizing the code to make it faster. You know actually code changes things like changing n^2 scans to log(n) scans. That sort of thing. Computer sciency work. All the arguments come down to 'i havent looked but i *GUESS* it is this'.

Has anyone run the code thru something like boundschecker? Memory leaks/overruns/underruns?! Good lord those are dead easy to find. There are tools out there that do it for you. Hell they even find subtle ones.

Compiling to machine code is a HACK. It will yeild some nice speedups. But does not address the core problem. No one is spending time actually restructuring the code to make it perform well.

I have worked on a couple of projects with 'many cooks'. You get to the point where you are afraid to change things as it will break a whole unrelated set of things. Firefox is almost there, but it is not too late!

Its is time to refactor!
see http://www.emulators.com/docs/nx01_intro.htm to see what you can do with just interperted code
see http://www.joelonsoftware.com/ about refactoring and what it can do for your code.

I'm not overlooking it. It's just that there is no objective standard for which approach is correct. Both have advantages and tradeoffs; they're optimized for different goals.

That's a childish approach to strategy. It reminds me of independent booksellers, who said "why should I make it comfortable for people to read books in my store? I want them to buy the books!" And then one day Barnes and Nobles puts couches and cafes in the stores and practically begged people to read books in their store without buying them. Now you've got all these customers sitting in their stores for hours at a time, mittengrabben all the books with their filthy hands, and the probability that they find something they want to buy is linearly proportional to the amount of time they spend in the store, and even the dinkiest Barnes and Nobles superstore in Iowa City rakes in hundreds of dollars a minute while the independent booksellers are going out of business. Honey, Shakespeare and Company on Manhattan's Upper West Side did not close because Barnes and Nobles had cheaper prices, it closed because Barnes and Nobles had more human beings in the building.

You must not have read much of what he's written about his business over the years. Way back in 2000, he posted a perfectly good explanation of why his business wasn't going to try to grow really quickly. A year later, he posted another article explaining why trying to grow quickly is such a monumentally stupid gamble (if you're the developer and not the VC).

Your example of Autodesk is pretty stupid. Autodesk was started in 1982, which was 26 years ago. They were a very early player in the market for CAD software, and they did a lot to shape it. They were in the right situation to grow almost as fast as the market for their kind of software. I'd imagine their sales data would probably support Joel's assertion that "good software takes ten years." Fog Creek, on the other hand, produces software in markets that are pretty much saturated, and they've only been around for 8 years. So far, everything seems to be going according to plans for Joel.

You must not have read much of what he's written about his business over the years. Way back in 2000, he posted a perfectly good explanation of why his business wasn't going to try to grow really quickly. A year later, he posted another article explaining why trying to grow quickly is such a monumentally stupid gamble (if you're the developer and not the VC).

Your example of Autodesk is pretty stupid. Autodesk was started in 1982, which was 26 years ago. They were a very early player in the market for CAD software, and they did a lot to shape it. They were in the right situation to grow almost as fast as the market for their kind of software. I'd imagine their sales data would probably support Joel's assertion that "good software takes ten years." Fog Creek, on the other hand, produces software in markets that are pretty much saturated, and they've only been around for 8 years. So far, everything seems to be going according to plans for Joel.

On live.com, Microsoft's search results suck.

The results are usually irrelevant. Not helpful.

If Microsoft eats Yahoo, we can expect them to throw away anything that was good in Yahoo.

For example, they bought the company that made Lookout and did not integrate the technology into MS Outlook. As a result searches in MS Outlook are excruciatingly slow if you have a large amount of emails. http://www.joelonsoftware.com/items/2007/12/24.html

When Google bought Youtube, they didnt squish it to replace it with google video.

When Apple bought Coverflow, they included it in their products.

When other companies buy companies, they tend to absorb their technology. Nowadays, in Microsoft's case it's only to steal traffic and to eliminate technological competition.

The law of Leaky Abstractions says otherwise.

That explains why SQL Server 2008 will be late.