4 ms·

The more I read Joel Spolsky, the more I realize how wrong he is. He's like the Thomas Friedman of software. He writes lots of things that sound good, but aren'

The more I read Joel Spolsky, the more I realize how wrong he is. He's like the Thomas Friedman of software. He writes lots of things that sound good, but aren't actually true. For example: In fact, there are lots of great reasons for bloatware: For one, if programmers don't have to worry about how large their code is, they can ship it sooner. And that means you get more features, and features make your life better (when you use them) and don't usually hurt (when you don't). Every single part of that statement is false. Your programmers should be worrying about how large their code is. If they're not, and your competitors are, then your competition will release a program that does everything your program does, but better and faster. So what if they're a couple months (or even a few years) behind? First mover advantage is relatively short-lived, anyway. Microsoft Word wasn't the first word processor and Microsoft Excel wasn't the first spreadsheet. Google wasn't the first search engine. Facebook wasn't the first social network. As far as more features being helpful when you use them and harmless when you don't, well, that's inaccurate too. I find it very ironic that he uses Excel as his poster child for this, since the addition of features has absolutely hurt Excel's usability. These days, Excel is a tool that's comparable to vim or emacs. It's very powerful, but it has a ferocious learning curve to match. Moreover, he overlooks the fact that more features mean more bugs. I think the success of various web-based, minimalist tools has shown that users are quite willing to accept fewer features, if the features that are present work flawlessly. And even the points that were true as of publication (e.g. ever shrinking prices for CPU cycles and RAM) are no longer true today. If you're writing code today, CPU cycles are definitely not free. You get roughly 4 billion cycles per core per second on a desktop, and somewhere between 1 and 2 billion if you're on a mobile device. Memory is slightly less constrained, but it's rare for desktops to ship with more than 8 GB of RAM, and it's unheard for mobile devices to have more than 1 or 2. So no, I don't think bloatware is a "mental health problem". I think it's a real issue, and one that's only going to get worse as we run into the limits of Moore's Law.

tonylemesmer 13y ago
more processors are running on batteries too now and the improvements on those aren't keeping up at Moore's law pace.
jmduke 13y ago
Every single part of that statement is false. Your programmers should be worrying about how large their code is. If they're not, and your competitors are, then your competition will release a program that does everything your program does, but better and faster. So what if they're a couple months (or even a few years) behind? First mover advantage is relatively short-lived, anyway. Microsoft Word wasn't the first word processor and Microsoft Excel wasn't the first spreadsheet. Google wasn't the first search engine. Facebook wasn't the first social network. You're equating code size with code quality, which in my opinion is an unqualified assumption. I'd further argue that its not as if programming hours exist in a vacuum, and its not as if one makes a binary choice whether or not to spend time reducing code size; development time is a precious, precious thing. When given the choice between: - reducing the size of Microsoft Excel from 15mb to 14mb -- and thus increasing sales by X, where X is the number of people who had hard disk space for 14mb but not 15mb - and implementing some sort of stretch goal feature (let's call it PowerPivot v0.0.1), and thus increasing sales by Y, where Y is the number of people who make their spreadsheet software purchase decision based on the presence of that feature I'm fairly confident X < Y.
- quanticle 13y ago
  You're equating code size with code quality, which in my opinion is an unqualified assumption. Unfortunately, most of the software engineering literature disagrees. We know few things in software engineering. One of them is more code == more bugs. Your comment about X > Y is true, but you're replacing one false binary choice with another. Again, as Apple has demonstrated over and over again with every single one of their products, fewer features, implemented well will outearn products that have more features implemented poorly. So, I'd argue that the choice isn't between reducing the size of Microsoft Excel from 15MB to 14MB and adding a stretch goal feature. It's between keeping Excel at 14MB (or whatever its old size was), fixing bugs and polishing the hell out of it or growing Excel to 15MB and adding some more buggy half-assed features to fill out the checklist on the back of the box.
  - gruseom 13y ago
    Unfortunately, most of the software engineering literature disagrees. We know few things in software engineering. One of them is more code == more bugs. Quite so. I wish there were more research into the consequences of this. And more teaching of it too, for that matter. It ought to be a much bigger deal than it is.
themodelplumber 13y ago
>> if programmers don't > Every single part of that statement is false. Your programmers should be Uhh...you're saying they "should be worrying" and he's saying they don't have to be. Those are not mutually exclusive positions. > As far as more features being helpful when you use them and harmless when you don't, well, that's inaccurate too Second time you made a statement after this fashion--I see the pattern. Your position is that Spolsky is not allowed to write about things that other people do that are wrong. > So no, I don't think bloatware is a "mental health problem". I think it's a real issue Pretty sure Spolsky feels that way too! What an argument.
WildUtah 13y ago
"The more I read Joel Spolsky, the more I realize how wrong he is." -parent "There are trivial truths and the great truths. The opposite of a trivial truth is plainly false. The opposite of a great truth is also true." -Niels Bohr
fuzzix 13y ago
"The more I read Joel Spolsky, the more I realize how wrong he is." You're lucky you've just read him. I've used his software. In fact, I've written software to integrate one of the most popular revision control systems with his software - I think Fog Creek may be pretending git does not exist. How did this integration work? Same as all the others, update of data via GET request, tut tut :)

tonylemesmer 13y ago

more processors are running on batteries too now and the improvements on those aren't keeping up at Moore's law pace.

jmduke 13y ago

Every single part of that statement is false. Your programmers should be worrying about how large their code is. If they're not, and your competitors are, then your competition will release a program that does everything your program does, but better and faster. So what if they're a couple months (or even a few years) behind? First mover advantage is relatively short-lived, anyway. Microsoft Word wasn't the first word processor and Microsoft Excel wasn't the first spreadsheet. Google wasn't the first search engine. Facebook wasn't the first social network. You're equating code size with code quality, which in my opinion is an unqualified assumption. I'd further argue that its not as if programming hours exist in a vacuum, and its not as if one makes a binary choice whether or not to spend time reducing code size; development time is a precious, precious thing. When given the choice between: - reducing the size of Microsoft Excel from 15mb to 14mb -- and thus increasing sales by X, where X is the number of people who had hard disk space for 14mb but not 15mb - and implementing some sort of stretch goal feature (let's call it PowerPivot v0.0.1), and thus increasing sales by Y, where Y is the number of people who make their spreadsheet software purchase decision based on the presence of that feature I'm fairly confident X < Y.

quanticle 13y ago
You're equating code size with code quality, which in my opinion is an unqualified assumption. Unfortunately, most of the software engineering literature disagrees. We know few things in software engineering. One of them is more code == more bugs. Your comment about X > Y is true, but you're replacing one false binary choice with another. Again, as Apple has demonstrated over and over again with every single one of their products, fewer features, implemented well will outearn products that have more features implemented poorly. So, I'd argue that the choice isn't between reducing the size of Microsoft Excel from 15MB to 14MB and adding a stretch goal feature. It's between keeping Excel at 14MB (or whatever its old size was), fixing bugs and polishing the hell out of it or growing Excel to 15MB and adding some more buggy half-assed features to fill out the checklist on the back of the box.
- gruseom 13y ago
  Unfortunately, most of the software engineering literature disagrees. We know few things in software engineering. One of them is more code == more bugs. Quite so. I wish there were more research into the consequences of this. And more teaching of it too, for that matter. It ought to be a much bigger deal than it is.

themodelplumber 13y ago

>> if programmers don't > Every single part of that statement is false. Your programmers should be Uhh...you're saying they "should be worrying" and he's saying they don't have to be. Those are not mutually exclusive positions. > As far as more features being helpful when you use them and harmless when you don't, well, that's inaccurate too Second time you made a statement after this fashion--I see the pattern. Your position is that Spolsky is not allowed to write about things that other people do that are wrong. > So no, I don't think bloatware is a "mental health problem". I think it's a real issue Pretty sure Spolsky feels that way too! What an argument.

WildUtah 13y ago

"The more I read Joel Spolsky, the more I realize how wrong he is." -parent "There are trivial truths and the great truths. The opposite of a trivial truth is plainly false. The opposite of a great truth is also true." -Niels Bohr

fuzzix 13y ago

"The more I read Joel Spolsky, the more I realize how wrong he is." You're lucky you've just read him. I've used his software. In fact, I've written software to integrate one of the most popular revision control systems with his software - I think Fog Creek may be pretending git does not exist. How did this integration work? Same as all the others, update of data via GET request, tut tut :)