Slashdot Mirror

That's the worst plan ever... :/

Java on Linux is great if you're running a server and your using java to serve web pages and talk to oracle or whatever. But if your program has a gui or you want people to install it without getting paid then don't use java. In a few years when java is GPL and the kinks have been worked out better then maybe it will be ok, but right now java sucks.

Java on Linux is an on going maintainance nightmare because there are so many JVMs and different implementations of the class libraries. Which would be fine if there was at least one that didn't suck...

Also doing a rewrite is a bad plan. C# is a fine language so just stay with what you know. There is no reason to do a complete rewrite when it would be easier to make it work with mono.

http://www.joelonsoftware.com/articles/fog00000000 69.html

read Joel Spolsky's Camels and Rubber Duckies article on how to determine a price for things... at the end, you'll be wiser, but no better off in determining what price should be if you have a single product and a variable market!

also of more general interest on how the price of items can be set is The Undercover Economist (indirect link to Amazon), where he touches on the dotcom boom and microsoft's monopoly.

No, I define it as "not complete garbage, and has a big enough user base that I won't be completely on my own if I use it."

How is it useful to define success in that way? The grandparent was talking about looking at Sourceforge to avoid sifting through a bunch of hobby projects that aren't going anywhere.

You might as well have said this:

For example, in your list is Coke and Pepsi. Both might have millions of users. But both are soft drinks so they are (within limits, no fight here) interchangeable. Therefore each Coke user is a loss for Pepsi and vice versa. You could say, that if one of them really were successful, the other would not exist anymore.

You sound like someone who could benefit from this article.

If it's a core business function -- do it yourself, no matter what.

Addressing your points:

1) How do you know a GUI application from a non-GUI one? What about programs that are run locally, but viewed remotely, and vice versa? What constitutes a "GUI" application?

2) But you are allocating different types of "memory"! See Leaky Abstractions for more information on this. Your "everything is memory" model sounds nice, but lacks a few key components.... When I fclose() a file, I have a STRONG assurance that the file has been saved and wouldn't go away if the power failed. That's not the case in your "everything is memory" model...

3) You are either talking about a security nightmare or pixie dust. How does computer B know that it's OK to run code from computer A? See other comments on #4

4) Capability security requires somebody to set up all those !#@!@# permissions. POSIX, by contrast, is very simple and requires little effort to maintain. Is POSIX ideal in all situations? No. But it's adequate in most circumstances without a lot of effort, and it's usually better to have a "just barely suits" possibility with a decent default than a perfect possibility with a lousy default. Perhaps that explains why your touted EROS operating system died on the vine?

Good rant. See also The Law of Leaky Abstractions.

Adobe have deservedly copped criticism over the years, but one great thing they've shown by example is that if you *do* let go out of specs (as they did with PDF), you can still be a viable business. More than viable. Adobe is still the #1 name in PDF/PS, but they do so alongside competitors (GhostScript/View and the zillion PDF generation tools). Yet Adobe is still making money.

Compare that to Sun with Java. Sun just wouldn't let go, so it never got beyond being just another product that competitors had to *take down!* One of those was Microsoft, but they themselves made the same mistake with Microsoft Word. Remember how DOC files used to be the "standard" (cough) for distributing documents on the web? Now it's all either PDF or HTML. If MS had let go, maybe, people would have used that?** In the long run, when we're talking about data which *needs* to be interchangable and not tied to one software vendor, an open spec will win. Especially a better one! (PDFs look the same. Word DOCs don't!)

(Reading this and feeling good Adobe? *great*. Now please head on over to Joel and learn about user interface design http://www.joelonsoftware.com/uibook/chapters/fog0 000000057.html Beyond [PageUp/PageDown], Adobe Reader's interface is very badly designed. The preferences make me weep and why can't I bookmark a la Visual Studio? And please stop trying to stuff every scripting concept known to humanity into the PDF spec, because all you're doing is turning PDF into the ultimate Trojan vector! Had to get that off my chest...)

Anyway, PDF and PS still rock and I'm glad they won!

** = Yes, Microsoft did make a feint with their Office XML, but everyone recognizes it for the debacle it is. Sorry Dad! ;-)

Looks like Microsoft forgot to send Zonk this week's cheque in the mail ;)

...or laptop...

"Look at all the crap Excel spreadsheet "systems" and badly-designed Access database "applications" that exist in every company."

Some people shouldn't throw stones.

Here's one source of data that shows a 5:1 to 10:1 difference in productivity for programmers, even after correcting for quality:

http://www.joelonsoftware.com/articles/HighNotes.h tml

This guy has some data that show 2-3x difference, up to 22x depending on how you interpret the data.

http://www.webfoot.com/blog/2006/12/07/programmer- productivity/

Steve McConnell's _Rapid_Development_, p 12, cites 7 academic studies claiming 10:1 productivity measures. Variations of teams vary by 3-5:1.

I've personally helped manage someone very senior who was consistently produced 1/5th of what I would. We'd schedule a problem for 2 days for me, or 2 weeks for him.

And as Joel pointed out in the first article, the problem isn't just that lesser programmers aren't as productive, but that there are some things that they just can't do.

I'm firmly convinced that many of the less productive programmers wash out relatively early in their career, before they start hitting system architecture and other challenges that greatly exceed their abilities.

Actually, VT can be used to enable VMWare Server (the free version) to run 64-bit guest OS's on 32-bit hosts ( http://kb.vmware.com/KanisaPlatform/Publishing/73/ 1901_f.SAL_Public.html). Although, in my experience the performance can be somewhat iffy (http://discuss.joelonsoftware.com/default.asp?biz .5.437372.14).

http://www.joelonsoftware.com/articles/fog00000000 18.html

It is true that the iPhone isn't cheap, but it's also not expensive when compared to similar phones, which... aren't yet available. Like myth number one, this idea rests on the assumption that prices are infinitely scalable along a regular incline. They are not.

First, it creates a viable platform for developers, who can actually sell a product instead of simply trying to subsist in a tiny market on shareware donations.

This has become the top battle cry of Microsoft slaves. One of the top three features of Microsoft's iPod Killer was that "it didn't scratch like the iPod."

Hrm. Well, I seem to remember an article at Joel Spolsky's Site about why he thought VB was a decent tool in ways. Remember, it has no memory management; I've done memory management, and I never want to do it again unless rains of fish will occur. It's not that it's hard, it's just that it's silly for me to do. How can you possibly feel differently?

Additionally, if VBA didn't exist you'd have to write C++ to do simple macro'ing in Office products. It's profitable, but it bites the big one as far as interesting programming jobs are concerned. Trust me on that one.

But 1850's houses are *better* than modern houses, you do know that don't you? The sad thing is I actually suspect your analogy still holds however, there is little evidence software is getting better quality over time, simply broader in scope.

Joel On Software is a good site if you want to understand some of the issues in software engineering, in particular this article springs to mind.

http://www.joelonsoftware.com/articles/Development Abstraction.html

What Makes Software Development So Hard?

Asked and answered in 1987, and still spot-on. No Silver Bullet: Essence and Accidents of Software Engineering

See also: The Iceberg Secret, Revealed.

Avoiding dataloss is perhaps the best reason for having a native file format, at least for existing applications.

I think this is a good point, particularly relevant both for existing applications and for areas of rapid innovation where it's not yet clear what should be in the app or the format. I consider myself corrected (and am somewhat embarrassed to have overlooked this in my previous post). I am not convinced it is the best case for word processing though, so I'm curious if you have any specific insights there.

Social constructivist theories of technological development describe the stabilization of the technology, at which point differing interpretations - often corresponding to different technical designs - converge on a single understanding of the technology. Word processing in particular is an established class of application for which consensus has been reached regarding its role and feature set[1]. According to this reasoning, as innovation slows, the benefits of custom formats would evaporate while the merits of standardization increase. I would therefore expect gravitation towards using open formats by default, with custom formats reserved for niche uses in need of application-specific features.

Significant innovation, I suspect, would tend to be understood not in terms of "word processing", but would be differentiated into new classes of application, which at a later date might (or might not) get folded back into word processing proper. HTML and blog post authoring strike me as two current examples of this.

None of what I say, however, is a result of direct experience in consumer application development, so your experience may point to other outcomes.

[1] Modulo a few exceptions; I'm sure this represents the vast majority of people - far more than Joel's 80% (though I think Joel overrates convergence - witness the iPod, game machines, portable DVD players, and the proliferation of other single-task technologies).

The internet is already being treated like a toll road. To connect, you pay an ISP. Taking the analogy further: To talk to Google, you send a packet to them, and they respond back with a packet. The current system has you pay your ISP for your packet (upload speeds) and Google's packet (download speeds) over their network. Google pays their ISP for your packet (their download speeds) and Google's packet (their upload speeds) over their network. Then the two ISPs cooperate to make the connection work. Thus, each ISP is paid for both packets.

Net neutrality is great because you know that no matter who you connect to (or how), it will be treated the same way by each ISP. Without it, you might have blazing fast speeds from ISP A (in Seattle) to ISP B (in New York, owned by the same parent company, perhaps), but horrendously slow speeds from ISP A to ISP C (also in Seattle, but given lower priority for competing).

There are many other ways ISPs could game the system if they didn't have to be neutral about packets: sending mail to certain servers might cost more, or hitting certain websites, or using certain protocols.

Getting rid of net neutrality suddenly opens up all new possibilities for the ISPs to work on segmenting their users. At this point, they segment purely on bandwidth (10Mbit down costs more than 1Mbit down), which makes sense for upkeep. If they can start inspecting packets, they can segment based on the type of access you need (charge more if you're receiving HTTP GET/POST messages, instead of just sending them, for example). Pure capitalism would be alright with this -- segmentation is how most businesses work, and if the Internet were a product worth something by itself, that would be great. However, the Internet doesn't work like most businesses.

Your example about toll roads highlights the difference: we consider the Internet to be a public good. Roads are free (or charge tolls solely based on the amount of use) because they're a public good. Charging more based on where you need to go on a certain road (getting to the mall costs less than getting to your friend's house, even though you take the same route) seems crazy when you think that you paid for the road to begin with (taxes, or the toll money itself). We want the roads/Internet to be as cheap as possible for all users because the economy is driven by destinations, not travel. Making travel as cheap as possible helps the majority of businesses. Same with the Internet.

Thus, net neutrality is good for two reasons: cost stays down and benefit stays up. Removing net neutrality would reverse both of these.

(TLDR: The Internet is only worthwhile if there are people on it. Dropping neutrality makes it harder for people to communicate, lowering the benefit for everybody.)

• "I'm working on getting some hardware out to key community folks, and I'd like to offer you a review PC."

• "Also, you are welcome to send the machine back to us after you are done playing with it, or you can give it away on your site, or you can keep it."

But ultimately, MS's tactic has worked. Whether or not many bloggers accept and/or write about these laptops, we're all talking about MS and Vista right here. As a form of advertising, those laptops were a pretty good investment!

Elaborate? Big committement? Really?

I've been using Allen's system for a while now. I've modified it to fit my needs. There is no large committment required. I have a milk crate sitting next to my desk. It's my InBox. Everything physical that needs processing goes into it. I have four packing boxes from Staples and a big pack of hanging files.

I try to clear out my InBox everyday but at least every other day. Everything is filed, junked, or tracked.

Tasks are tracked in a spreadsheet. I use Google Spreadsheets and the Joel Spolsky method.

It took me about 10 minutes to walk across the street to Staples. It took me about 5 minutes to dump everything in the milk crate and setup the spreadsheet.

Ever consider that you may be procrastinating?

To think that the targetted consumer of this is a "switch from Outlook Express" user is extremely short sighted and arrogant.

Thunderbird has all the tools needed (through extensions) to be the power mailer for the power user.

But that is not its intention. It was, like Firefox, intended to be an end-user tool, and you make end user tools by enforcing interface *simplicity*. It is meant to be good enough for OEMs like Dell and HP to finally stop bundling the garbage that is OE and provide a better experience. For the average user, a "better experience" means *fewer* configuration dialogs and settings, not more choices. People HATE choices. Drive down a busy highway sometime and watch closely: you'll see the worst backups every time someone needs to make a choice - it's not the incoming or outgoing traffic that screws people up and makes them slow down: its the choice. People simply don't want to have to make decisions, nor do they want to have to fill in dialogs that in turn give them choices to have to make later: the thing should "just know".

Go read http://joelonsoftware.com/ for a while.

What do you mean? Did you miss the awesome part where when you mouse over the links* in the top row they go from being nice white-on-black text to light-blue-on-white with a drop shadow in a box with no padding? *gag*

Proving once again that it's better to have talent and bad tools than good tools but no talent.

* note: the first bit of text, which looks EXACTLY like the other bits of text in that row, is not a link, just like the e*trade example here. Actually, whichever page you're on gets the this-isn't-a-link treatment, but nothing else about the text indicates that it's the page you're on. So I guess to figure out which page you're on, just mouse over all the links and see which one doesn't change. Oh, wait, I see--there's also the little pixel-y graphic that moves. I see. But the little graphic just looks like a fancy bullet on the first page since it's all the way on the left. Wait, let me check Firefox (I'm using Safari) to make sure I'm not missing anything. [checks] Nope, the only difference is Firefox doesn't show the drop shadow. Nice.

Which is better design:
- having distinct things which look distinct when you first see them--tabs, for example**
- having distinct things with small visual distinctions which only become apparent when you do a few different things and look closely for differences, like those spot-the-six-differences-in-these-two-pictures things in the Sunday comics.

** note: for as good as Apple is, I'm super-pissed that they ditched tabs in favor of blue buttons starting in OS X 10.3. Tabs are WAY easier to differentiate, especially when there's only 2 choices. And they don't almost disappear when the tabbed-item-in-question isn't the foreground app.

removing features from your roadmap and shipping betas isn't how you "complete" a piece of software

To be honest, I've never known any software to become complete.

The reasons for paring down a release are many, varied, often controversial and equally often necessary. Releasing without "everything" means that customers who are waiting for the things that are done can get them. It also means that there is a new round of revenue that can be realized.

To quote Joel On Software:

nothing we have ever done at Fog Creek has increased our revenue more than releasing a new version with more features

To be able to release a version with new features means not "completing" the software for the current release.

There is a grey area between making good software engineering (and business) decisions vs. purposely manipulating the market in order to yield extract extra revenue. In the first case, you expect to keep a solid and viable company alive, keeping most customers happy while absorbing the criticism of those you have not been able to service completely with the current release. In the latter case, hopefully market forces (and human nature) will bring the rogue software vendor inline or put them out of business (unless they happen to have billions in the bank and a name that no one gets fired for purchasing products of...).

OpenOffice in my opinion is simply a clone of MS Office suite. Instead of trying to mimic MS' product. It should innovate. Try things. Risk things. Experiment. Do something crazy. Remove all features that isn't useful or doesn't add to the experience and add features that rock. Don't let feature creep come in. Don't worry if the competitors got this many features. Until OpenOffice finally have a reason for me to use it(Such as killer UI or killer implementations of features), I will continue to use other word proccessor.

I agree about the need for innovation. I just recently started using Office 2007 and, though I thought I wouldn't like it at first, the new UI really is a breath of fresh air. But as far as feature creep is concerned, I think you're looking at the wrong problem. Joel Spolsky maybe said it best...

A lot of software developers are seduced by the old '80/20' rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies. Unfortunately, it's never the same 20%.

Wasn't Joel just complaining about how complex Vista's power button is, because it gives you too many choices?

I don't get this guy.

These dudes are stuck back in the day where you're product had to be marketable to everyone. Different strokes people.

This is what Spolsky himself, not long ago, argued here: http://www.joelonsoftware.com/items/2006/11/21.htm l Now, the Vista shutdown menu is a very amusing example. So, perhaps the finer point is that complexity can be good, but redundancy isn't(?) Or should we accommodate every single method in which a user might possibly try to execute a task?

In this article, Joel on software claims that simplicity is overrated, that users want more features, and the single thing his company does to drive more sales is to release a new version of an existing product with more features. What's notable is that a week earlier, he wrote this well-circulated post lambasting Microsoft for having too much choice in the shutdown menu in Vista, and advocated for a simple, one-button shutdown solution.

In this article, Joel on software claims that simplicity is overrated, that users want more features, and the single thing his company does to drive more sales is to release a new version of an existing product with more features. What's notable is that a week earlier, he wrote this well-circulated post lambasting Microsoft for having too much choice in the shutdown menu in Vista, and advocated for a simple, one-button shutdown solution.

I suggest gaining some experience in free open-source software development. Goto high-priority projects assisted by GNU, or goto Savannah. Get an IRC account at FreeNode and meet other hackers.

Then, I suggest investing about $400 per year on a Safari subscription. This is a site where you can legally read O'Reilly IT e-books. It will come handy if you have a PDA, like HTC Universal with a 3G broadband connection for reading Safari while you commute (note: Here in Europe we commute by taking a taxi, riding a bus, or using a train, if you are in North America most probably you won't be able to use a PDA during commuting as you ought to drive, unless you are in New York City where mass transit is similar to Europe).

Finally, focus on the fundamentals. What's a queue and how it differs from an array? What is a relation? What is a finite state machine? What is a Turing machine, and what is a hypercube?

Armed with the fundamentals, assisted by a good e-books site like Safari, and practising on open-source projects, you will become a hacker in no time.

A caveat: Try to understand what kind of company your employer is. Do they pass the Joel Test? Do they have good Management and do they use Software Engineering methodologies, and if not why not? Many companies are just hiring a bunch of underpaid engineers, put them in a noisy environment, and tell them to write code all day. This is a recipe for bugs! Good companies act on bugs proactively, via test-driven development, etc.

Another important thing you must achieve is the state of flow, coding in the zone, or hack-mode. It is, in fact, more important to be able to achieve flow easily rather than have advanced degrees in computers.

No, this problem has already been solved... the only remaining one is "b'bye".

Pretty simple ;-)

I thought that might be the idea.

My only problem with that is I've always taken exceptions as something to be used when there is a error condition of some sort. Returning null from a function does not necessary imply that there is an error.

For example if you are querying for the existance of something and it doesn't exist, throwing an exception seems like a bad idea. It seems to me if you take the not null returns to its logical conclusion then you end up overusing exceptions.

There are also some people who just flat out dislike exceptions. I'm not one of them, but the view does exist.

Yes, I think 20% time is pivotal here. I don't think the articles hypothesis is going to be a problem. 6 months ago I was thinking of forming my own company. Yesterday I was talking to an interview candidate about why he should come work for us instead of setting up his own business. The simplest thing was to tell the truth, to tell what I thought in his boots 6 months ago, so that's what I did.

Essentially, if you are thinking of forming your own company to write software, you need to weigh up the trade. If you work for Google then it's quite likely - assuming your idea is not totally stupid - you can work on it in 20% time. Not just for web apps either, but for pretty much the whole spectrum of software development. If you do this, you don't own your idea and you can't work on it full time. BUT you trade those downsides against the upsides:

• You have access to the Google infrastructure and can build your program upon it. For me, this was a huge thing, because if my idea eventually takes off I want it to scale and I want it to have exposure to a large market. Solving scalability is not an easy thing. Look at how many companies suffered crippling scalability issues and either tanked or nearly tanked (Friendster springs to mind). I already knew Googles tech was impressive before I came here, because we have techtalks about it on Google Video and have published papers etc, but there are plenty of amazing technological nuggets we don't talk about. Time spent re-solving these (superhard) problems is time spent not implementing my idea.
• You have the advantage of formal process and peer review from people who know what they're doing. Some people say Google is full of smart people. I think "smart" is too vague a word. Jeff Dean is smart, I'm not all that smart. I couldn't have invented MapReduce, and I'll probably not invent the best way to implement my idea. But if I want Jeffs thoughts, all I have to do is email him. Or Rob Pikes. Or Ken Thompsons. Or Vint Cerfs. That combining the brainpower of the organisation is smart and it's only possible when you have a very open internal culture like Google has.
• There are, in fact, financial rewards available to people who make a significant contribution to the company (say by launching a wildly succesful new product). As big as founding your own company? Depends .... you won't be the next Bill Gates, but most startups don't make their founders billionaires anyway.
• You personally shoulder much less of the risk.

From a rational perspective, for me it made sense to join the big G and work at my idea in my 20% time and spare time. That's because for this specific project I want to see it be built and deployed well more badly than I want to get rich (because I feel it will be strongly needed in future). Maybe if I was writing some AJAX wiki web 3 mashup or whatever I'd care more about getting rich and it'd make more sense to go it alone. Depends on your goals.

Anyway, it's sort of become fashionable lately to say Google isn't innovative anymore, or something like that, but I'm not seeing that on the inside. I'm seeing lots of innovation. Not all of it turns into a successful product of course, but that's true of business in general no matter what you do.

So. I say to you - if you are thinking of writing the next amazing killer app on your own, seriously, consider doing it with us. If you don't trust me on this, go read Joel Spolskis opinion on the same thing. Setting up a business is a lot of work and there are many ways to get it wrong. But whatever you do, make sure you enjoy doing it. That's the most important thing, I think.

They already did that. Part of the reason why Netscape lost.

Assembly is like a sharp scalpel. Yes you can hurt yourself if you're unskilled, inexperienced or sloppy.
C++ is like those scissors with rounded ends for kids. Totally inefficent but safe for beginners.


Now, I agree the 'inneficient' comparison isn't valid, but the rest is. C# (and to a lesser extent, Java) is not so much about being easier as they are about being more productive to use. Now, I agree with Joel that you do need programmers who can happily code in C++, but there's no reason why you should neccesarily use it for your project, especially if it results in the project being completed more quickly, or with less people.

Exactly.

C, C++, Java and god forbid VB should be prohibited by law for university courses and any person teaching them during the first 2 semesters in CS should be prosecuted for child abuse. Pascal (even without the object oriented extensions) remains the best language for teaching the first years in CS. Once students are past their data structures course and know how to deal with linked lists, pointers, objects hashes and the like you can switch to C, C++ or Java with minimal fuss. Before that its outright criminal. In fact the total amount of hours spent till the point when the students can produce something that will pay their daily bread will most likely end up being less than the required when teaching directly in C/C++.

There was a very good article on the subject by Joel called The perils of Java schools and I tend to agree with it 100%. In fact I will extend its reasoning further to C and C++. Probably the most important part of teaching a data structure course is to teach it in a language that has a clear syntax and "one way to get it right" for pointers, linked lists and the like. C and C++ are insufficiently clear and unambiguous. Java simply does not allow you half of the things you need to do in that course.

Many people advocate for the usage of Java and especially VB from the perspective of "look how fast can I learn to program in these". That is irrelevant as far as university courses are concerned. What is relevant is will the student learn to produce literate, commercially viable code or not. If he has been subjected to VB - never, Java or C++ - not bloody likely, C - it may work but it will be anything but readable for the first 10 years of his career.

Disclaimer: I've yet to work with Perforce, having not yet graduated from CVS, but at least I'm not using VSS.

I think the way that Dave Winer characterises Microsoft is accurate; they're a company which only becomes interested in markets once others have proved them viable. After all, that's the safe bet. Microsoft are a business first and foremost, not an innovator. A lot of technology companies are innovators first, businesses second, and a lot of this type of company go out of business when they realise they didn't actually have any means of making money from their innovation. From this perspective it is of course sensible to let others make your mistakes for you, then enter the market once it's proven. Microsoft have done this time and time again; with Apple, IBM, Sega (Dreamcast, anyone?), Sendo and probably numerous others I've not heard about.

I quote Paul Graham (who created Yahoo Stores, cited by Joel Spolsky):

"If you want to write desktop software now you do it on Microsoft's terms, calling their APIs and working around their buggy OS. And if you manage to write something that takes off, you may find that you were merely doing market research for Microsoft."

But there is innovation, still. Microsoft has begun to give a lot more free reign to its web development teams. There are interesting projects taking off there, and they might well become useful tools. But as far as business goes, this is practically just research. They might turn up useful tools in the future which can be sold, but then again they might not.

The biggest problem Microsoft suffers from nowadays is that where previously they allowed others to do their market research for them, nowadays they seem to assume that they have a right to any market dominated by any company vaguely related to technology. This is a serious mistake. Microsoft can't beat Google by doing the tools Google does better than them, because Microsoft isn't an advertising company. Microsoft can't beat Apple at the iPod+iTunes game, because they don't understand what it is consumers want. They fundamentally don't grok either what it is that makes these things successful or their reason for existing in the first place.

Scoble can talk about the little innovations that Microsoft makes (even though I think pretty much every example he cites is desperately flawed), but even in these cases they're usually incremental improvement. Microsoft didn't bring the mouse to the desktop as a revolutionary input device; they merely refined it. They didn't 'make' Halo; they bought the company that did and got them to make their game an Xbox exclusive (to begin with, at least).

I honestly believe Microsoft would be set for a fall (in the way that all those clueless journos predicted the 'death' of Apple throughout the 90s) if it wasn't for the insanely large pile of cash they sit on. It'll take many years of stupidity to fritter that away. In the meantime they'll keep putting out crappy operating systems based on Windows NT with yet more "me too!" chrome based on what Mac OS X looked like 3 years previously but that will begrudgingly be accepted by the market who are already crack addicts to Win32; they'll keep on attempting to win the handheld device / videogame system / portable music player markets; keep on trying to compete with Google and keep coming up scratching their heads. Eventually a wind change will occur once the likes of Ballmer has been superceded by a new generation of people who were inspired by Apple, Google, Yahoo et al and want to do more. People who recognise that there is sometimes a correlation between business success and innovation, and that being "me too!" doesn't always hack it. That's when Microsoft will finally return to being an innovator.

http://joelonsoftware.com/items/2006/11/24.html

• your team can't say yes to nearly all of the points on the Joel test
• if you spend more time fighting fires than working on your project
• if you couldn't honestly say your team is better than average
• if your managment is more focused on getting it out the door than getting it right

It is known that incentive plans do not work with respect to creativity, invention, and innovation.
http://www.joelonsoftware.com/articles/fog00000000 70.html

It's not particularly your fault the problem exists, it's the whole large business system. Being the go-between between devs and upper management isn't nessecarily a BAD thing ("I have PEOPLE skills!!!!"), but the fact that you need to go to meetings ad infinitum is a problem. There needs to be more organization on the higher-ups so that the dev team (represented by you) can focus on the developing and not the "business" end of things. See: Joel on Software's take on it. Basically, your job is important, but Microsoft needs to focus on the level above yours.

Joel likes to stroke his ego and promote his company by claiming he always hires the best people.

In France, the government found that some surgeons were able to acheive 12x as many procedures as others at the same quality level[1]. This is the basis of the NHS reforms in the UK. i.e. Provide a system to encourage the 12x surgeons/other-staff to succeed.

So one way to increase productivity is to identify those 12x people, and find less demanding work for the <12ers. This is done by hocus-pocus Management Consultant type processes at the moment. Correcting this would lead to improved efficiency overall.

How much improvement? Dunno, I'm not a 12x person either!

----
[1] I read this in The Economist. Sorry, they require registration+£££ to read the article.

The Mozilla codebase is a mess. However, it is getting better. Did you look at it at all when Netscape first released the source? It was absolutely terrible. The Mozilla guys have done a good job at cleaning it over the years, but it's still a mess. They really should have just started from scratch and used the old codebase as a reference.

Hold on a minute! They did do that. They rewrote the whole damn thing starting on October 1998, a mere seven months after the initial release of the source code. One year later, mozilla shipped nothing, and JWZ resigned citing lack of progress. In 2000 -- two years after the rewrite started -- mozilla released the new layout engine, Gecko. Jaws all around had to be picked up off the floor. It was a horribly buggy. (The most obvious bug to me was the fact that scrolling to the bottom of a page, then back up, then back down a second time, caused TWO copies of the page to appear in the window. Repeat N times, and you got N copies. I discovered that bug within the first five minutes of use.) FOUR years after the rewrite, Mozilla released version 1.0. Now four years after 1.0, 8 years after the rewrite that is widely considered the biggest blunder of mozilla's history. A blunder that is made all the worse since it's outcome was immediately forseeable.

Now you're not seriously proposing the repeat their old mistakes are you?

From an outsiders perspective I'd say Joel Spolsky of Joel on Software ticks all of the boxes, e.g. "The Development Abstraction Layer". It's such a shame that they can't clone him on demand and ship him worldwide in 48 hours :(

From an outsiders perspective I'd say Joel Spolsky of Joel on Software ticks all of the boxes, e.g. "The Development Abstraction Layer". It's such a shame that they can't clone him on demand and ship him worldwide in 48 hours :(

> You (singular) dragged MS into this discussion without reason

You (singular) keep talking about how popular a project is as though that matters.

When people say that Microsoft must create quality software because so many people use it, you (plural, i.e. the open source community) immediately perceive and loudly repeat that popularity is not the same thing as quality.

You cannot have this both ways. If popularity is not quality, and it's not, then you can't use the popularity of a product as evidence of its quality.

And that's my reason.

> Calling me names and throwing around insults about
> it doesn't make you (singular) look any better.

What names and what insults?

> I was not comparing just to FOSS projects, I was
> comparing to closed source software as well.

It doesn't matter. If your one project is a phenomenal success, it is still only one project. It does not change the percentage of projects that fail, and it doesn't have much impact on the average length of successful projects.

> I distinctly remember you calling my community a
> bunch of monkeys

No, I called the *flaw* in the community the "infinite monkeys fallacy". Joel Spolsky explained it a little differently:

"The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce. Five Antonio Salieris won't produce Mozart's Requiem. Ever. Not if they work for 100 years."

You can read that whole article at http://www.joelonsoftware.com/articles/HighNotes.h tml if you're interested. It's not about open source; it's about building high-quality software. And in my experience, the open source community would do well to occasionally shut up about open source and spend some time learning about high-quality software. You know, maybe 20% of the time, or something like that.

I call this problem - recruiting a lot of mediocre programmers instead of a few good ones - the "infinite monkeys fallacy", because it's the same stupid idea that leads people to say "if an infinite number of monkeys typed on an infinite number of typewriters for an infinite amount of time, they would eventually produce the works of Shakespeare".

In other words, IT'S A FUCKING METAPHOR. Nobody called you a monkey. Grow up.

> So why not help out these "failed" projects with your
> obviously valuable feedback, instead of spending all
> your time complaining about it on Slashdot?

I'm a professional software project manager. Any open source project that wants my services is more than welcome to pay for them just like everyone else, and I'll put every bit as much time and effort into it as I would for a commercial client.