Slashdot Mirror

One of the common anti-patterns is over-relying on tools and frameworks instead of inventing new programming models.

Actually, he missed the anti-pattern. It's really: One of the common anti-patterns is over-relying on tools and frameworks and programming paradigms and processes instead of improving the skills and knowledge of the people doing the programming.

I've been programming for a long time too, and I don't think that new programming models do all that much for productivity compared to finding good people or investing in improving the people you have. The recent Joel on Software article discusses this at length. This is one of the big reasons I'm so interested in agile methods and principles.

I read my mails in a AJAX based interface by Google called Gmail. It's way faster than my previous mail applications in several ways. Also it's the one application I use the most.

I would recommend reading "How Microsoft lost the API war" by Joal Spolsky: http://www.joelonsoftware.com/articles/APIWar.html

He "plugs his products" with a little line that automatically gets included to the bottom of each page. He is a very smart guy with a profitable (the only thing that matters) small software company. He worked at MS in the early 90s (working on VB for Excel), then at Juno when they were a free ISP, then for his own little company, so he has a wide range of experience--everything from the 800-lb gorilla to a 2-man shop. Plus he is an excellent writer and is really into making good user interfaces. Of course, "good writing" is subjective, so visit the archive and judge for yourself.

Here's a random sample, about why it's rarely a good idea to toss all your old code and rewrite from scratch:

"The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. Au contraire, baby!... it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes.

"One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.

"Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters. When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work."

Excellent point, symbolic. That's why the best interviewers don't necessarily just ask "How many years of C++ experience do you have?". They give you brain-twister-type problems that show, in general, your intelligence and enthusiasm. This is way more important than the number of years you've spent typing at the keyboard.

Joel actually talks about this in another article (link) although he still insists on specific knowledge of programming syntax. I suppose that's just his way of minimizing the startup cost of a new hire. Pity, you'll miss out on some good people that way.

The bext boss I ever had once said to me, "I'd rather hire a smart person and teach them to code, then teach a coder to be smart." (paraphrase). This is what you are saying in your post, and I agree completely. But my mindset does not get you a fast, hit-the-ground-running developer.

How can Joel hire good programmers if he insists on using Hungarian Notation instead of a choosing a decent language?

Actually, in another one of his articles, he mentions how he recommends/enforces a 40hr weekin his company due to diminishing returns from overtime.

What about SimCity.

Microsoft went through great pains to get SimCity to work, but ignored Lotus 123. I don't think so.

Here's what Joel wrote-

The Windows testing team is huge and one of their most important responsibilities is guaranteeing that everyone can safely upgrade their operating system, no matter what applications they have installed, and those applications will continue to run, even if those applications do bad things or use undocumented functions or rely on buggy behavior that happens to be buggy in Windows n but is no longer buggy in Windows n+1.

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

I dont this behavior just started happening in the Windows days.

This sort of change will only add non-value added time to releasing warnings while offering virtually no error proofing. Something like a drop down with the full text of the warning would be a slightly better solution.

Well, the question is how big the gap actually is, irrespective of who has a PhD and who doesn't. Here's one recent take on it -- Hitting the High Notes appearing on Joel on Software.

Having done quite a bit of programming language training for large companies, I've concluded there are some really great developers out there mixed with a lot of mediocre talent. Interestingly, some of the best small groups of programmers I've encountered work for the federal and state governments, defying the conventional wisdom.

Well, the question is how big the gap actually is, irrespective of who has a PhD and who doesn't. Here's one recent take on it -- Hitting the High Notes appearing on Joel on Software.

Having done quite a bit of programming language training for large companies, I've concluded there are some really great developers out there mixed with a lot of mediocre talent. Interestingly, some of the best small groups of programmers I've encountered work for the federal and state governments, defying the conventional wisdom.

Hehe - reminds me of this article about the "small" cultural differences between Unix users and Windows users. And I quote: "the Windows culture understands that end users don't like reading". Look down my nose on these people? Why yes, I do, as a matter of fact.

What the Open source community doesn't have are Art Directors. We have very capable coders, some good testing courtesy of Sun, but no Johnathan Ive. For reasons explained better elsewhere, without people like him it's very hard to transcend the "cool tech gizmo" and achieve the "great usable interface". Beagle might be a great tool, but if the usable interface is not there (and it might be, I don't know) it won't succeed.

The second point I will make, the most repeated one, is that Apple and MS do things for a reason, and spend a lot of money on usability tests. Sometimes it pays off to wander into the unknown, other times it pays off to offer a new user exactly what he's expecting.

The third point I'll make has also been stated by others: KDE and GNOME aren't the whole thing on Open Source Desktops. Multiple alternatives are there, exploring many things. Check enlightenment (yes, they could do a release before hell froze over), check Croquet before thinking "open source doesn't innovate".

Look at the scenario from the customer's standpoint. You bought programs X, Y and Z. You then upgraded to Windows XP. Your computer now crashes randomly, and program Z doesn't work at all. You're going to tell your friends, "Don't upgrade to Windows XP. It crashes randomly, and it's not compatible with program Z." Are you going to debug your system to determine that program X is causing the crashes, and that program Z doesn't work because it is using undocumented window messages? Of course not. You're going to return the Windows XP box for a refund. (You bought programs X, Y, and Z some months ago. The 30-day return policy no longer applies to them. The only thing you can return is Windows XP.)

Yes, Solaris x86 and Be don't worry about this. But AFAIK Solaris has no marketshare among non-geeks, and Be has no market whatsoever.

Japan had a population roughly equal to half that of the US. In order for Japan to surpass the US, the average Japanese citizen would have to be twice as efficient as the average US citizen.

Incorrect.
To base efficiency of a collection upon individual efficicency is an improper and illogical action. There are many cultural and societal differences that change the equation. For example, assume for the moment the Japanese had no worries about being "over mechanized" -- they would/could freely use robots for many tasks that unions would lobby against here.

That one assumption entirely destroys your per-capita efficiency model. Unlikely? Hardly, as this is indeed what happeneed in the automotive world. Your argument entirely avoids the non-person multipliers technology *can* provide.

China has a population roughly equal to four times that of the US. In order for China to surpass the US, the average Chinese citizen would have to be one quarter as efficient as the average US citizen.

again: Incorrect
Individual efficiency can, and often is, nullified through organizational inefficiencies. The ability to organize a population the size of China and harness the individual inefficiencies is not currently permitted to exist on this planet. The mentality and goverment of the Chinese will not permit it there either.

And finally, sciences are not like cars or televisions, they are like software. As Joel Says, no number of mediocre/average designers will produce the big things/hits. Works the same in science. A dozen B and C students won't produce the level of new science and innovation that the cream of the crop will. Thus, it doesn't matter how many Chinese citizens are as "efficient" as Americans. In science, what will matter is who is better at making large leaps forward.

This is precisely why the attempt over the years of the NEA to abolish accellerated ("gifted") student learning and produce mere cogs is the single greatest threat to American intellectual and scientific advancement.

No, it is not the "dumbing down" of the general populace, that is a minor item by comparison. It is the dumbing down of the extremely bright and gifted people at all ages.

The notion that we need "liberal arts" where people "become better through studying the arts" is one that needs banished to the annals of unfortunate history. We need people who are extremely good at what they do. We need programmers who are truly amazing to drive things forward. We need scientists who have a genuine love and in depth almost intuitive grasp of the world around them.

This is a critical failing in the Chinese system. It is exceptionally good at producing mediocrity. It was actually designed to do so (so too was the US system when it was imported). We need to realize there is no shame in not being the brightest. We need to stop clinging to a mistaken notion that if Johnny does better than Joey, Joey is somehow less than he was.

When we do that, we will be able to stop shackling our geniuses and truly gifted with the chains of forced mediocrity. Just as Google is doign in regards to Microsoft. Sure, MS has many more programmers, some quite bright. But they are shackled in the bounds of One Microsoft Way.

At Google, they instead focussed on getting *the best* they could. Those who have an ability to go beyond. And they are producing better software, faster. Go figure.

If the US can shed the bonds of fear, it doesn't matter if China outnumbers us 100 to one if it can't produce the level of genius we can.

Looking at history, nearly all major advancements in science and technology are the work of one or a handful of disparate people, not the work of comittees of medicority. There is no reason to expect any different today.

And no, the numbers game is irrelevant. We've shown you can stifle genius. The countries in which genious is not only allowed to flourish but is incourage

Myself, I'm not so hot on everything being a web app. http://www.joelonsoftware.com/articles/APIWar.html

People who are Smart but don't Get Things Done often have PhDs and work in big companies where nobody listens to them because they are completely impractical. They would rather mull over something academic about a problem rather than ship on time. These kind of people can be identified because they love to point out the theoretical similarity between two widely divergent concepts. For example, they will say "Spreadsheets are really just a special case of programming language" and then go off for a week and write a thrilling, brilliant white paper about the theoretical computational linguistic attributes of a spreadsheet as a programming language. Smart, but not useful.

How much should I charge for my software? http://www.joelonsoftware.com/articles/CamelsandRu bberDuckies.html

You've just released your latest photo-organizing software. Through some mechanism which will be left as an exercise to the reader, you've managed to actually let people know about it. Maybe you have a popular blog or something. Maybe Walt Mossberg wrote a rave review in the Wall Street Journal.

One of the biggest questions you're going to be asking now is, "How much should I charge for my software?" When you ask the experts they don't seem to know. Pricing is a deep, dark mystery, they tell you. The biggest mistake software companies make is charging too little, so they don't get enough income, and they have to go out of business. An even bigger mistake, yes, even bigger than the biggest mistake, is ...

And that is why I'm worth hiring.

I'm sure you are worth hiring, but for what you would probably demand in salary with a 4 year CS degree and 4 years industry experience, I doubt you'd be worth hiring to write that VB app you were talking about. No offense, but this to me, is a common misconseption. "I've been programming for 4 years and can learn VB from a book in 2 days," while I have no doubt that you could, in no way compares to "I've been writing apps in VB for four years."

With the abundance of 4 year CS degrees floating around, and the abundance of those with CS degrees that can have programmed in VB for 4 years, do you really think that you are worth hiring for that position?

Sure, you know all the theory behind a visual basic app, and hey, you've got your book, and that's great. But what you don't know, is all of the things that you learn in the trenches (as you are an experienced coder I will assume you know exactly what I am talking about in this regard).

Joel has an article that touches on this very issue, in the article he states: "Leaky abstractions mean that we live with a hockey stick learning curve: you can learn 90% of what you use day by day with a week of learning. But the other 10% might take you a couple of years catching up. That's where the really experienced programmers will shine over the people who say "whatever you want me to do, I can just pick up the book and learn how to do it." If you're building a team, it's OK to have a lot of less experienced programmers cranking out big blocks of code using the abstract tools, but the team is not going to work if you don't have some really experienced members to do the really hard stuff."

Sorry for the rant, but I'm tired of hearing disgrunteled programmers that I know complaining about not getting that "Java" job that they applied for when they had 5 years of experience programming in VB. "Just give me a book! I can learn it in a week!" They say...

It's just not the same thing. And I wish people would stop believing that it was.

Here is the like to the article that I refer to:
http://www.joelonsoftware.com/articles/LordPalmers ton.html

This was the best link I could find quickly.

I'll quote from a discussion that was linked to from a recent post on /.

The Unix programmer will create a command-line or text-driven core and occasionally, as an afterthought, build a GUI which drives that core. This way the main operations of the application will be available to other programmers who can invoke the program on the command line and read the results as text. The Windows programmer will tend to start with a GUI, and occasionally, as an afterthought, add a scripting language which can automate the operation of the GUI interface.

Oh, I agree, there's lots and lots and lots wrong with Windows.

I guess I was trying to make the point that too often, when people say "Linux needs to do so-and-so to attract Windows Users", the reply is "Linux does do so-and-so if you technobabble technobabble" which does not help attract Windows users

Joel Spolskey's article, refered to today on slashdot, catches it perfectly as a cultural difference - Unix is written for programmers, and Windows for users. Programmers like having a choice of twelve different desktop environments because they like to find the one closest to what they need. Windows users want it to work the same as it always has. Neither side is right, they're just different. Article is at http://www.joelonsoftware.com/articles/Biculturali sm.html

1) While most programs today should probably not be written in C, I think it's still an important language to learn and understand as a beginner programmer. Most applications today use C at some level. If you understand it, you get a chance to understand how the application/framework/library you are using works which make you able to use it better. See Joel Spolski's "Back to Basics" for more on this.

3) More on this in Robert L. Read's How to be a Programmer.

"Netscape lost not because IE went free, but because Netscape 4 was such a bloat POS that it was agonizing to use it compared to IE 4."

Netscape lost because they "practically started over from scratch."

Check out Joel's take on it here: http://www.joelonsoftware.com/articles/fog00000000 69.html

...but all software. PHBs have no clue how long it takes to make software correctly. If the screen shots look good, then the product is finished, right Pareto?

They look at the "testing" tasks in the project plan with dismay at the amount of time allocated. Figuring a simple solution to a complex problem is the best approach, they say, "just make the developers test it," which is a colossal mistake that---in a just world---would get a PHB fired, but in the real one, they take it out.

The Itanium is the hardware equivalent of this Joel on Software parable, and a close relative to IBM's biggest blunder.

AMD64/EM64T provides a solid upgrade path from x86, whereas the horrible x86 perfomance of the Itanium (first in hardware, then in software) makes it a clean break. In the real world, where we depend on cheap, commodity x86 server hardware and applications, a clean break to a more expensive, incompatible, unproven platform was just not attractive to customers.

And don't discount the AMD factor. Even Intel-only shops benefit from the price and performance pressure any measure of competition in the x86 market provides. Moving to an Intel-only platform would remove the last barrier to permanent hardware lock-in.

Joel (from http://www.joelonsoftware.com/ ) describes a similar interview strategy.

He asks a candidate to design a house. They usually get several minutes in when he interrupts them and tells them it's a house for a family of blind giraffes.

The object lesson is that you're supposed to ask for more requirements and not just start going with the barest idea of what you're doing. It's just a way for interviewers to make themselves feel smart, IMO. I think they figure that if you don't leave on the spot then you'll be able to put up with the kind of assholes you'll be working with every day there.

Actually, most companies don't care! (...) the BSD and GPL licenses are functionally equivalent.
They're functionally equivalent for now, but this is because you can develop code in-house using the GPL for your competitive advantage if you don't release them (GPL FAQ here).This is poised for change in version 3.0.
The reality of the GPL is that it is being widely deployed by companies dual-licensing. That is, they release GPLed code, often with shoddy documentation, and propose to you the alternative of opting for a proprietary licensing scheme.
My understanding of what this scheme means is that, in the end, you end up developing code for free for an enterprise that will license that code under a proprietary license. Exactly how these companies will disentangle GPL code contributions made by others and sell you a proprietary license is something I don't quite understand. Maybe there's a legal, untested, loophole. There's gotta be something, since so many software houses are doing it. Maybe the loophole is the above item of the FAQ above: the company apropriates GPL code and develops it in-house, but for a contractor.
Under the puported forthcoming changes in v 3.0, will you not be able to develop in-house code without giving back. This will push people who are clients of those software houses to two choices: either choose a pure proprietary license, no longer a twin tributary and heir of the GPL code, or the truly viral v. 3.0. You are back to square 1. But if you have the option of a truly viral license, why would you choose the proprietary one? This means both loose.
All this means the GPL is a confusing model. It lends itself to dual-licensing, something the BSD licese aborts by creation. There are no legal loopholes in the BSDL.

However, for big corporations, the reasoning is completely different. The GPL is a big thing for them, but not because of dual-licensing. By commoditizing the complements fo their products (i.e., what they really sell you is hardware , but it runs on Linux - a formulation first written by Joel Spolsky on the now-famous Strategy Letter V), they get garantees that the competitor won't simply incorporate changes. Also, it's a great scheme because it cuts down the cost of development, by getting contributions from the community. Please notice that, whenever, e,g, IBM sells software, it's under a proprietary license (e.g., WebSphere). Either that, or they sell per-seat licenses (e.g. RedHat).
For small independent software vendors, it takes away any competitive advantage you might otherwise aggregate to a client. This is a very important factor, because the BSD allows you to contribute and benefit from a free code base, and still use your software talent to your benefit. There are some real-world scenarios where the Human Factor may actually work against you (I'll come back to that bellow).

So you see, there's absolutely nothing to do with freedom when companies selling per-seat licenses and/or hardware defend the GPL. Don't believe their PR department, please.
Why do companies take BSD code and often don't give anything back. This has more to do with corporate culture. Linux is all about PR and evangelizing. The BSD people always were hackers, before everything else. They only cared about coding, maybe that was their mistake.
And finally, the last aspect I see regarding the GPL is the human factor. A very real world political one, but that's not so evident in the USA, because there's a stronger business culture there. But in my country (Brazil) the government often is the biggest contractor. I've seen the Free Software community be maneuvered by a government

hhttp://endangeredit.xlan.org/story/2005/7/4/91825 /02357

and

http://discuss.joelonsoftware.com/default.asp?off. 9.155251.0

The thing is, at some point the value of the codebase is greater than the cost of giving up some of your rights in order to use it. When that happens then the GPL has a major, major advantage in that it creates a feedback loop.

This is laughable, but of course, it's been moderated up by /. knee-jerk meme replicators.

I don't think your "feedback loop" has any slight evidence of existing. In a recent economics paper here) "Harvard Business School professors Pankaj Ghemawat and Ramon Casadesus-Masanell (...) chose to explore the fundamental competitive dynamics question: Will OSS ever displace traditional software from its market leadership position? (...) Our main result is that in the absence of cost asymmetries and as long as Windows has a first-mover advantage (a larger installed base at time zero), Linux never displaces Windows of its leadership position."

Of course, you can say what you want, and if it pleases the Linux fanboys, you get modded up and your Karma explodes! Yay!

Also, read up on the commoditization of Linux and how it relates to IBM, HP, etc ("Smart companies try to commoditize their products' complements.") here

the GPL is a primary motivator for people who want to be able to share software but protect it from blood suckers who want to profit from their hard work without giving anything back.

Wrong. Please think. How is IBM not exploiting Linux developers? IBM makes money from hardware. Linux software is just a complement to IBM products. Same goes with HP and others, including Sun and OpenSolaris.

IBM and other corporations have, IMHO, more exploited than contributed. Millions in research to retrofit Linux in new Big Iron, that's all. Important? Yes. More to IBM than anyone else. And what you get? Linux on Big Iron. It's funny how what goes aroung comes around, isn't it?

Do you really think substantial research, the kind that DARPA did, or the kind Xerox Parc was doing in the 80s was done in IBM, HP, etc?

To quote: Once again: demand for a product increases when the price of its complements decreases. In general, a company's strategic interest is going to be to get the price of their complements as low as possible. Please read Joel Spolsky's famous Strategy Letter V http://www.joelonsoftware.com/articles/StrategyLet terV.html)

Regarding PHP, http://www.joelonsoftware.com/items/2003/10/10.htm l is instructive. Yes, I did confirm from the PHP website that things aren't too different now.

MySQL? The less said, the better.

-without using some crappy 'BabelFish' layer

Ask any government that supports multiple official languages (Canada, Switzerland, ...). You translate into the other language(s) using professional translators. Period. You can give them the most powerful automatic translation tools available, and multiple language dictionarys (e.g. English-French) but in the end you need a human professional translator to make translations worth reading.

-without having to write a complete localized version for each language.

You need to make the content management system (CMS) language aware, and you need to localize all your templates. Then you need to add a key to your article database for language, so the user can retrieve article 101 in either english or french. (think a long the lines of http://localhost/cms/display.php?article=101&lang= en ).

I know nothing about PHP programming, so I cannot comment on that, or MySQL (main gotcha I expect is datatype, UTF-8, iso8859-1, vs. windowspage1574). Two articles I found useful in general about internationalization are

UTF-8 and Unicode FAQ for Unix/Linux by Markus Kahn
How do I have to modify my software?
http://www.cl.cam.ac.uk/~mgk25/unicode.html#mod

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
http://www.joelonsoftware.com/articles/Unicode.htm l

No, the demise of online advertising won't kill free content. This is trivially obvious to prove by noting that there are lots and lots of sites out there that manage to provide free content without online advertising, using a variety of business models. Some put the content out there as a way to promote other businesses (http://joelonsoftware.com./ Some run text sponsorships that their readers apparently find tolerable (http://www.larkware.com./ Some are just labors of love partially funded by donations (http://www.crazymeds.com./ Ad blocking is going to kill off one particular obsolete business model. Big deal. There aren't a lot of buggy whip manufacturers left either. It's called progress. Get over yourself, change with the times, and stop whining.

Good points... a few thoughts:

Antivirus software, malware removers, spam-reducing solutions.... these are not designed around users?

Nope. No, they're not. They're palliatives to problems that we have inflicted upon users, not systems designed with users in mind. How many users understand what "malware" is -- even those that run Spybot? Is a malware remover something that a user would choose to run, if they weren't forced to by imminent threat from exploitation of broken systems by malicious parties?

(None of which is to belittle the heroic work that people have done on products like Spybot to help patch these holes. It's hugely important. But can we depend forever on heroes?)

A person who has any idea that a computer is a general purpose machine... Why should anyone be surprised when it does something new or malicious?

See, this is the problem. The average user does not see their computer as a general purpose Turing device -- they see it through the prism of whatever application they happen to be using at that moment. If they're reading e-mail, the computer is an e-mail terminal. If they're browsing the Web, it's a Web terminal. If they're in Word, it's a word processor.

You and I know that the computer is a general purpose machine, infinitely reprogrammable, but the average person does not think that way. They approach the computer through a series of metaphors ("desktop", "mail", "pages"), and the vast majority expect it to follow those metaphors as closely as possible. When it doesn't -- when the abstractions start leaking -- it creates opportunites for malicious parties to exploit the user's resulting confusion.

Which is exactly what has happened with e-mail -- in certain cases it can behave in a very un-mail-like way. This behavior is being exploited to confuse users into doing the wrong thing. You can try to educate people into not doing the wrong thing, but as long as the underlying metaphor is "mail" it will be very hard to make significant progress.

Why must the responsibility be placed solely on the software developer... ruling out one possible angle that you can't disprove and blaming a group of people who, by and large, strive to produce workable solutions is an insult to the good work many among us have done.

Don't look at it as placing blame (my apologies, I didn't mean to come across as blaming you for the problem) -- look at it as opportunity. Apple's recent success in taming UNIX, and Firefox's success in taming Mozilla, should be a lesson to developers everywhere that you can really make it big by reducing complexity, locking down unnecessary options, and streamlining the user experience.

IT Marketing learned it's history lesson, or will it forever doomed to repeat it?

Perhaps the lesson is that pumping millions into flimsy ideas is a bad idea. But that's always going to happen - just not in the sort of frenzy with which it happened in the dot-com era, and probably not too easily for anyone for a while. But someone was selling something correctly to get $195 million in VC funding for 265 employees all centered around sending little cats to people in hopes that they'd scan barcodes out of the Dallas Morning News and Wired Magazine.

I can't help but think that either a) DigitalConvergence had grander schemes in the pipes and this CueCat thing was just to be the first, or b) The DigitalConvergence guys were con artists and the whole thing was a scam to get lots of money from VC's. The 260+ other employees were just pawns in a ponzi scheme.

You joke, but it's been done.

Joel, 'zat really you?

Some recommended reading on the topic of scheduling: Painless Software Schedules

Joel Spolsky wrote a pretty informative article about the dangers of software rewrites. He makes some excellent points (and uses Netscape/Mozilla as his example), though I do disagree that rewrites are *always* a bad thing. It's probably true that there's a strong tendency to pronounce old code dead prematurely in the OSS world, however.

Not that I blame them, from a business standpoint why have one product when you can have two with none of the extra work?

It's called market segmentation, and it exists in virtually every area of business. There is nothing insidious or unusual about this.

http://www.joelonsoftware.com/articles/CamelsandRu bberDuckies.html

You say that like it's a good thing(!)

"Internet Explorer's architecture made this app fairly easy to build." as testament to the browser?

No; for some pretty obvious reasons: one obvious one being, you exclude anyone not using that particular browser. I thought everyone realised that was a Bad Thing - or maybe you haven't been one of those people who can't use their online bank because the bank decided to arbitrarily depend on IE. One can only hope that accessibility laws will put an end to such stupidities.

It's not surprising that both browser products have memory leaks. However one could reflect deeply on the differences in responsibility and approaches to remediation. In Firefox's case - being open source - you have complete transparency; you can file a bug on it, check the bug db, or even fix it yourself (don't laugh). In M$'s case, all you can do is kiss your money goodbye and hope they fix it "one day".

The same goes for all the rest of their system, too. It is not always obvious what a disturbing abdication of rights using a closed system is. A friend recently told me of a Visual $tudio crash triggered by a few \b backspace characters in a print statement. Not such a big deal, I thought at the time; but I found myself reflecting on his story later. Eventually the true horror of the situation sank in, which is that we have to completely trust the ability and goodwill of the vendor to deal with any and all issues in their O/S. That is no small responsibility and there is not much evidence that M$ is capable of fulfilling their end of the bargain. I would postulate, after RMS of course, that no closed and proprietary system on the scale of M$ products can be adequately maintained by one vendor. And of course maintenance becomes irrelevant when major "rewrites" are involved, such as have been prescribed by Longhr0n to fix W1ndows' fundamental ills (ref Spolsky on rewrites, Things You Should Never Do

You say that like it's a good thing(!)

"Internet Explorer's architecture made this app fairly easy to build." as testament to the browser?

No; for some pretty obvious reasons: one obvious one being, you exclude anyone not using that particular browser. I thought everyone realised that was a Bad Thing - or maybe you haven't been one of those people who can't use their online bank because the bank decided to arbitrarily depend on IE. One can only hope that accessibility laws will put an end to such stupidities.

It's not surprising that both browser products have memory leaks. However one could reflect deeply on the differences in responsibility and approaches to remediation. In Firefox's case - being open source - you have complete transparency; you can file a bug on it, check the bug db, or even fix it yourself (don't laugh). In M$'s case, all you can do is kiss your money goodbye and hope they fix it "one day".

The same goes for all the rest of their system, too. It is not always obvious what a disturbing abdication of rights using a closed system is. A friend recently told me of a Visual $tudio crash triggered by a few \b backspace characters in a print statement. Not such a big deal, I thought at the time; but I found myself reflecting on his story later. Eventually the true horror of the situation sank in, which is that we have to completely trust the ability and goodwill of the vendor to deal with any and all issues in their O/S. That is no small responsibility and there is not much evidence that M$ is capable of fulfilling their end of the bargain. I would postulate, after RMS of course, that no closed and proprietary system on the scale of M$ products can be adequately maintained by one vendor. And of course maintenance becomes irrelevant when major "rewrites" are involved, such as have been prescribed by Longhr0n to fix W1ndows' fundamental ills (ref Spolsky on rewrites, Things You Should Never Do what a dead-end that is, and for putting in place viable alternatives./p

You say that like it's a good thing(!)

"Internet Explorer's architecture made this app fairly easy to build." as testament to the browser?

No; for some pretty obvious reasons: one obvious one being, you exclude anyone not using that particular browser. I thought everyone realised that was a Bad Thing - or maybe you haven't been one of those people who can't use their online bank because the bank decided to arbitrarily depend on IE. One can only hope that accessibility laws will put an end to such stupidities.

It's not surprising that both browser products have memory leaks. However one could reflect deeply on the differences in responsibility and approaches to remediation. In Firefox's case - being open source - you have complete transparency; you can file a bug on it, check the bug db, or even fix it yourself (don't laugh). In M$'s case, all you can do is kiss your money goodbye and hope they fix it "one day".

The same goes for all the rest of their system, too. It is not always obvious what a disturbing abdication of rights using a closed system is. A friend recently told me of a Visual $tudio crash triggered by a few \b backspace characters in a print statement. Not such a big deal, I thought at the time; but I found myself reflecting on his story later. Eventually the true horror of the situation sank in, which is that we have to completely trust the ability and goodwill of the vendor to deal with any and all issues in their O/S. That is no small responsibility and there is not much evidence that M$ is capable of fulfilling their end of the bargain. I would postulate, after RMS of course, that no closed and proprietary system on the scale of M$ products can be adequately maintained by one vendor. And of course maintenance becomes irrelevant when major "rewrites" are involved, such as have been prescribed by Longhr0n to fix W1ndows' fundamental ills (ref Spolsky on rewrites, Things You Should Never Do what a dead-end that is, and for putting in place viable alternatives./p

You say that like it's a good thing(!)

"Internet Explorer's architecture made this app fairly easy to build." as testament to the browser?

No; for some pretty obvious reasons: one obvious one being, you exclude anyone not using that particular browser. I thought everyone realised that was a Bad Thing - or maybe you haven't been one of those people who can't use their online bank because the bank decided to arbitrarily depend on IE. One can only hope that accessibility laws will put an end to such stupidities.

It's not surprising that both browser products have memory leaks. However one could reflect deeply on the differences in responsibility and approaches to remediation. In Firefox's case - being open source - you have complete transparency; you can file a bug on it, check the bug db, or even fix it yourself (don't laugh). In M$'s case, all you can do is kiss your money goodbye and hope they fix it "one day".

The same goes for all the rest of their system, too. It is not always obvious what a disturbing abdication of rights using a closed system is. A friend recently told me of a Visual $tudio crash triggered by a few \b backspace characters in a print statement. Not such a big deal, I thought at the time; but I found myself reflecting on his story later. Eventually the true horror of the situation sank in, which is that we have to completely trust the ability and goodwill of the vendor to deal with any and all issues in their O/S. That is no small responsibility and there is not much evidence that M$ is capable of fulfilling their end of the bargain. I would postulate, after RMS of course, that no closed and proprietary system on the scale of M$ products can be adequately maintained by one vendor. And of course maintenance becomes irrelevant when major "rewrites" are involved, such as have been prescribed by Longhr0n to fix W1ndows' fundamental ills (ref Spolsky on rewrites, Things You Should Never Do what a dead-end that is, and for putting in place viable alternatives./p

You say that like it's a good thing(!)

"Internet Explorer's architecture made this app fairly easy to build." as testament to the browser?

No; for some pretty obvious reasons: one obvious one being, you exclude anyone not using that particular browser. I thought everyone realised that was a Bad Thing - or maybe you haven't been one of those people who can't use their online bank because the bank decided to arbitrarily depend on IE. One can only hope that accessibility laws will put an end to such stupidities.

It's not surprising that both browser products have memory leaks. However one could reflect deeply on the differences in responsibility and approaches to remediation. In Firefox's case - being open source - you have complete transparency; you can file a bug on it, check the bug db, or even fix it yourself (don't laugh). In M$'s case, all you can do is kiss your money goodbye and hope they fix it "one day".

The same goes for all the rest of their system, too. It is not always obvious what a disturbing abdication of rights using a closed system is. A friend recently told me of a Visual $tudio crash triggered by a few \b backspace characters in a print statement. Not such a big deal, I thought at the time; but I found myself reflecting on his story later. Eventually the true horror of the situation sank in, which is that we have to completely trust the ability and goodwill of the vendor to deal with any and all issues in their O/S. That is no small responsibility and there is not much evidence that M$ is capable of fulfilling their end of the bargain. I would postulate, after RMS of course, that no closed and proprietary system on the scale of M$ products can be adequately maintained by one vendor. And of course maintenance becomes irrelevant when major "rewrites" are involved, such as have been prescribed by Longhr0n to fix W1ndows' fundamental ills (ref Spolsky on rewrites, Things You Should Never Do).

The thought that one has no recourse and indeed not even any way to inspect the system one uses (livelihood, etc), is deeply, deeply disturbing, and I again have to thank RMS for pointing out long ago what a dead-end that is, and for putting in place viable alternatives.

Joel has an excellent article on how pricing goes on software. Although not very related, this is basically an automated bad idea #2.
http://www.joelonsoftware.com/articles/CamelsandRu bberDuckies.html

Suggestion: reduce your costs by subdividing your space, but not into single offices.. Someone else posted that they prefer "large" offices shared by a team of 2-4 people working on the same project. Also start a culture of "cell-phone goes on vibrate when you enter the building--or you buy lunch for everyone in earshot". Another inexpensive thing is a type of floor-to-ceiling whiteboard wall covering--per square foot must cheaper than white-boards, and placed in some of the large open areas it encourages ad hoc design, serendipity, etc. But the people sitting immediately next to those areas in their veal fattening pens may suffer... In an ideal world use a line of internal offices to create noise barriers--why do offices have to steal all the natural light?

Joel Spolsky has some insights on software development workspaces. Item 8 on the Joel Test: http://www.joelonsoftware.com/articles/fog00000000 43.html

A seperate article here: http://www.joelonsoftware.com/articles/fog00000000 68.html

Suggestion: reduce your costs by subdividing your space, but not into single offices.. Someone else posted that they prefer "large" offices shared by a team of 2-4 people working on the same project. Also start a culture of "cell-phone goes on vibrate when you enter the building--or you buy lunch for everyone in earshot". Another inexpensive thing is a type of floor-to-ceiling whiteboard wall covering--per square foot must cheaper than white-boards, and placed in some of the large open areas it encourages ad hoc design, serendipity, etc. But the people sitting immediately next to those areas in their veal fattening pens may suffer... In an ideal world use a line of internal offices to create noise barriers--why do offices have to steal all the natural light?

Joel Spolsky has some insights on software development workspaces. Item 8 on the Joel Test: http://www.joelonsoftware.com/articles/fog00000000 43.html

A seperate article here: http://www.joelonsoftware.com/articles/fog00000000 68.html

Sorry, but I'm going to have to go ahead and disagree with the bulk of your post. It's attitudes like this that make me hate using Windows and Linux for day-to-day work (I use my Mac and Mac OS X for my day-to-day work, but work with Windows and Linux systems as required/appropriate for work, school, and other projects).

Joel Spolsky has a book out called User Interface Design for Programmers. In it, he makes a point of telling a story about a company that set out to design kitchen utensils for arthritic people (I want to say Oxo, but that could be completely wrong, and I don't have the book in front of me to check). The target market was people who couldn't grip a handle as tightly as you or I might be able to, so the utensils were designed with rubbery handles that were easy to hold onto and wouldn't slip, and that were large enough to grip comfortably. As it turns out, these utensils were a huge hit not only with the target market, but also with everyday users: they found the utensils easy to use as well, and the company took off.

The point of this story is twofold: first, you never know who your target market really is until the product is out in the world. You may find that your intended target just isn't interested in your product, or that some group you overlooked while doing market research finds your product by accident, gives it a chance, and loves it.

Secondly, and MUCH more importantly, is the notion that by designing something that is easy for a certain group of people to use, you end up making it easier for everyone to use. Everyone wins.

I consider myself a pretty advanced user (undergrad degree in Computer Science, graduate degree in Comp. Sci. in progress, etc., etc). I use Linux on my PCs and on servers because of the flexibility it provides me. That doesn't, however, that I don't like to have that flexibility hidden from me behind a complex or non-intuitive interface. Consider, for a moment, a program that has a couple dozen options that are binary (yes/no), so that they can be all be chosen by simple checkboxes in a GUI. At first glance, you might think that I would like to have all those options in a single "Options" dialog box. After all, there all the options would then be presented in a single window and I could, in theory, find what I wanted to change quickly and easily. But how do I have to find that option I'm looking for? I have to start going through the options one by one until I find it. And if what I want is at the end of the list, I just wasted a lot of time and got a little annoyed (multiply that annoyance by every time I need to go through this). But what if I arrange the options by, say, function. All the file-related options in one group, all the text-related options in another, all the shortcut-related options in another. Take that a step further, and move each group to its own preference window or tab. Give each section a simple, descriptive name. Boom. You've just reduced the clutter, streamlined the interface, and made your users much happier. Instead of trying to search for "enable syntax highlighting" amongst dozens of checkboxes, I just need to select the text-related tab, scan 6-8 options, and click the checkbox. See, that wasn't so hard, now was it?

It's people who dismiss with the wave of a hand the benefits of good user interface design that really irk me. A good user interface is not something that just happens to materialize out of thin air. Nor is it something that is really best developed by the same people who actually write the code, either. And sadly, it's the general attitudes of "if you don't like it, fix the code yourself" or "it works well for me, it should work well for everyone" that dooms so many applications. And don't even get me started on user interface conventions (I'll just say that they exist for a reason.

/end rant

It's not *always* a bad idea to start over.

I think it is *always* a bad idea to start over from scratch when you currently dominate the market and want to continue to do so: http://www.joelonsoftware.com/articles/fog00000000 69.html

Microsoft does not care about software vendors. The only thing it cares about is it's monopoly. It doesn't care about bespoke app vendors (custom made, one shot applications), but if you want to do anything that will compete with them, or even create a new market that they see has opportunity, they will drive you under.

They needed software vendors when Windows was introduced and had competition. Now they don't, and they don't care about them anymore. .Net is just the latest example of them not playing by their own 'rules'. Ever notice how any change in Windows is first introduced in their own products (notably: Office). Movable toolbars, menus, custom title-bars, etc, etc. They put out 'UI guidelines', on the theory that we all follow them, and make the user interface easily learnable, and then they change all the rules for themselves. Hmm...how does this relate to .NET now?

Developers - it is not in your best interests to follow where Microsoft is trying to push you. Trying to follow anythig like their inter-application communication methodology is a waste of your time. (what was the path now?)

DDE->DCE->OLE->COM->COM+(?)->DCOM->NET ?

Why jump on their cart? Because they say it's the new thing? Oh...MS has a new api, I'd better kill my company trying to follow their twisting and turnings.

They have far more people designing new API's and architectures than any small company has people to keep up with them. It's a losing proposition.

ODBC, RDO, DAO, ADO, OLEDB, whatever .net uses... Just another example of 6 ways they've pushed over the years as the 'latest/best' way to access databases. Which is just one more example of them creating new api's to distract us.

It costs them developer time to continually shift the target, but it may cost you your company to follow it.

Ahh....this is all better explained here: http://www.joelonsoftware.com/articles/fog00000003 39.html

Canonical Anonymous Coward