Slashdot Mirror

"The simple answer is that there is a growing movement to reduce user options that can break applications."

The writer could have stopped at the first half of that sentence, and it would have been more concise and accurate.

"The simple answer is that there is a growing movement to reduce user options."

This isn't really new. UI design "experts" have been saying for years that delegating choices to the users is bad. The programmer should make a decision and stick by it.

That's a bit of an exaggeration. What they're actually saying is a bit more subtle and nuanced. For example, this article by Joel Spolsky discusses when you should and should not offer the user a choice. Basically, it boils down to whether the users of the software will care. He cites the silly Help database dialog from Win95 (where you had to tell the OS what kind of database optimization you wanted it to do on the Help file before you could search for a term!) as an example of the kind of choice that shouldn't be presented to the user. In contrast, if something is related to the task at hand, then the user probably wants fine-grained control over it: "If it's a graphics program, they probably want to be able to control every pixel to the finest level of detail. If it's a tool to build a web site, you can bet that they are obsessive about getting the web site to look exactly the way they want it to look."

The problem is that, like so many other good ideas over the years, this principle of UI design was bastardized and dumbed down by the corporate equivalent of a game of telephone. These days it's been reduced to "Choices are bad. Don't give the user a choice." And, of course, users hate it. This is the design philosophy behind Windows 8.

If you want a language that has no cruft there are languages you can switch to but not many people use them for the reasons stated a above.

Cruft is there for a reason.

What the computer does is complicated. We use the written high level language to generate the instructions that the computer actually executes to "do something." The instructions are what "do something." Someone might stare in puzzlement at why some seemingly irrelevant value is bit-shifted right 8 bits. No reference in the code to it. BUT... there might be some library function that needs it. Or something. A well-worn code base is typically a well-tested and reliable code base.

I'm not saying one should never re-architect a kludge to modern programming paradigms. However, one must be very judicious in reworking something that's been working well for a long time for a lot of users.

Yeah, this poisonous trend is baked deeply into the school of "UI design". It is now an article of faith among UI designers that letting the users choose is a bad thing. It should be the designers making a choice, and that should not only be the default setting, but the only setting. This article, written by Joel Spolsky way back in 2000, gives some insight into what these people are thinking when they take choices away from users.

Educate yourself: http://www.joelonsoftware.com/items/2008/02/19.html

Sorry... that URL should be:
http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html

Chapter 1 of Spolsky's "User Interface Design for Programmers", which is basically this article from his site: http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html/. You should try to decide for yourself how much this applies to your situation, but there's another set of articles, one called "Choices = Headaches" that you should look at as well. You may not agree with everything you read, and you won't get a simple answer to your question, but these will be food for thought.

It's not just the caffeine that benefits the company by stimulating workers, but also that you don't have staff doing daily coffee runs for a half hour.

Yes, this! Joel Spolsky said it best:

A programmer is most productive with a quiet private office, a great computer, unlimited beverages, an ambient temperature between 68 and 72 degrees (F), no glare on the screen, a chair that's so comfortable you don't feel it, an administrator that brings them their mail and orders manuals and books, a system administrator who makes the Internet as available as oxygen, a tester to find the bugs they just can't see, a graphic designer to make their screens beautiful, a team of marketing people to make the masses want their products, a team of sales people to make sure the masses can get these products, some patient tech support saints who help customers get the product working and help the programmers understand what problems are generating the tech support calls, and about a dozen other support and administrative functions which, in a typical company, add up to about 80% of the payroll. It is not a coincidence that the Roman army had a ratio of four servants for every soldier. This was not decadence.

I don't think the original poster's numbers are that odd. I think he just doesn't understand the big picture. More goes into creating a product than just engineering and if no one buys it, the engineering is entirely pointless.

In his article The Development Abstraction Layer, Joel Spolsky said "...support and administrative functions which, in a typical company, add up to about 80% of the payroll."
I highly recommend that article as there is a lot of great information in that article that can help with developing perspective on what really needs to happen to make a great product.

Back when Joel spent time on writing, Joel Spolsky of Joel on software had an interesting method for doing time estimates. His point was to go into a deep level of detail. Instead of handwavy "code the GUI" the only way to really get anything remotely close to a real time is to estimate everything down to at least half day, if not lower granularity. It's not the "oh you feel the time better" as much as to think of EVERYthing you need. If you go to a lower level, you may remember that dialog box that you didn't think of at the 25,000 foot level.

It would be interesting to see if anyone ever used it to improve their estimates. Even he "disavows" it now, preferring the method in his software tool. But I like the "the world is a big place, are you sure you're thinking of everything" that the older method pushed you to.

You get 100+ qualified applicants for every job.

Or perhaps they're actually not all-that-qualified.

Agreed. There's a good Joel on Software piece - things you should never do on why you should never start with a total rewrite.

The solution is hard, fix X. The mistake is thinking that starting again will produce a better result.

I notice a lot of developers struggle with generic, reusable designs in this manner because the abstract nature of such designs make them a little harder to understand,

Those benighted, simple developers who value simplicity in an API even have a phrase for those who live on a higher plane - Architecture Astronaut.

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

If you're arguing that abstraction and the attendant complexity are usually good, I'm afraid a lot of smart people disagree. I've used systems with far better domain abstractions (named in the thread), in fact I find it hard to think of a system with a worse set of abstractions.

The newer versions of drupal, which have added things instead of refining them, remind me of this article. I do feel that most full-time Drupal devs could do with stepping away from the madness despite their huge investment in time learning it, and checking out other frameworks and languages (if you think all PHP CMSs are the same, look at other options). It's fine to think Drupal is the best CMS available, but you should do so from a position of knowledge having evaluated the other options, and if criticisms are made, accept them where they have some foundation (however small), and try to improve it. There is no need to start a holy war on behalf of Drupal the one true universal module loader.

Re PHP I actually think the last year or two they have shown signs of sanity with things like the new password API and changes in the latest version, perhaps they read that article and took it to heart!

Here is probably the source for the info on the excel bug. Starts about halfway through.

Yeah, except that the main use of Excel is apparently to make lists. (You might need to scroll down a little.)

No, that doesn't do it either. Take Azureus (Vuze). They had so many options they did a tree view of pages. And then it was still too complicated, so they created an entirely new interface, but still allowed access to the old "classic" interface.

Now it used to be that my Aseureus installation used to download 4 files at once. But now it only downloads one at a time. I'm pretty sure, at one time when I was trying to get a download working faster, I changed something in the advanced options to make it do that. And now I can't find it.

Yes, there are 48 pages of options, several of which will affect how many downloads you have, and I can't find the one that I changed before.

It's not good enough to have options hidden in "Advanced" sections, because they get changed, maybe by the main user, perhaps by someone borrowing the machine. Possibly by someone supporting the machine who thought he was helping. And then someone has to find what option was changed and change it back.

Here, read this.
http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html

Are you perhaps thinking of this Joel on Software article "How Trello is different", in which Joel writes:

Over the next two weeks we visited dozens of Excel customers, and did not see anyone using Excel to actually perform what you would call “calculations.” Almost all of them were using Excel because it was a convenient way to create a table.

What was I talking about? Oh yeah... most people just used Excel to make lists. Suddenly we understood why Lotus Improv, which was this fancy futuristic spreadsheet that was going to make Excel obsolete, had failed completely: because it was great at calculations, but terrible at creating tables, and everyone was using Excel for tables, not calculations.

Your source could have just been another writeup of the same Microsoft investigation, of course.

Do you think the TCO of changing .NET or Java platforms every couple of years is cheap?

No way José!

Joel Spolsky addressed the issue some time ago: http://www.joelonsoftware.com/articles/fog0000000339.html

Joel Spolsky wrote a number of articles, years ago, that are really relevant. I'm going to link to and quote some of them:
The Joel Test: 12 Steps to Better Code:
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?

Joel says you should be getting at least ten of those twelve. Sounds like you aren't. So, next article is relevant:
Getting Things Done When You're Only a Grunt:

You could just leave, I suppose. But presumably, there's some reason you're stuck there. The stock options haven't quite vested, there's no better place to work in Podunk, or perhaps your boss is holding someone you love hostage. In any case, dealing with life on a bad team can be infuriating. But there are strategies for improving your team from the bottom, and I'd like to share a few of them.

And those are:
"Strategy 1 Just Do It", setup a build server, write the make file to automate the build process, etc.
"Strategy 2 Harness the Power of Viral Marketing", setup your own bug tracker. Use it for your own bugs. If someone sends you a bug in an email, add it to the tracker and reply saying that it would be so much easier if the person just added it directly to the tracker themselves. Setup local version control. Use it. Etc.
"Strategy 3 Create a Pocket of Excellence", be excellent. Write specs and follow them. Write schedules and follow them. Etc.
He continues with "Strategy 4 Neutralize The Bozos", "Strategy 5 Get Away From Interruptions" and "Strategy 6 Become Invaluable".

Another article Top Five (Wrong) Reasons You Don't Have Testers explains that you need an independent Q&A team with real power, while Things You Should Never Do, Part I says don't throw out code and rewrite from scratch and Incentive Pay Considered Harmful says what it says on the tin.

Browse around the site and read some of the other articles as well. There is a lot of good advice there.

Joel Spolsky wrote a number of articles, years ago, that are really relevant. I'm going to link to and quote some of them:
The Joel Test: 12 Steps to Better Code:
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?

Joel says you should be getting at least ten of those twelve. Sounds like you aren't. So, next article is relevant:
Getting Things Done When You're Only a Grunt:

You could just leave, I suppose. But presumably, there's some reason you're stuck there. The stock options haven't quite vested, there's no better place to work in Podunk, or perhaps your boss is holding someone you love hostage. In any case, dealing with life on a bad team can be infuriating. But there are strategies for improving your team from the bottom, and I'd like to share a few of them.

And those are:
"Strategy 1 Just Do It", setup a build server, write the make file to automate the build process, etc.
"Strategy 2 Harness the Power of Viral Marketing", setup your own bug tracker. Use it for your own bugs. If someone sends you a bug in an email, add it to the tracker and reply saying that it would be so much easier if the person just added it directly to the tracker themselves. Setup local version control. Use it. Etc.
"Strategy 3 Create a Pocket of Excellence", be excellent. Write specs and follow them. Write schedules and follow them. Etc.
He continues with "Strategy 4 Neutralize The Bozos", "Strategy 5 Get Away From Interruptions" and "Strategy 6 Become Invaluable".

Another article Top Five (Wrong) Reasons You Don't Have Testers explains that you need an independent Q&A team with real power, while Things You Should Never Do, Part I says don't throw out code and rewrite from scratch and Incentive Pay Considered Harmful says what it says on the tin.

Browse around the site and read some of the other articles as well. There is a lot of good advice there.

Joel Spolsky wrote a number of articles, years ago, that are really relevant. I'm going to link to and quote some of them:
The Joel Test: 12 Steps to Better Code:
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?

Joel says you should be getting at least ten of those twelve. Sounds like you aren't. So, next article is relevant:
Getting Things Done When You're Only a Grunt:

You could just leave, I suppose. But presumably, there's some reason you're stuck there. The stock options haven't quite vested, there's no better place to work in Podunk, or perhaps your boss is holding someone you love hostage. In any case, dealing with life on a bad team can be infuriating. But there are strategies for improving your team from the bottom, and I'd like to share a few of them.

And those are:
"Strategy 1 Just Do It", setup a build server, write the make file to automate the build process, etc.
"Strategy 2 Harness the Power of Viral Marketing", setup your own bug tracker. Use it for your own bugs. If someone sends you a bug in an email, add it to the tracker and reply saying that it would be so much easier if the person just added it directly to the tracker themselves. Setup local version control. Use it. Etc.
"Strategy 3 Create a Pocket of Excellence", be excellent. Write specs and follow them. Write schedules and follow them. Etc.
He continues with "Strategy 4 Neutralize The Bozos", "Strategy 5 Get Away From Interruptions" and "Strategy 6 Become Invaluable".

Another article Top Five (Wrong) Reasons You Don't Have Testers explains that you need an independent Q&A team with real power, while Things You Should Never Do, Part I says don't throw out code and rewrite from scratch and Incentive Pay Considered Harmful says what it says on the tin.

Browse around the site and read some of the other articles as well. There is a lot of good advice there.

Joel Spolsky wrote a number of articles, years ago, that are really relevant. I'm going to link to and quote some of them:
The Joel Test: 12 Steps to Better Code:
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?

Joel says you should be getting at least ten of those twelve. Sounds like you aren't. So, next article is relevant:
Getting Things Done When You're Only a Grunt:

You could just leave, I suppose. But presumably, there's some reason you're stuck there. The stock options haven't quite vested, there's no better place to work in Podunk, or perhaps your boss is holding someone you love hostage. In any case, dealing with life on a bad team can be infuriating. But there are strategies for improving your team from the bottom, and I'd like to share a few of them.

And those are:
"Strategy 1 Just Do It", setup a build server, write the make file to automate the build process, etc.
"Strategy 2 Harness the Power of Viral Marketing", setup your own bug tracker. Use it for your own bugs. If someone sends you a bug in an email, add it to the tracker and reply saying that it would be so much easier if the person just added it directly to the tracker themselves. Setup local version control. Use it. Etc.
"Strategy 3 Create a Pocket of Excellence", be excellent. Write specs and follow them. Write schedules and follow them. Etc.
He continues with "Strategy 4 Neutralize The Bozos", "Strategy 5 Get Away From Interruptions" and "Strategy 6 Become Invaluable".

Another article Top Five (Wrong) Reasons You Don't Have Testers explains that you need an independent Q&A team with real power, while Things You Should Never Do, Part I says don't throw out code and rewrite from scratch and Incentive Pay Considered Harmful says what it says on the tin.

Browse around the site and read some of the other articles as well. There is a lot of good advice there.

Joel Spolsky wrote a number of articles, years ago, that are really relevant. I'm going to link to and quote some of them:
The Joel Test: 12 Steps to Better Code:
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?

Joel says you should be getting at least ten of those twelve. Sounds like you aren't. So, next article is relevant:
Getting Things Done When You're Only a Grunt:

You could just leave, I suppose. But presumably, there's some reason you're stuck there. The stock options haven't quite vested, there's no better place to work in Podunk, or perhaps your boss is holding someone you love hostage. In any case, dealing with life on a bad team can be infuriating. But there are strategies for improving your team from the bottom, and I'd like to share a few of them.

And those are:
"Strategy 1 Just Do It", setup a build server, write the make file to automate the build process, etc.
"Strategy 2 Harness the Power of Viral Marketing", setup your own bug tracker. Use it for your own bugs. If someone sends you a bug in an email, add it to the tracker and reply saying that it would be so much easier if the person just added it directly to the tracker themselves. Setup local version control. Use it. Etc.
"Strategy 3 Create a Pocket of Excellence", be excellent. Write specs and follow them. Write schedules and follow them. Etc.
He continues with "Strategy 4 Neutralize The Bozos", "Strategy 5 Get Away From Interruptions" and "Strategy 6 Become Invaluable".

Another article Top Five (Wrong) Reasons You Don't Have Testers explains that you need an independent Q&A team with real power, while Things You Should Never Do, Part I says don't throw out code and rewrite from scratch and Incentive Pay Considered Harmful says what it says on the tin.

Browse around the site and read some of the other articles as well. There is a lot of good advice there.

Subject: Movie Theaters are dying for the same reason

Payphone booths and arcades are. Plain and simple. Too many other options.

I'll be more willing to accept your illustration if you plug the leaks. What's the alternative to a movie theater if you don't want to have to avoid spoilers for a year while waiting for a movie to come out on home video and pay-per-view? What's the alternative to a phone booth for calling a cab if you don't spend hundreds of dollars per year for a cell phone plan or for stripping off your mundane clothes to reveal your superhero uniform? What's the alternative to an arcade for lag-free multiplayer or for trying games that use expensive specialized controllers?

Rent 3-6 month old movies at Redbox for a little over a buck

3-6 months? Hop wasn't at Redbox until about 13 months after theatrical release.

> Allowing mixed tab/space for indentation is a nightmare too.

Agreed. The correct usage is:

        Spaces for indentation, Tabs for alignement, because ALL text editors are still too stupid to understand dynamic tab stops!

> there definitely are also coding styles that are simply a terrible idea.

I've found over the years as I've tried various coding standards that they all have _some_ merit. Usually because a programmer was trying to solve a particular problem and didn't want anybody else to fall into the same trap -- so he made a religion out of it !

That is some of those are based on ideology instead of practicality (cargo-cult mentality.) Or said another way:

    "Any ideology taken to an extreme is usually never a good idea in the long run."

An expert needs to balance anarchy (no rules) with structure (rules). That is, an expert, knows WHEN _to_ and when _not_ to break the rules. ;-) The reason Microsoft Hungarian notation SUCKS is because somebody went to the extreme and didn't understand what the fuck they were doing -- forcing everyone to become a partial compiler. Joel has a rant on this: http://www.joelonsoftware.com/articles/Wrong.html

const char * pszText = "Hello World";

What the fuck does 'sz' even add EXCEPT NOISE. You don't care that the compiler has to zero-terminate a string. We ALREADY can tell it is a string by the variable -name-. All you care is about the basic types: is it a pointer? an array? an numeric?

Instead:

const char *pText = "Hello World"

Is _good_ enough. It adds SOME information without getting lost in the dogma of naming.

I personally use a modified SHORT Hungarian notation because I deal with various graphics/math types all day long.
i.e.
* a Array of
* b Boolean
* i Iterator
* g Global
* m Matrix
* n any Number / Count / Sum / Total. Why the hell do you care if it is 8-bit, 16-bit, 32-bit, or 64-bits or SIGNED or UNSIGNED ?!?!
* p Pointer
* s Singleton
* r Reference
* t table/hash/object
* v Vector
* q Quaternion
* _ Member variable // Only because 'm_' is too verbose. Using a single character prefix keeps everything aligned up. ;-)

A one character prefix (for the most part) is a good balance between conveying information and minimizing noise.

i.e. pointless contrived example to demonstrate

// Globals
    int gnThing; // -type- and -variable- should be aligned in columns; /. eats whitespace
    Thing gaThing[ SIZE ];
 
// I also append an underscore in parameters so people can visually tell the arguments will be getting modified.
int Count( int & bIsFragmented_ )
{
    bIsFragmented = false;
 
    int .. nTotal = 0; // ingore the periods; /. sucks for code formatting
    Thing *pThing = &aThing[0];
    for( int iThing = 0; iThing < gnThing; ++pThing )
    {
        if( pThing )
            nTotal += pThing->nSize;
        else
            bIsFragmented = true;
    }
    return nTotal;
}

Some of the old "standards" no longer make sense today such as limiting comments to 80 chars. We all have wide-screen monitors these days and if you are too dam lazy to learn how to toggle word-wrap in your editor maybe you should consider another career.

Is to achieve this: http://www.joelonsoftware.com/articles/Wrong.html -- make things that are wrong be more obviously wrong. Using discipline and coding standards is just one part of the appropriately paranoid developer's defensive programming toolkit.

Absolutely shocking to me that the one solution that is the most obvious (a user actually educating themselves about the tool they rely on) is the one that has somehow now been deemed "magical" due to mass ignorance.

It's easy to see how that happened. Information processing is abstract, you don't see any moving parts that make it obvious what's going on. Add the endless versatility and power of computers to that and computers are arguably amongst the most difficult devices to interact with. But to make personal computers (including the mobile computers we don't call PC's) popular and accessible the software industry has put such a strong focus on user friendliness and intuitive interfaces that the expectation has become that you don't need to learn or know anything to use a computer, it is expected to magically work. This push towards knowledge-free computing has helped to put computers in nearly every home, and I certainly see that as a positive effect. Unfortunately it has also resulted in a large majority of computer users who, apart from some operational knowledge, have no idea at all what a computer actually is and leaves them completely helpless when something goes wrong. Abstractions are far from perfect, and I keep having this nagging feeling that we would have fewer helpless users, *and* fewer problems with malware and phishing etc., if the OS builders had made interfaces that helped people to understand computers instead of trying to camouflage what they actually are. I suspect that quite a few people who do have the intellectual capability to understand what a computer is are kept in the dark because it's abstracted away too much. That doesn't mean I want everybody to use a Linux CLI or something like that, and I don't know what UIs would have been like if keeping the computer visible and transparent had been a goal as well as making it easy to use, but I do think the attempts to camouflage what's going probably confuse people more than they help in the long run.

I say fuck 'em.

No, fuck the corporations that misinform people about what they're buying and leave it to their friends and family to clean up the mess.

Apple doesn't need to sue, they just need to add a few Core* frameworks every year like they always do. GnuStep replicates the OSX/iOS Foundation and AppKit libraries. That's really good, but their API hasn't kept up with Apple's block/closure idioms or libdispatch, almost all new code being written on the Mac today uses these. Also, while they've done the lord's work with their own CoreData, just about every new application these days links against at least AddressBook.framework and CoreAnimation -- it's hard to find even an FTP client on the Mac that doesn't use animated transitions.

Apple's never used DRM on their OS, they've just kept the upgrades coming and make sure developers start using them -- in exchange Apple aggressively markets its OS upgrades to its userbase, so developers don't lose their users becuase they don't upgrade. That's where MS failed in the end, people fell off the upgrade carousel, developers stopped chasing new Win APIs... This was Joel Spolsky's point when he argued that MS had failed as a platform company.

Joel Spolsky coined the term "Commoditize your complements" ten years ago. Steam, who sells software, wants consoles (or PCs acting as consoles) to be as cheap as possible, so as many people as possible can afford to have hardware that will run their games.

Every product in the marketplace has substitutes and complements. A substitute is another product you might buy if the first product is too expensive. Chicken is a substitute for beef. If you're a chicken farmer and the price of beef goes up, the people will want more chicken, and you will sell more.
 
A complement is a product that you usually buy together with another product. Gas and cars are complements. Computer hardware is a classic complement of computer operating systems...
 
All else being equal, demand for a product increases when the prices of its complements decrease... why don't the video chip vendors of the world try to commoditize the games, somehow? That' s a lot harder. If the game Halo is selling like crazy, it doesn't really have any substitutes. You're not going to go to the movie theatre to see Star Wars: Attack of the Clones and decide instead that you would be satisfied with a Woody Allen movie. They may both be great movies, but they're not perfect substitutes. Now: who would you rather be, a game publisher or a video chip vendor?

Now that the cheapest hardware out there is ridiculously capable, of course Steam wants you to throw a free OS on there and turn it into a Steam appliance. Which can also browse the web, play videos, send emails, make Skype calls, etc etc etc.

I agree that bad code is the norm. My recent experience was a large Perl codebase, belonging to the merger of about four different companies that did the same thing but [of course] had different business processes. The code was in the gigbyte range with tons of templates and about four foreign lanugage versions.

However the code base covered many corner cases in the business model, pricing and marketing and [in the main] worked.

Thirty odd years of experience has shown me that a re-write of something like this is usually a disaster, I agree with Joel: http://www.joelonsoftware.com/articles/fog0000000069.html

The least-worst way is rolling reviews through sections of the system and a very comprehensive set of regression tests. But the point is that, at some stage, one will have to engage with 'bad code that works', it's the way of the world.

The Joel Test: 12 Steps to Better Code by Joel Spolsky

I've come up with my own, highly irresponsible, sloppy test to rate the quality of a software team. The great part about it is that it takes about 3 minutes. [...] The bummer about The Joel Test is that you really shouldn't use it to make sure that your nuclear power plant software is safe.

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

Perl Shop Maturity Checklist: Technical Concerns by chromatic

• Do you use source control?
• Do you stage deployments? Do you have a defined process for deployment? Do you have a defined process for rolling back a failed deployment?
• Do you have code that "no one knows what it does"?
• Do you have critical business code written more than five years ago that people are afraid to touch?
• Do you have coding standards? Does most of your code follow it?
• Can you tell who wrote each piece of code by its style?
• Do you have a standard technology stack? Across multiple applications?
• If some applications don't meet it, do you have plans to refactor them? Do you refactor at all?
• Do you have a defined process for handling bugs? ... for handling feature requests? ... for scheduling delivery?
• Do you have a training or mentoring process?
• Do you have multiple developers? Can you retain developers for longer than one year? Five years?
• Do you use automated tests? Do your tests all pass? ... before you check in? ... before you deploy?
• Do you have backups? ... for servers? ... for developer workstations? ... and do you test them regularly?
• Are developers their own system administrators?

In short, how predictable is your development process? Can you manage risk? Do you? When surprises happen, how much work is it to recover?

Perl Shop Maturity Checklist: Social Concerns by chromatic

• Do you have a coding competence test when hiring? Does it include real code? Did your developers have a hand in writing it?
• Do you have code reviews? Before deployment? Before merge?
• If you have multiple developers, do they all have access to every piece of code you have?
• Do you pay a prevailing developer wage for your region? ... commensurate with experience?
• Do you have overtime? ... required?
• Do you allow telecommuting? ... part time? ... full time?
• Do you have a training budget? ... for books? ... for travel?
• Do you have well-defined roles? ... technical leadership roles? How do you resolve conflicts?
• Do you have a defined process for scheduling features? ... triaging bugs? ... resolving schedule conflicts?
• How do you handle surprises?

Perl Shop Maturity Checklist

Ask them how well they score on The Joel Test (see also this post with some suggested updates). This won't necessarily teach you about how much legacy code they have floating around, but it's a useful barometer. Part of what favorably impressed me about the place I am working now is that the VP I talked to (1) knew what it was, and (2) knew how they scored.

Ask how refactoring is viewed, if time is scheduled for specific cleanups of known "code rot"; if at least it is possible to include refactoring of relevant code as part of building new features. A too loose policy (which I've never seen but I suppose is possible) could be as bad as not budgeting for it at all; either can produce "legacy" quality code. Intelligent refactoring is part of the cost of maintenance (code "taxes", even).

> Which breaks once the 257th distinct element or the 257th distinct attribute is added.

You DO know how UTF-8 works, right?
http://www.joelonsoftware.com/articles/Unicode.html

You seem to think Constant bit-rate is the only solution. Here's a hint for the solution: Variable bit-rate

> And the registry is still like HTML in that one has to parse an arbitrary-length string for keys.
Depends on how it is implemented. Guess what, the OS guys have had to solve this _exact_ problem in File Systems. We've only had the concept & solution of B-Trees+ for "ages."

Even though it is about ZFS, it shows some of the B-Tree concepts.
i.e.
http://www.scribd.com/doc/43973847/How-Zfs-Works#page=10

Embrace, Extend, Extinguish.

Microsoft freely admits it, and when everyone jumps on the TypeScript bandwagon, the carpet will be pulled out from under you.

This seems reminiscent of the Excel vs Lotus 123 war and how Microsoft won. Joel Spolsky has a great article describing the tactics M$ used to win the war.

The basic idea was to eliminate barriers that would keep people from switching from Lotus 123. Below are some exerts from the article. I think there are some interesting parallels to Typescript and javascript.

Barrier:They have to convert their existing spreadsheets from 123 to Excel
Solution:Give Excel the capability to read 123 spreadsheets

Barrier:They have to learn a new user interface
Solution:Give Excel the ability to understand Lotus keystrokes, in case you were used to the old way of doing things

If he really wants to know what incentive structure would be better for his IT staff, he should ask them to design one for him. Give them a budget limitation, as appropriate.

The point of an incentive system is to leverage the maximum amount of work for the minimum investment.

Examples would be: providing $10 worth of pizza to the guys working through lunch in place of paying them an extra $50/hr; awarding a $1,000 bonus to the guys who worked 80 hours last week and would have got an extra $2,000 at their hourly rate or $3,000 if you paid them overtime; giving out a trip to the most productive team to go carting, costing you maybe $500 but getting an average of an extra $300 worth of work out of all four teams competing.

Best case, you ask them to come up with incentives, they'll take it seriously and come up with entirely fair 1:1 compensation for their time. At that point, you may as well have just paid them better in the first place, offered them paid overtime in place of OTE or hired more, as you're not getting any increased profitability from their fair program.

Most likely though, they'll come up with a program that's easy for them to game and get more compensation than the extra effort actually merits. The guys who always come in early anyway will likely set up an early arrivers bonus, those who already hit 40 tickets a day will set a bonus threshold at 40.

If the point of an incentive system is to get extra work for less than, you know, hiring extra people to do that extra work, you are by definition asking for more for less. Asking people to set up the system for tricking extra work out of them? Probably not that successful.

To be fair though, very, very few incentive systems actually work anyway. The smart figure out how to game the system (give a bonus for clearing the most tickets and you suddenly notice some guys only take the quick and easy tickets, refusing to touch the hard ones). The lazy figure they're not going to get the bonus anyway and don't make an effort. Worse, it divides your team as those who aren't getting the incentive complain about how unfair the system is and it drives a wedge between them and those who were smart enough to figure out how to game it. Joel on Software has written a bunch of good articles on this, here's one of them.

Thanks for a better response, though I don't agree completely with you. Apple painted itself into the DTP corner neither by design and nor by choice. They just couldn't deal with the tsunami of IBM-PC clones from Compaq, Dell, HP etc. that MS very cunningly licensed DOS/Windows to. Apple's computers were general purpose computers able to run any applications, but they failed to attract developers like MS was able to and the prices kept it within the reach of only graphic designers and not the general public. In that sense, they were and are competing with Microsoft. A college kid goes to Best Buy and looks around for a laptop, and might just pick the Macbook Air instead of an Asus Ultrabook. Not only DTP users use Macs, and that's especially true nowadays.

How many of these kids are DTP users? http://i44.photobucket.com/albums/f49/Voodoogoon/big-mac-class.jpg

http://osxdaily.com/2010/08/05/70-of-college-freshman-use-macs/

They also make an OS which is a miserable failure. The only reason Microsoft is still in existence is due to anti-competitive behavior and vendor lock-in.
Microsoft is currently trying to recast itself as a company capable of being in competition with Apple once again. They have failed miserably for the simple reason that they cannot possibly do it. They are incompetent morons

While MS did have luck like IBM picking DOS for the OS, they did make software in those times which was simply better than the competition. Office Word, Excel, Powerpoint etc. lagged behind their competitors like WordPerfect, Lotus 1-2-3, etc. but by the typical 4th version or so, they were just better in objective ways and thus won the market. Did you ever try using Lotus Notes? Try it, you'd pay a million to run screaming to Outlook or Pine within a day. IE 4 and 5 were similarly better than Netscape 4 while Netscape didn't have a major version for 3 years smack in the middle of the dot com boom while implementing a new version.

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

Windows 95 was similarly better than any competition out there, and still OpenOffice or whatever Exchange/AD clone don't have the features and polish of MS Office/Exchange/AD.

The LAMP stack had success on the server side, but OpenOffice, Zimbra, OpenLDAP etc. have nothing on the competition. While I do agree that lock-in etc. played a role, you're underestimating the mis-steps made by competitors and that MS' software was actually better at the time it beat the rivals.

How does Apple being a hardware company negate it? People go to Best Buy or Amazon to buy a laptop, not to pick up a shrink wrapped OS disc, and that's where the real sales numbers are at. You're the moron here.

Also for just one more example, http://en.wikipedia.org/wiki/Common_Desktop_Environment

http://www.youtube.com/watch?v=Z2CprTGEIS8

Though I am sure you'll find some nonsense revisionist reason to blame MS for CDE sucking, instead of blaming the actual companies and people who developed it.

MS did have market forces working for it, but you totally ignore the missteps, bumbling and stumbling by the competition while MS executed well, across DOS, Windows, Office etc.

Take Netscape for example, it was good the first few versions and then later IE 4-5 was actually objectively better.
http://www.joelonsoftware.com/articles/fog0000000069.html

For the latest example of such a thing, see Sony stumbling with the PS3, while the XBox overtook it in sales.

The most successful tech entrepreneurs had significant technical skills. And that absolutely mattered - without those skills, they have no way of evaluating technical employees and applicants. If they weren't in charge of product development themselves, then they at least had to know who they should hire to run product development.

For example: Bill Gates was an extremely effective developer and architect (worth reading is Joel Spolsky writing about a time he met with Bill Gates). Larry and Sergei of Google were well-respected developers doing graduate work at Stanford. Steve Jobs wasn't at good at the technical stuff as Woz was, but he had tinkered with electronics and done technical work for Atari.

Many MBAs of the world would like to think that managers don't need to understand the details of their product line. But that's simply not true - the manager that understands the details will hire better people, make wiser decisions about how to accomplish tasks, and have a more realistic outlook of what the organization can do.

But herein lies the problem: anonymous and software development are not comparable, not unless you want to stretch the definition of problem statement. But that's just Reductio ad Absurdum just to fit an argument.

Anonymous could be reduced to an algorithm and so can software. Another aspect they have in common is both usually depend on continuous optimization.

Which problem of decision making are we referring to here?

Just gathering a mass of emotional people does not produce good decisions without direction. Not all programmers make good design decisions and if you look at open source software you'll see a lot of great software ideas designed horribly. Napster was an example of a great idea with a horrible design.

How does this draw lessons for software development, and to general projects and missions with identifiable players? Is it a legitimate argument that requires Anonymous as an example (which is what the article says, remember the topic)?

I think it's more Anonymous can learn something from the software development process. Anonymous is like a piece of "software"that offers conceptual and philosophical cover as an umbrella organization. The problem is that concept and philosophy are receiving the least attention while the most attention is being put into the hacktivist aspect which may actually be the least important function of Anonymous as a concept.

Separations of duties are subject (for good or bad) to managerial control (or lack thereof, there is such a thing as bad managerial control by omission). Considering that the premise of the original article intends to draw lessons from Anonymous in the context of excessive control, then that puts micro-management as the main focus of the discussion.

Micro-management is just bad management. Separation of duties can be a part of good management practices.

And that typically ends horribly in the form of architect astronauts building crystal citadels. I've seen in the enterprise and in the defense sector. The moment you separate design from hand-to-hand development, you are typically doomed. Development gives immediate feedback about the consequences of architectural/design decisions.

I'm not saying it has to be separate to the point of the designers not being able to read or understand the code. The designers should understand the code. Designers should review the code continuously. Designers don't have to actually do the coding because a lot of coding isn't much more than implementing the design typing stuff in and testing it for bugs. The hardest part of software development is the design process and that is the part which requires abstract thinking while the coding part just requires following of orders, checking your work for bugs to make sure it works, all which could be part of a blueprint or set of instructions. Consider that most development teams want to produce a lot of code for cheap it's going to cost a bit more money to try and take junior coders and turn them into lead designers.

You, as a designer (or as part of a design team) can create design blue prints send to junior developers (local or offshore), but you need to be substantially involved in day-to-day development (in addition to conducting frequent code reviews to ensure your juniors/minions are implemented the design as intended.) The only time I've seen such partitioning working out is when the designers are involved in coding as well. It rarely works otherwise.

When did I say the designer shouldn't be involved? The designer has to keep track of everything to make sure it's all going according to the design or make changes to the design.

The problem with Anonymou

It was in 2003 when he was revamping his forums. He sent out an email to members that was similar to what he posted here but slightly different, including what you're describing:

If you post something and it gets deleted, we'll use a cookie to actually continue to show you your own post. We just don't show it to anyone else in the world. 9 times out of 10, you won't even know your post has been deleted. If you delete cookies or go to another computer, you may catch us, but most of the time people don't even notice that their post was removed.

It was Joel first. I, too, remember reading about it many years ago. (Jeff's post is just a year old.) Here's a mention of it from 2004:

http://joi.ito.com/weblog/2004/12/20/happy-trolls.html

(See comment #2)

[later]

Aha! I knew I had it. Way back when, he was revamping his community, and he, briefly, made it so you had to sign up to get an email to hear when it would be launched. I still have that email. It is entitled "Building Communities with Software" but it differs slightly from this. According to Google there is exactly one copy of the original email on the WWW and here it is.

If you post something and it gets deleted, we'll use a cookie to actually continue to show you your own post. We just don't show it to anyone else in the world. 9 times out of 10, you won't even know your post has been deleted. If you delete cookies or go to another computer, you may catch us, but most of the time people don't even notice that their post was removed.

Well my point wasn't so much that the design is perfect, but rather that all the people who are screaming "change for change's sake!" are idiots. There are plenty of reasons behind the changes in Gnome Shell, and I doubt anything was changed just for "change's sake".

1. I'm not sure I agree that the benefits of the overview drop off over time. After using Gnome 3 for a few months, I can't stand having to go back to using Windows machines with taskbars. If you prefer the taskbar, you can go install the Bottom Panel extension. But if we agree that initially, Fitts's law does hold, shouldn't the overview be the initial default?

2. Tabs are nice, but they are an application-level mechanism for something that should be handled at the window manager level. Maybe you're right that the application-centric model can't replace tabs, but that in itself isn't a reason to go window-centric. Again, if you don't like it, you can install the Windows Alt Tab extension which makes it behave like Windows.

3. On my computer, the power button brings up a dialog box which lets me restart or shut down. If I don't respond in 60 seconds, it shuts down by default. If I want to suspend, I just close my laptop lid. This works perfectly for me and I suspect most if not all people.
I agree that it is a bit strange that they chose to only put suspend there, and I don't see why the full selection of shutdown options (lock screen, switch user, log out, restart, suspend, hibernate, shut down) can't be there. My guess is that they were trying to avoid the mess of a shutdown menu that Vista had. But the argument is really a storm in a teacup - the menu is a secondary method of shutting down, and the primary one is via the hardware controls that every computer has.

4. I find the drag-the-window-to-the-side thing to be useful for viewing two windows side-by-side. It's great now that we have these ridiculously wide monitors. Why didn't they provide an option to turn this off? Well 1) most users shouldn't need to do this and 2) they did: dconf-editor lets you do this.

I'm not sure I agree with all of your points, but thanks for making an intelligent argument about them unlike most people here. It's a really refreshing change from "OMG CHANGE FOR CHANGES SAKE!!!!"

Beware of the second system effect. http://en.wikipedia.org/wiki/Second-system_effect

Rewriting code can kill you in the short term. http://www.joelonsoftware.com/articles/fog0000000069.html

Or help you in the long term. http://notes-on-haskell.blogspot.com/2007/08/rewriting-software.html

I recall another similar article about a rewrite of MS Office, and what a mistake it was...

What the second essay is missing is that, if you followed Joel's advice which is - refactor - modularise - improve then by the time you get to the long term, your software will be almost as much re-written as in the first case but will do more. In fact it may have become two pieces of software; one which does the aim of your rewrite and another one which provides the compatibility features for peple who need the old feature set.

Isnt this how Netscape died?

According to Joel Spolsky...

Rewriting from scratch is probably the worst thing you can do. See this article by Joel Spolsky,,

Beware of the second system effect.
http://en.wikipedia.org/wiki/Second-system_effect

Rewriting code can kill you in the short term.
http://www.joelonsoftware.com/articles/fog0000000069.html

Or help you in the long term.
http://notes-on-haskell.blogspot.com/2007/08/rewriting-software.html

I recall another similar article about a rewrite of MS Office, and what a mistake it was...

This has been marked as redundant, but it isn't. If you look at the 101 things wrong with Windows Phone list you will see that most of these things are not wrong with the iPhone. Most current Nokia customers will find transferring to an iPhone or Android phone easier than transferring to a Nokia Windows Phone. To a large extent this is because Windows Phone is lots worse than other systems (who ever heard of an alarm which doesn't work when you turn the phone off since the 1990s?) but it's also because Windows Phone is designed to match with the rest of Windows at the expense of the normal smartphone experience. This is the crucial thing which is killing Nokia; any knowledgable/experienced customer will be unhappy with Windows phone and Nokia's most valuable customers are the ones who have been buying a new Nokia phone at least once a year every year for the last ten or more years.

Even if Nokia does make a several million sales now, and that seems unlikely when you exclude phones stored in warehouses, the customers they are getting are the ones who just choose the "smartphone" with the lowest price. As these customers become more discriminating they will want to move to one of the more advanced smartphone platforms such as iOS.

It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time

That's just flat out untrue. Everything around us is constantly improving. Database techniques, database systems, file systems, operating systems, APIs, networking, hardware, engineering principles, and the trends that accompany these changes, libraries that do a lot of the stuff you did manually, etc. I've seen fairly large JS apps written years ago before wide adoption of tiny-yet-powerful libraries reduced by over a factor of 30x in code size. That's moving non-DRY code into a more maintainable fashion. It's sound architecturally. You see, Joel also advocates this: http://www.joelonsoftware.com/articles/fog0000000007.html. This is in many ways contradictory to that very statement. While you may not necessarily have MORE EXPERIENCE from the team re-writing it, you have the advances in computing which are constantly growing. To deny that this would have a significant impact in re-engineering a product is foolish.

As much respect as I have for Joel and his experience, some of his beliefs are just wrong in the world of software engineering.

That may be true of most any software, but in almost no case is it wise to do so. Read: http://www.joelonsoftware.com/articles/fog0000000069.html

Yes, but ... that is a response to the miserable failure that the project already is. The fundamental problem, is "If there's one thing every junior consultant needs to have injected into their head with a heavy duty 2500 RPM DeWalt Drill, it's this: Customers Don't Know What They Want. Stop Expecting Customers to Know What They Want. It's just never going to happen. Get over it." --Joel Spolsky.

The customers, in the DOD's case, are combat leaders, not program managers. They don't know what they want. They know what they don't like about what they have, and they think they want whatever vendor presentation is given to them. Then, add 5 layers of committee in the JCIDS process, and it can never work.

The system is fucked, but not substantially worse than in the rest of industry for large software projects.

Like every large software project it deserves a rewrite from scratch because it's full of cruft, but nobody will ever find the time to do it.
At least some refactoring and de-crufting is done from time to time if some dev gets pissed off enough. Not something that happens in commercial SW development unless the code is hopelessly broken.

Every time someone says this they should be forced to sit in the corner and and copy this essay by Joel Spolsky on things you should never do 5000 times and give a copy to each of their friends together with an essay about what they have learned from this punishment.