Slashdot Mirror

Joel Spolsky, another engineer-turned-architect writes thoughtful, entertaining, straightforward essays on these topics and other elements of software management based on his experiences at MSFT (regardless of your opinion of their business practices, they are certainly successful at orchestrating large, complex software projects) and, more recently, at his own company.

This stuff is such good reading that I've converted most of it into Plucker format for browsing on my PalmOS device. You never know when you'll need it for reference or inspiration.

Some personal favorites: The Joel Test of effective s/w development processes, painless software schedules, writing effective (read: convincing) functional specifications, and plenty of other gems.

Joel Spolsky, another engineer-turned-architect writes thoughtful, entertaining, straightforward essays on these topics and other elements of software management based on his experiences at MSFT (regardless of your opinion of their business practices, they are certainly successful at orchestrating large, complex software projects) and, more recently, at his own company.

This stuff is such good reading that I've converted most of it into Plucker format for browsing on my PalmOS device. You never know when you'll need it for reference or inspiration.

Some personal favorites: The Joel Test of effective s/w development processes, painless software schedules, writing effective (read: convincing) functional specifications, and plenty of other gems.

Joel Spolsky, another engineer-turned-architect writes thoughtful, entertaining, straightforward essays on these topics and other elements of software management based on his experiences at MSFT (regardless of your opinion of their business practices, they are certainly successful at orchestrating large, complex software projects) and, more recently, at his own company.

This stuff is such good reading that I've converted most of it into Plucker format for browsing on my PalmOS device. You never know when you'll need it for reference or inspiration.

Some personal favorites: The Joel Test of effective s/w development processes, painless software schedules, writing effective (read: convincing) functional specifications, and plenty of other gems.

Joel Spolsky, another engineer-turned-architect writes thoughtful, entertaining, straightforward essays on these topics and other elements of software management based on his experiences at MSFT (regardless of your opinion of their business practices, they are certainly successful at orchestrating large, complex software projects) and, more recently, at his own company.

This stuff is such good reading that I've converted most of it into Plucker format for browsing on my PalmOS device. You never know when you'll need it for reference or inspiration.

Some personal favorites: The Joel Test of effective s/w development processes, painless software schedules, writing effective (read: convincing) functional specifications, and plenty of other gems.

"But many VB programs are spaghetti, either because they're done as quick and dirty one-offs, or because they're written by hack programmers without training in object oriented programming, or even structured programming.

"What I wondered was, what happens if you take top-notch C++ programmers who dream in pointers, and let them code in VB. What I discovered at Fog Creek was that they become super-efficient coding machines."

What they should do is perhaps re-design IIS, and use as much existing (heavily peer reviewed) code as possible.

Read the Gartner story here and then the whole spiel here. Joel's a highly opinionated person, but we tend to agree on a lot of things.

If you're trying to get someone to move away from VSS, and are looking for more opinions on it (I haven't seen any actual *facts* yet, but there are plenty of opinions), a reasonably respected one would probably be Joel Spolsky's (from Joel on Software). He was the Microsoft "Program Manager" from VBA (the version of Visual Basic that Office uses for scripting).

Basically, MS doesn't use it internally - they don't trust it. Apparently they use a lot of their own stuff in development (for example -- Joel was on the Excel team, and they all used Excel for project planning, and added in project planning features, making it reasonably good for development planning. Here are the details). For NT (-> 2K -> XP) they used something called SLM, which was replaced by something else. Here's a USENIX paper on it.

His company has a bug tracking system ("FogBUGZ") too, and if you buy a site license ($1995) -- which covers the whole project team -- you get the source and are allowed to modify it and use your modified versions internally. See here for more info. It doesn't integrate with VSS, unfortunately ;-)

This really means, "don't re-invent the wheel". If your project goal is to get working software package, it is quicker, easier, and hopefully has fewer bugs to work with and existing project and try to achieve synergy than starting another similar oriented project from stratch.

See: Never do this

If you just want to write your own text editor that is fine too, but the benefit isn't necessary as great as what is possible through colloration.

On the contrary, being able to write native MS-Word documents is absolutely essential. Otherwise you will not be able to exchange documents with your co-workers who are still using MS-Word.

It comes down to what Joel Spolsky calls "eliminating barriers to switching". And it is not only barriers to switching in. Being unable to switch out if something turns out to be a bad decision (e.g. having dozens of documents that can only be converted to MS-Word using cut-and-paste - and you don't have time for that) will also prevent people from adopting another word processor.

On the contrary, being able to write native MS-Word documents is absolutely essential. Otherwise you will not be able to exchange documents with your co-workers who are still using MS-Word.

It comes down to what Joel Spolsky calls "eliminating barriers to switching". And it is not only barriers to switching in. Being unable to switch out if something turns out to be a bad decision (e.g. having dozens of documents that can only be converted to MS-Word using cut-and-paste - and you don't have time for that) will also prevent people from adopting another word processor.

"As much as MS would have it otherwise, most Office users are only using a very small subset of the functionality available."

Joel Spolksy (former MS employee) has a great article on why this doesn't make sense - everyone who's tried to do this has failed because even if most poeple use 5% of the features they all use a different 5%, so if you do that you'll get to about 5% of the users.

Too bad they're all using a different very small subset. As Joel Spolsky put it, the road to Word is littered with the corpses of untold numbers of "light" word processing packages that decided to only implement that "very small subset". Many of them failed because, duh, nobody uses [insert one of: auto-correct, word count, mail merge, anything else that some developer thought wasn't important enough], but it turns out that when you actually get to market, all those things that the naive developer thought were just more Microsoft bloat turn out to be deal-breakers for the consumer.

Joel's favorite example is word count. He mentions one "light" word processor whose developers knew nobody actually uses word count, so they left it out. When the reviewers tried to use the program to write its own review, what was the first thing they did? They tried to get a word count to see if they were writing too long. Guess what? Bad review, and bad sales, and it's just another corpse on the highway to Word...

I would point you to this, where Joel Spolsky talks about what some would call "feature bloat". It's not. Different people use different features. Some people in accounting need certain features, some people in academia need other features, and leaving some of those features out alienates *somebody*. And if you want to write the most used piece of software in the world (read: MS Office), you don't alienate anybody.
The same is true of Linux distros. Some people need the server services provided (email, FTP, web), but I never did. Does that mean they should disappear? Certainly not! All of the things that are in the distros are there because somebody, somewhere uses them, and is a big part of Linux's soaring popularity.

At least according to this guy. That claims that "good software takes 10 years". (There was a slashdot story on this a while back, but I couldn't find the link.)

Heffel

What about the CueCat? :)

Grrr...you preview a story and somehow between preview and submit you munge it up. In this case I apparently deleted a &gt. Bleh.

Anyways that link was to http://www.joelonsoftware.com/stories/storyReader$ 351

BTW: Could someone please tell me why Slashdot inserts random spaces, screwing up links and such?

I'm not suggesting that every company should be sueing Microsoft, but rather that vendors should have ZERO restrictions when installing Windows, and if they decide that as a value added they'll replace Solitaire with Megataire, then so be it: Let customers decide among true options rather than letting Microsoft dictate that even if it's beneficial to the customer, vendor Y can't do anything because that might give them a "in" into the software market. For too long Microsoft has dominated through brute force, and their domination has led to lots of software companies that have , and that's just sad.

I have massive respect for the folks in Redmond, and personally I love a lot of their product, but the reality is that they are a monopoly and they have been using that position to stop competition from ever taking root. As a Microsoft apologist for many years they have gone too far too many times, and I no longer find their actions acceptable.

I'd agree with the article that the Open Source offerings currently have many limitations when compared to the commercial ones, but this is more due to their lack of maturity than anything else.

We should remember that oracle & db2 have had over 20 years to get to where they are now. Have a look at this article to see what I mean about maturity of products.

However the open source community has several advantages and disadvantages over the commercial players. 1. we dont have all the legacy bloatware which makes the commercial offerings so large 2. we're able to design using current best practice, not something which was dreamed up 20 years ago and no longer applies (no I'm not talking about the relational model but things like distributed storage, sans, nas etc).

However, we also don't have the guarentee that the original developers will still be here in 10 years time, working on the software and adapting it for new needs. Admit it, how many people are prepared to dedicate their careers to a single piece of software? not many. so can you understand why commercial companies are less than eager to use open source for critical/production systems?

Human Task Switches Considered Harmful

He's got many good rants on that site.

Human Task Switches Considered Harmful

He's got many good rants on that site.

There is a nice article on Joel called Human Task Switches Considered Harmful explaining how context switching is extremely damaging for programmer's productivity. He of course does not have any statistical data to back it up with, but it is a convincing read if you have worked on more than one programming task at a time for whatever reason. Most managers who have not done programming themselves unfortunately do not understand this.

There is a nice article on Joel called Human Task Switches Considered Harmful explaining how context switching is extremely damaging for programmer's productivity. He of course does not have any statistical data to back it up with, but it is a convincing read if you have worked on more than one programming task at a time for whatever reason. Most managers who have not done programming themselves unfortunately do not understand this.

Something to show your boss, really.

Anyway, Joel Spolsky also wrote a nice article about it recently ... worth mentioning here I'm sure.

http://www.joelonsoftware.com/stories/storyReader$ 300

I suggest everyone read Joel on Software. He has a lot of good information for programmers and site management. One of his articles is how to interview. He lists several things, most of which are really good for any interviewer (be they in software development or not). For example, his main point, "Smart and gets things done."

Anyway, I'm rambling. Check the site out. Lots of good information.

I suggest everyone read Joel on Software. He has a lot of good information for programmers and site management. One of his articles is how to interview. He lists several things, most of which are really good for any interviewer (be they in software development or not). For example, his main point, "Smart and gets things done."

Anyway, I'm rambling. Check the site out. Lots of good information.

There's a lot of really good articles on this site, and I recommend anyone who's involved in software development to take the time to go along and have a read through. You might not agree with it all, but there's plenty of useful tips and heaps of common sense, which is so often lost in the corporate world. Start in the archives here.

He may have a point, but the "number of lotus users" graph might have some correlation to "the number of PCs in use" graph. The size of the market has increased so much it doesn't really prove much. I know Joel tends to think older software is better, hence this article entitled "Things you should never do, part 1" where he chastises anyone who has ever re-written anything from scratch, saying that it is a waste of a huge investment. I don't know. I certainly think refactoring code is often necessary. When does it stop being refactoring and start being a re-write?

For example, why did Microsoft become involved in a highly public argument with the Justice Department? Was that really necessary for profit?