Slashdot Mirror

Sounds like you've been reading Joel.
http://www.joelonsoftware.com/articles/fog00000003 19.html

There are, of course, a variety of indicators of the malaise of the system; one of the more interesting I've seen recently is this commentary on how textbooks used in schools actually get produced.

Actually, I think Joel of Joel on Software has a parallel example of part of the problem with schools, which is that good teaching doesn't scale -- and neither does good programming. Chances are, most slashdot readers can remember a few really great teachers (I can) and can't remember a slew of mediocre or indifferent ones. That's because really good teachers can't be produced by an assembly line, and there is no good system for figuring out who the good teachers are; instead, we have a system today in which teachers willing to put in the time are kept in regardless of whether or not they're actually good (Insert political comment here regarding unions, depending on one's alignment).

We have two big problems: the system as a whole and the quality of particular teachers. The real question becomes how one solves the riddle; I don't know, but I suspect the solution is deeper than "throw money at it."

The reason Microsoft made both XP Home and XP Pro is easy: They can get more people to pay for the Home version, but the people with deep pockets are willing to shell out for a version called 'Pro'.
Joel On Software gives a better explanation of it than I can.

Amen! Let me add to that an extract from a blog rant I wrote up a while back.

Joel Spolsky suggests that one sign of a good programmer is if he writes something like "if (0==strlen(x)), putting the constant on the left hand side of the ==." The recommendation seems to be to put constants on the left side of equality comparisons in general. That way, if you mistakenly write an "=" instead of a "==", it won't compile. But guess what: if you instead put the strlen() call on the left side of this expression, and mistakenly use an =, it also won't compile (yes, I checked it, on a Linux box, gcc2.96 (one of those Red Hat specials)). This example is one that can't give you a run-time error, no matter how hard you try to fuck it up.

The correct strategy he should be endorsing is: always put variables on the right side of a conditional expression. Of course, this is not possible when both items for comparison are variables. And, as stated above, it's meaningless when neither side is a variable. So I really question the value of acquiring this habit whose use you have to put so much thought into, can't use it all the time, so you have to work even harder to remember to use it; seems you might have better luck simply trying to remember to use == when you mean ==.

Some experts seem to disagree with you.

To quote his rationale:

the biggest advantage of the book is that when you throw it at your colleague's head after a very frustrating argument about whether to throw away all your code and start over from scratch, it makes more of an impact than a URL

Blogging can spread the word, but references to printed material carry a lot more weight [no pun] than an html page full of supportive links.

Anyone interested in how this free speach thing corrupts society on a wider scale through disinformation, should go to Speakers' Corner in Hyde Park in London.

There you will see the Evangelicals preaching to their convverted congregation who turn up to support and cry Hallelulejah at the orchestrated time. You will also see a drunkard with a small footladder arguing that "G-d is a Lesbian". There are people listening. Ruin of society does not result.

Note, actual Speakers' Corner content may vary.

Web development is development, so everything that runs for getting "ordinary" develpment work done run for web. The technologies are different, but they are always different. I'd recommend asking this question in one of joel spolsky's forums, such as this one

I think the best thing you can do for your company would be to get a tour of their facility, talk to some programmers, and try to gauge what kind of operation they are running.

If you need some pointers on this, a good start would be The Joel Test. Grab a copy of Joel On Software and take it over there and say, "How does your company score on this test?" They may look at you funny; just tell them you're trying to be sure they're a high quality organization. You can check off some of the boxes yourself, like the "quite working conditions", but on others, you will just have to trust them. If they refuse to talk to you about that sort of thing, take them off your list and go on to the next place, because they are not worth your attention. (Keep in mind they may try to do the "Manage the iceberg" thing to you; this is probably actually a good sign. Just tell them to cut it out. :)

The most important aspect of the development practice, though, is PEOPLE, not tools or platform or methodology or any of that. Unfortunately, it will be very hard for you to get far enough inside an organization to figure out if they people are SMART and GET THINGS DONE. But if you get a chance to talk to someone like a lead developer or project manager within the company, look for intelligence and resourcefulness.

Things to avoid are places where you walk in and they tell you "We'll do your site in $TECHNOLOGY, and nothing else." Also, aviod any place that doesn't try to figure out WHAT EXACTLY YOUR ARE ASKING THEM TO DO before they commit to it!

Unfortunately, you probably will not select the company at which I work. Ces la vis.

Affordances and Metaphors

You should really check out Joel On Software . His articles on user interface design are right on the mark. Specifically, you might want to read his User Interface Design for Programmers book (available mostly online, free).

You should really check out Joel On Software . His articles on user interface design are right on the mark. Specifically, you might want to read his User Interface Design for Programmers book (available mostly online, free).

Also try usability guru Jakob Nielsen's site Useit. Although mostly focused on web design it s a good read for anyone designing interfaces.

There's no way IE7 will be written in .NET, they don't have time to completely rewrite IE from scratch (not if they expect to release a beta version this summer).
And remember what happened to Netscape when they decided to do a rewrite.

Software is simply a component. Adding 256 Megs of RAM will cost about the same for my old 300MHz K6-2 as it will for a reasonably fast modern CPU.

In the end it's all about supply and demand. If they price it at an amount targetted at the Sunfire F25K, then they'll simply lose the business of the local database user. So they use number of processors as a means for segmentation. This means they can charge a lot to people who can afford a lot, and less to people who can't afford as much. Fair enough, but this isn't about fairness. It's about maximising profits. I could go into more detail, but this guy has already written a long winded article about the subject.

"If you have a website that shows a map, and the user clicks to zoom in, they're going to expect the map to zoom in, quickly--they will no longer tolerate the full-page-reload-and-scroll-to-the-top that Mapquest has conditioned them to accept.

"That's what I meant by "raising the bar.""

This is called "Market Segmentation".

This is a good thing for companies to practice from a profit point of view. Its the process that makes the most money. It also means that people who can not afford to pay a higher price (e.g. students, the elderly) can get software/movie tickets at something they can afford.

Joel Spolsky wrote about it here.

Joel on Software has a (typically) entertaining and insightful piece on pricing and market segmentation.

Joel On Software has an article that touches on some of these issues. Well worth a read, IMHO.

Joel On Software has an article that touches on some of these issues. Well worth a read, IMHO.

was it this guy?

Why do people stay on Windows? Microsoft Office? Partially, but that doesn't account for why 90% of consumers do. Security? Nope. Stability? XP goes a long way, but nope. The real reason people stay on Windows is because that's where the games are. Period.

Also, something Joel pointed out, if you're developing a Windows game you're developing for 90% of the market. If you write for the Mac you're writing for less than 10% of the market. If you have a Windows game and you port it to the Mac, the cost of porting it has to be less than 10% of the overall cost (of doing both ports) or it's not worth it, because you will only get 10% of the overall sales from the Mac. Conversely, if you're writing the game for the Mac then you can port the game to Windows and get nine times the potential sales. Notice how, as much as Macintosh people loved Marathon and were somewhat ambivalent about Marathon 2, Marathon 2 sold truckloads more since it was the first Bungie game to run on Windows.

Guys,
I work on the MSN.com Homepage team. Thanks for all of this feedback. We know that there are still some validation errors. There are still some accessibility issues. We will be working to fix those issues as soon as possible. Please let us know what you think.

...so why did they ask for feedback, before fixing those?

As Joel says

"It is crucial to get to zero known bugs (what Netscape famously called "Zarro Boogs") before releasing a beta. If you don't, you'll waste a lot of time during the beta reading 200 emails about a bug that you already knew about."

Something tells me the MSN guys are going to get more than 200 messages about validation issues, and almost none about things they care about.

That is not correct. Netscape 6 was simply a clone of an early Mozilla beta

Given that most customers use PCs almost exclusively for word processing, e-mail, and web surfing,

But, that's not what most people use their computers for! Read up on the The 80/20 Myth to get some idea what I mean.

True, 80% of computer use is what you specify - but what about the other 20%?

It's ALL OVER THE PLACE. CAD/CAM. Web design. Graphic arts. Video games. Taxes and book-keeping. Software engineering. Encoding MP3s. Playing DVDs, MP3s, DivX, MPG content. Building quilt patterns. Serving database content.

Just because you can satisfy 80% of the uses of a computer doesn't mean that you can satisfy 80% of the users out there with 80% of the applications. If they were to be sold, your 80% computers would leave 100% of its users 20% dis-satisfied.

I think Joel answers this nicely.

I am sure most of these programs are small and maintained by a few people. So does it matter if it is ugly?

Yes, in my experience it matters *more* in that case. If 10,000 developers know how the code works, and it's ugly, I can get find somebody who'll answer how it works for me. If 3 developers know how it works, chances are they've all moved on by now, and I'm SOL.

Another reason why ugly code in a small program is bad: if they can't figure it out, and it's not very long, they'll just rewrite it. If it's a big program, they're much less likely to start from scratch, and instead refactor the program so it's more understandable.

Ugly code is a liability anywhere, because it slows you down and limits your options.

Citydesk by the company of software engineering guru Joel Spolsky, would be an excellent choice if you are a) running Windows b) willing to spend a little money.

Maybe less leaky abstractions in our languages.

I think this is the article you're referring to.

1) Bugs should not have owners. This is th approach taken by Joel (thy joelonsoftware.com guy) when creating Fozbug.

"...every bug needs to be assigned to exactly one person at all times, until it is closed."

Joel Spolsky (from Joel on Software), wrote an article awhile back about trying to do many things at once...which just isn't possible. You can try and context-switch, but just like David Allen states, you're wasting time and breaking your flow.

For a programmer's perspective on this issue, check out the article here.

I've read Getting Things Done as well. Highly recommend if you want to get organized and have a "mind like water" like Allen talks about.

Aktiom Networks: Debian, Fedora, RHEL Virtual Servers for Professionals

A great read.

While paying developers to work on an EXISTING open source project does work, paying developers to CREATE an open source does not. What happens? Millions of dollars in... money and feature creep at an unimaginable scale.

That's funny, what you wrote sounds pretty much like what everybody was saying about Mozilla circa 2000 or so.

Now, of course, we all can see what Mozilla.org hath wrought. But it took a loooooong time to get there, and a lot of missteps. So Chandler in this respect is not terribly different from Mozilla.

Firefox 0.1 was 10x more usable than Chandler 0.5.

That's because when Firefox 0.1 was released (as Phoenix 0.1) on Sep. 23, 2002, there had already been nearly five years of work plowed into the Mozilla codebase.

OSAF organized in 2002 or so, so if you want to see where Mozilla was at an equivalent point in its lifecycle, go dig up a copy of Mozilla Milestone 18 or so (bring your crash helmet, you'll need it).

I do realise the difference - what you called a map is just a subset of layers (streets, topography). GIS can contain these layers and many more, including power grid capacity and the ability to combine them all for processing, display, tracking, etc. But seriously, the prices for GIS data are astronomical. And because they are astronomical, they destroy the unborn mass market for geo data. Joel writes about the same problem for software pricing. Of course, there are some data sets for which there is no conceivable mass market, but overall there definitely is one for geo data/systems. But since it costs $1000s, only those who absolutely need them and can afford to pay insane proces become the clients, perpetrating this vicious circle.

Personally I found out (when making a city map for PDAs) that it's several orders of magnitued cheaper to hire a student to scan a folded map and create a vector map manually than to buy digital data.

I thought Joel said to stop worrying about all the jobs going to India. What gives? Is it only old people in Korea who should worry about outsourcing? I'm so confused.

I thought Joel said to stop worrying about all the jobs going to India. What gives? Is it only old people in Korea who should worry about outsourcing? I'm so confused.

Actually it was Joel Spolsky. His problem is: he created his own company, he is successfull and doesn't need to worry about his own future. With all these books sold throught FUD, we don't know what's really happening...

HTML is a must. Learn it from the w3schools website - their tutorial rocks. Also check out XHTML, and see if you can conform to the standard in everything you write, whether it is required by your job or not. Standard conformity is a good way to save yourself when all the browsers in the world render differently.

CSS is good to know, BUT: most of the time, a company will have a CSS template that they use over all their web pages. Sometimes you'll just have to include this template in your HTML (a one tag thing), and sometimes you'll have to edit it a bit. If you ever have to make your own, a quick look at the above website will help you do it immediately (if you can already do HTML, CSS makes a lot of sense), although I wouldn't focus on it initially.

ASP (& VB), JSP (& Java), PHP (& Perl). Most companies are going to be tied to one of these three. The best thing to do is be a beginner at all of them - take a look at sample code from all six - and then become an expert on the job. My current employers (a university) are tied into Microsoft products, and politics (and other interesting financial things) keep them from changing. However much I would like them to move over to LAMP, I'm not going to sit and mope and lose my job. THUS, I code in ASP with Microsoft SQL-Server, and write VB programs for another section of my department. Be flexible. Don't assume you'll get to use your language of choice, wherever you work. Sometimes conditions prohibit it.

Learn SQL. Forget all this "learn MySQL" stuff. The connection to the database is generally something you'll write in 30 secs - with some template somewhere - and the SQL code to actually query and update that database is going to be the important, life-changing stuff. Learn SQL. On that note, if you're planning on being more of a back-end web developer (like me), learn database management. Learn how relational databases work. Learn how JOINs are your friend, and multiple relations (or tables) are a good thing. Ugly database code kills me.

And, to take a note from Joel yesterday, know how to communicate. Most web designers - the people who will be giving you changes that you absolutely must make or they'll die of horror at that color scheme - are art or design majors who have the elite thing going just like most of us programmers. Learn how to talk, how to listen, how to accept someone else's decisions when you don't have the power to make them - yet.

If you're planning on being back-end, there's a lot of other stuff you might need to know: how virtual directories work, how IIS sets up ASP applications, how Apache's configuration file works, how home directories are transferred over, how server scripting actually works, how to lock down a web server, etc. But if you have a good grasp on the above, and you stay flexible, you should be ok in the job market.

(That, and having all those acronyms on your resume will get people hooked if you can actually confirm your knowledge!)

....and Joel has something to say on that topic.

They're usually focused on a specific area that the author is interested in. Joel on Sofware, for example. Or Dan Bricklin's blog. Or the various Microsoft blogs by people working on .net. Or the Lambda programming languages weblog. Or any of the popular writers and musicians who have weblogs.

This is what people read. Not teenybopper angst and love lore.

The quote is from this article:
http://www.joelonsoftware.com/articles/APIWar.html

The moral of the story: Pressing the preview button won't save you if you don't actually READ the preview before hitting submit.

This is a great vision, but, as Joel points out at http://www.joelonsoftware.com/articles/APIWar.html , there are quite a few applications where latency matters, not bandwidth (scroll down about 4/5 of the way, where he says, "Here are a few examples of things you can't really do well in a web application").

Even if you got all of the other latency limitations out of the way, you're left with speed-of-light delays. Imagine a server on the other side of the Earth; it's 20000 km away. That's a 13 ms round-trip, which limits interactivity to 8 Hz, which is way below the threshold considered "interactive" (which is around 20 Hz).

What this means is that those operations which are latency-sensitive need to live on the client, or very close (on-LAN, most likely, or, perhaps, at a municipal level), which still means substantial local computing power.

Joel wasn't refering to ASP.NET, he was referring to .NET in general. If you check the article How Microsoft Lost the API War, you will see what he meant more specifically. He actually quite likes ASP.NET.

However, ASP itself wasn't soley responsible for the problems with cut-and-copy disease. It was a problem of developers thinking at page level versus creating an application that handled page generation. The problem could be prevented with ASP, although admittedly it did encourage that style of coding.

Joel wasn't refering to ASP.NET, he was referring to .NET in general. If you check the article How Microsoft Lost the API War, you will see what he meant more specifically. He actually quite likes ASP.NET.

However, ASP itself wasn't soley responsible for the problems with cut-and-copy disease. It was a problem of developers thinking at page level versus creating an application that handled page generation. The problem could be prevented with ASP, although admittedly it did encourage that style of coding.

Keynote can make a dent in PowerPoint because presentation files are traded relatively rarely. For spreadsheets and (for want of a better term) Word documents, interchange is essential. Perception is reality, and if someone can't read a Word doc because you made it with something other than MS Word, it is your fault. If it's because of screwups between Office XP, 2004, 2001, 2000, or '97, both parties can safely blame MS. Otherwise, the 'nonconformist' takes the blame. Everyone here should know by now that no one wants to hear how they shouldn't be using Word documentns. Users want it simple and to just work. 100% Word compatibility is impossible--at best, you're spending all your resources chasing a moving target. At worst, you're doing a bad job and no one will use your product.

And remember kids, for every mom and dad you get to start using Open Office, there are a thousand companies with a thousand employees each who will continue to buy MS Office. Overthrowing the market leader is possible but it gets more and more difficult every year. There are orders of magnitude more Excel users today than there were Lotus 1-2-3 users.

Personally, I think Adobe really missed the boat. They should have made a word processor based on PDF. The full version of Acrobat can edit text, so they should have made something--even as simple as MS WordPad--where PDF was the native format. Since everyone and their brother can read PDFs (and they hold their formatting even better than Word docs) they could have distributed a $50-$100 PDF editor--nothing more than Acrobat Reader and Wordpad--that would have ate MS's lunch. Think about it--anyone with a free tool that they already have can read your documents on any platform, and anyone with an inexpensive editor can make and save changes in the native format. Could've been great.

As could be read on Joel on Software, Webapps are becoming major competition to MS. That's why a better browser is the last thing MS wants. Worse browser = better browser.

Joel Spolsky has probably done the best job I've seen of explaining What's Wrong with Unix.

Like C#Develop
Like Enterprise Manager

Because .NET is so piss easy to program.
I mean you get more enthusiasm of people joining projects and submitting code.
I mean how many of us can submit code to GIMP or code filters?

What about Open Office have you seen their perverse "VB" - how stupidly unintituive? How can company-apps be easily migrated? That is not Open Basic that is sick-Java mutated
But again because .NET is so slow and fails to be truly manageable on a larger scale (take Orkut for example) projects like this may die soon. Microsoft constantly changing the protocols and APIs doesn't help much either..

Still there are some absolutely IDIOTIC companies migrating their win32 apps to .NET - are you mad ???

Microsoft is like a mediocre daddy .. ah so many promises.

You: Oracle sends a team of slick salesmen to do 4 months of PowerPoint just to get one > $100,000 sale.

Joel Spolsky: $75,000 - $1,000,000, sold to a handful of rich big companies using a team of slick salespeople that do six months of intense PowerPoint just to get one goddamn sale. The Oracle model.

Otherwise, your comments were +5 Insightful ...

Check out the article on Why this will raise the bar. You're right that this, in and of itself, is not going to make an enormous difference in how we search. The idea of instant feedback without a browser refresh, on the other hand, is a very big deal.