Slashdot Mirror

Joel doesn't like it either:

Attention, FogBugz competitors: a court has ruled that you are welcome to continue to advertise your products when people search for FogBugz on Google. I actually don't think there's anything wrong with this although it does show a certain lack of class, mm, don't you think? You don't see Wal*Mart advertising when you search for Tiffany.

Joel Spolsky reckons Microsoft Lost the Backwards Compatibility Religion.

of mixing up programming languages and API knowledge. Please read this http://www.joelonsoftware.com/articles/LordPalmers ton.html, where the difference is made clear. The problem is that:

* Learn a programming language is not enough. You need to be good at API programming -- and there are lots of APIs out there.

* You can get 90% of knowledge by reading a book about a certain language or API. But the last 10% of knowledge you get only after several years of practice, and that is the knowledge you need to be a good programmer and a good debugger.

So you can't just use refurbished programmers. Experience is essential!

ptex

A few days later I was called in by our VP and told that I needed to start top posting like everyone else.

While you were burning your bridges by pointing out that he was wrong, did you also point out that perhaps as Vice-President he should have something better to do than meet with individual employs about the format of their email messages? (A good pair of stories on the matter from Joel Spolsky)

I sympathize; we all have to deal with irrational behavior from superiors. Anyone who claims that capitalism naturally leads to highly efficient behavior clearly hasn't actually worked in a large company.

Do you really NEED venture capital or do you just WANT it because it seem like a cool and easy thing? You have so many other options as people have pointed out here (friends, family et cetera). You can even ask your customers to buy a share of your company, then you will have a life long customer and an owner with a strategic stake in your company.

Another article that should be required reading by anyone thinking about getting venture capital can be found here.

Read this first: Strategy Letter I: Ben and Jerry's vs. Amazon

VC may be a good idea, but it probably isn't. Read these links:

• Joel on Software on VCs
• 10 reasons to shy away from venture capital

Dude, you've got to read the whole article. Particularly this paragraph:

First, there are architectural problems. The code is not factored correctly. The networking code is popping up its own dialog boxes from the middle of nowhere; this should have been handled in the UI code. These problems can be solved, one at a time, by carefully moving code, refactoring, changing interfaces. They can be done by one programmer working carefully and checking in his changes all at once, so that nobody else is disrupted. Even fairly major architectural changes can be done without throwing away the code. On the Juno project we spent several months rearchitecting at one point: just moving things around, cleaning them up, creating base classes that made sense, and creating sharp interfaces between the modules. But we did it carefully, with our existing code base, and we didn't introduce new bugs or throw away working code.

He is most certainly not saying that once you've made a poor architectural decision, you are stuck with it for the lifetime of the project. Instead, he's saying that it is possible to change these things without discarding everything. (Throwing the baby out with the bathwater.)

There are also lessons here for when you are writing the first version. Here's one: if your code to open a window needs a lot of new workaround code, add a comment, for the love of God. Version control logs are often enough for fixing existing code, but a big block of code that only is important on one platform really should have a comment in front of it. And, if you have a test machine of the type needing the workaround, add a unit test. (And if you don't, maybe you should get one.) You should never get into that situation where you have that two-page long function for a tiny task and no idea what all that code does. If you do, someone will inevitably rip it out without realizing they've introduced a bug on a platform they're not using.

Then you can avoid problems like this one:

I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked.

In which you're afraid to touch those 5,000 lines of code because there are so many odd situations. If you have tests for them, this isn't a problem. Can you get ahold of all 60 types of server? Maybe, maybe not. But you can at least get a good chunk of them for integration tests. And you can certainly write mocks for the behavior noted as problematic for the others.

I can't say I'm too interested in the debate -- nothing new here, folks -- but I do like the reference Tim Bray made to Joel Spolsky's essay Things You Should Never Do, Part 1 about the dangers of rewriting code from scratch instead of trying to work with the existing code base. It's an old piece, but I hadn't come across it yet, and I like what he says. Go give it a read, then enjoy your weekend.

I'm not a hardcore Fogbugz user, but I've been involved with a few projects that had lightweight use of it, and I think it is quite nice. nice. It runs on Unix/Linux, Windows, and Mac OS X.

It is not free as in beer. But it is quite reasonably priced imho. There's a free trial of course.

Check out their pages on How Fogbugz Works and Why Fogbugz Works

It's from Joel Splosky, writer of the JoelOnSoftware blog.

Maybe the sign was the problem?

People Don't Read

It's surely a bad idea to rewrite and take a step backwards. After all, Code doesn't get rusty.

Absolutely. A book I highly recommend any programmer read is User Interface Design for Programmers. It's only about 150 pages in length, well illustrated, and easy to understand.

One thing the author (Joel Spolsky of Joel on Software recommends is conducting "hallway usability tests." Basically, as you work on a program, pull a non-geek to the side, and have them try to use the software while watching how they try to accomplish a given task. This can be done in 5 minutes, is practically free, and (depending on the project) you can use almost anyone - the office receptionist, a visiting friend, it doesn't matter. This is a great way to spot usability problems early on when they're still easy to fix.

Anyway, excellent book, it's centered around concepts like this with simple mantra to keep in mind. IE: Users don't read, Users are impatient, etc. It really makes to step back and take a look at how an every day person is going to attempt to use a computer, and I feel you'll be a better coder for it.

Let me just throw in a disclaimer here that I have nothing to do with the book or the author, I was just incredibly impressed with a book I picked up essentially as an impulse buy. It's earned its place as one of my favorite books in my programming library, and was worth every penny I spent on it.

An article with noble intentions, but it falls far short.

To begin with, anyone involved in UI development needs to read Joel Spolsky's User Interface Design for Programmers .

From Roe's article:

Professional UI designers tell us that user interfaces should be the first thing designed when we come to develop an application, and that programmers are incapable of doing this kind of design. They say it can only be done by the professional UI experts; OSS projects don't have access to these kind of people, and therefore can never be truly usable.

This is like saying all developers care only about performance, and all manager care only about impossible schedules. There are a number of books out there that aim to give developers the skills to design usable interfaces -- in fact some are on Roe's reference list!

Fitt's law is not the "most basic ... of UI design". Fitt's law has become unreasonably important because UI designers stopped giving users visual cues about keyboard shortcuts. Even my Dad uses the backspace key rather than the back button! Its so much easier. Mouse gestures will also dramatically change the effect of Fitt's law.

In my experience, the weaknesses of open source UI design are also its strengths: (1) the ability to experiment with new interface metaphores; and (2) the flexibility of the software.

The more you conform to established metaphores, the more easily you can make your product usable. Creating new metaphores is difficult, and getting them accepted is even more difficult.

Flexible software typically has a lot of functions and options. The capacity of short term memory is important here: a person at random can remember or concentrate on 7 +/- 2 items at once. At no point should a person be presented with more than 9 items in a selection when one has to be chosen. So there should be at most 9 menus, 9 items per menu, etc. Any more than that and people are operating at less than peak efficiency in order to find the functionality they want.

I got linked to this site from /. some time, and I've since read a lot of the articles. There are lots of good ideas in here for making productive development teams. http://www.joelonsoftware.com/index.html/

What I'm getting at is that when a coder is in said Zone, the hours mean nothing to them. Look up and it's 4a.m. and you haven't gone to the toilet in 5 hours, and you can't remember when you last exhaled.

But extra special conditions are required to get into this Zone.

1. You find the work interesting
2. You have most of what you want grokked

The problem as I see it is the same as when I'm due to be somewhere on the other side of London, and I need to catch the Tube. I know that in a perfect world, to make it to Brixton, say, takes 30 minutes. And it can. iff the tube is waiting when I get on the platform and the connections are smooth. This is all possible, and I've done it before.

Problem is using that perfect situation as the constant in the equation over a long period of time. It is not sustainable unless there is a LOT of 1.) and 2.).

Games coders can fall into this trap because they like it, and they grokk it. So their managers get in the habit of using the Zone as the constant, and they're more right than other managers. Still wrong overall though.

There was a good thread about Runtime Revolution on Joel On Software not too long ago.

I've been using RunRev for a year now and really like it. See my comment in the above link.

-- Frank Leahy
http://www.webphotospro.com/

Anyone who doesn't understand the importance of abstractions is likely to get left behind.

Equally, anyone who comes to rely on abstractions as a crutch will almost certainly get left behind as well... Joel on Software puts it, and other software design principles very nicely...

Anyone who doesn't understand the importance of abstractions is likely to get left behind.

Equally, anyone who comes to rely on abstractions as a crutch will almost certainly get left behind as well... Joel on Software puts it, and other software design principles very nicely...

"Read through Mr. Spolsky's web site and see that he doesn't acknowledge free software/open source at all other than sterotypical blanket bromides."

It's worse than that -- he wrote an essay (was it this one?) on ArsTechnica with massive critisism of Phil Greenspun's "lack of insight" for basing the company around Free Software, and praised the actions of the new VC who decided to scrap the (working, successful) code and re-write it in .NET with a proprietary license.

Naturally, the .NET code was a big stinking failure, horribly late, bug-ridden, and the customers were complaining all-through the process that (a) they liked the software as it was and (b) they wanted modifications now, which ArsTechnica couldn't do because they were busy rewriting their software in an inferior language.

The impression I got of the company was that it went from being a very successful company with a Free Software product, making millions from consulting, to a failed, almost-bankrupt company with a proprietary product that nobody wanted and wasn't earning any money. And Joel Spolsky wrote an essay in the middle of all this, cheering the people with the "vision" to persue a proper software license (proprietary), a proper programming language (.NET), which would now only run on WindowsNT and didn't do what the customers wanted

You could have code like this:

int foo( object& r )
{
r.Blah();
return 1;
}

and you would get crashes there because the r reference was NULL, even though that's completely impossible, there's no such thing as a NULL reference, C++ guarantees it

#include <iostream>

void f(char& ref)
{
std::cout << "value of reference is " << (int)&ref << "\n";
}

int main()
{
char* p = NULL;
f(*p);
}

Hmm, when I went poking around I found this quote almost immediately..

'First of all, failing to write a spec is the single biggest unnecessary risk you take in a software project. It's as stupid as setting off to cross the Mojave desert with just the clothes on your back, hoping to "wing it."' ....

I don't think you are really justified to call the guy an idiot with your single, most likely very out of context, quote. Here is where I got this quote.

"In fact there are lots of great reasons for bloatware. For one, if programmers don't have to worry about how large their code is, they can ship it sooner."

Interesting reasons. Bloat is still bad, no matter how much CPU you decide you can throw at it.

The entire book is available on the Web for free, since the book is basically the collection of Joel's best articles. He cleaned them up, according to the introduction, but anyone willing to "look inside the book" (tm) before getting it, has a chance to go through 100% of it.

Joel is assembling a volume of "the best software essays" of 2004 and is taking reader nominations. Suggest something if you have a favorite, or just click through and read everyone else's picks.

THe Lookout program was mentioned a bit back on Joel on Software and interestingly enough, it looks like they used the Apache Foundation's open-source Lucene full-text indexer to create a good search plugin for Outlook.

while microsoft discontinues support for old systems, they go to extraordinary lengths... ... read raymond chen's blog...

Joel Spolsky wrote in his now famous article about two opposing camps at Microsoft, one of which he calls the "Raymond Chen Camp" and the other, the "MSDN Camp".

Flip. Flop. The strategic direction is the result of a tension amongst younger people that is arbitrated by a few central older characters.

Linux, seems to be organized along different lines. The unpaid authors are motivated by other interests and by different values. Linux may be akin to a spiritual journey for some authors. Such a force may result in a coherency over time that stems from a belief system rather than from a marketplace.

But that's just about the author geeks who create Linux. The marketing people may be on yet different journeys still.

IBM's doing well and plays a part in Linux community.

Meanwhile, the community exhibits a lot of diversity and that's both a sign of flexibility and a source of strength.

I've sat in front of my source code knowing that not only could it be made better, but that there is probably a better way to do it. Unfortunately, the reason old code stays around hobbling around the system with plaster casts around its legs and band aids covering its heads, yes more than one head because at some point I figured that it would be better to stick a brand new head on there rather than refactor the functionality out and create a brand new program.

Old code has much embedded wisdom. Lots of little bug fixes, solutions thought out, methods applied and debugged. Usually it's a really bad idea to scrap it.

If you apply proper refactoring techniques and some underlying method to allow the code to evolve, and you'll find that most cases of code rot are really just code neglect.

Of course, there may be licensing, or other reasons (designed for an environment that no longer exists) why it's best to scrap a particular codebase, but as a general rule, only drop software that's actually unsuccessful in the marketplace.

If it sells, update/extend/refactor rather than rewrite.

... in case they want a GUI to create those presentations. CityDesk's free edition is enough for most presentations.

Yesterday I was reading an interview from Joel Spolsky (You probably know him from Joel on software) and I found the following quote interesting:

In my ("How Microsoft Lost the API War") essay, I quoted a Microsoft guy (and Longhorn Avalon team member) named Joe Beda. I quoted him saying "Microsoft is making a big bet on the rich client." And now he works at Google with Adam Bosworth. I'm sure what they're doing is a new browser. It's the IE (Internet Explorer) team reconstructed inside Google.

C++ would be a totally stupid first language; I don't think it's suited as a teaching language at all. Even C is too finicky in many ways.

But Java is a fairly clean language. I'm biased coz I use it a lot, but I'm quite happy with the idea of using it as a teaching language, especially for OO.

Of course I'm biased since Stanford was doing C++, to Lisp, to Java.

For independent software development and running your software business:
Eric Sink
Joel on Software (read business of software newsgroup)

For inexpensive, reliable order processing:
SWREG
ShareIt

Installers:
NSIS (Windows)
BitRock (Linux, Windows)

Icons/Website:
Go to KDE Look find some artwork you like and contact the author.

• this set of instructions
  
• this manual on how to use them (sometimes incomplete or even misleading)
  
• this platform
  
• your willingness to learn new techniques and technologies and
  
• a considerable degree of focus and dedication
  

Let's set the record straight - Microsoft won the browser wars over the Netscape, because it delivered a better product with IE 4 and IE 5.

Netscape made a fatal development decision. THEY CEASED DEVELOPMENT FOR THREE YEARS. Let me say that again: some PHB acquiesced to the developers' request (or decided on his own---who knows?) to allow them to start over. Oh a medium to large project, you never, ever, ever start over when market share is on the line, lest you wish to become number two or lower. And they did.

The trailing / needs to be removed from the link for it to work.

It was a great article though, I have observed similar effects for some time. Any interesting group always develops core members and the group is better off if those core members are able to somewhat control how the group as a whole operates.

And it's very true that if you go in and disturb a happily functioning group, the core members will go to great lengths to remove the disturbance and punish the offender in some way.

Another article along those lines is this JoelOnSoftware article about socal interfaces.

PS: don't miss the follow-up to that piece. Best line ever: "I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked."

And for those who don't like exercise, I suggest Joel. Samples:

"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."

>> [cut] he said to me... "What's this about usability?[cut]

This is quite normal: something that's you're used to is obviously much more easy to use than something new. See http://www.joelonsoftware.com/printerFriendly/uibo ok/fog0000000249.html

Also arguing about the look is fruitless: to each his own taste..

But if MS decided to write code for a new OS which the management suddenly stopped skrewing over, and everyone on the team could have free constructive reign on their coding, there would be alot more motivated, harder motivated, programmers on that project.

Don't get me wrong - I think there are a lot of brilliant and hard-working programmers who work at Microsoft. In fact you have to be realy really good to even get in there. I read Joel Spolsky (an ex-Microsoftie) regularly and some Microsoft blogs and these guys are far more talented (and wealthy because of it) than I'll ever be.


Alot of people that aren't completely struck against MS by principle (those with open minds?), and those people would have a hayday if you ask me.

Here you've hit on the reason people enjoy working on FLOSS (Free, Libre and Open Source Software): it's fun and the terms of the licenses nearly always mean that a corporation can't take their work and give nothing back.

P.S. It seems there is an evil moral background for MS. Could someone please define this versus any other large corporation?

Microsoft is a baby when compared to organisations like Monsanto, the Federal Government and say, SBC. The reason many people on /. take it personally is because the attacks are personal: the company lies, cheats, steals other companies IP, calls Linux a cancer, Communistic, unAmerican, and a toy - and fights it with hundreds of millions of dollars worth of marketing. I know this gets up my nose because I wrote some of that code it attacks (very very little but still).

The legacy firewall configuration, in Control Panel -> Windows Firewall -> Advanced -> Settings..., is extremely confusing and dangerous. The settings from SP1 get carried over to SP2, but only inside the Advanced area.

Unlike the SP2 firewall, changing a legacy firewall setting in the Advanced area requires a reboot, and it doesn't tell you that. Generally, I've seen that the legacy firewall settings poke a much bigger hole in the firewall than the new SP2 exceptions. It's great that the SP2 exceptions are stricter, but Microsoft really should have disabled all of the legacy SP1 firewall settings, with an option to ask you which ones to enable.

Yes, I'm in the Raymond camp, but I think this is a case where breaking compatibility is prudent, especially considering the goals of SP2.

Read the blog. This guy is one prolific programmer. He's the guy who ensures that all the old windows apps (like the ones from 10 years ago) keep running on the latest versions of windows. He has all sorts of stories about windows bugs and idiosyncracies and explains how they all came to be. It's a fascinating read and I have an RSS subscrption to his blog.

Read this article which is all about his quest for windows and developer backwards compatiblity.

He give this story about Sim City: It deallocated memory, and then used it right after deallocation. It was a bug that windows 95 allowed. So his code make a special check that you were running sim city and if you were, you could use memory right after you deallocated it. It's pretty amazing to see all the hoops that he and his team jump through. But he's a MSFT ledgend.

PS. That blog entry I linked to sent Shockwaves through Microsoft. It's changed the new XML api design, and resulted in the backporting of Avalon to Windows XP.

Do not assume the status quo as the norm. If you take a look at jos and his article on 'how ms lost the api war' - 'The Two Forces at Microsoft', you might better appreciate that within microsoft the, Chen (backwards compatability at os level) vs the MSDN Magazine (who dish out microsoft spagetti recipies) is as unified as many make it out to be.

Do not assume the status quo as the norm. If you take a look at jos and his article on 'how ms lost the api war' - 'The Two Forces at Microsoft', you might better appreciate that within microsoft the, Chen (backwards compatability at os level) vs the MSDN Magazine (who dish out microsoft spagetti recipies) is as unified as many make it out to be.

1) You are using perl right now. How else could you post on slashdot? Who says it has to run on the computer in front of you? Also, are you will to state for the record that you aren't using Windows, X11, Apple's Quartz, or any similar widget-based GUI? What, are you posting in LYNX, with Linux 1.x kernel? I'm really curious to find out what you are REALLY USING...

2) I wish I had a link - somebody wrote a DVD decoder as a perl regular expression that could decompress a DVD in real-time on a >2 Ghz P4. Although a bit unrealistic today, in 3 short years a 2 Ghz P4 will cost $80 on EBay.

3) The quote: "That's strange because I am having a hell of a time playing back video on my 286. Where is the lighening fast program that will play it at the same speed I do now?" Doesn't make sense when compared against what I said. Please read what I wrote again. There were video options on the '286 - they just sucked, were proprietary, and very expensive. (but they weren't bloated!)

4)Additionally, you can't even argue that a java video player is fancier than a native video player. The java player is really less fancy, and less feature-packed. Gee - I thought that somebody as smart as you would be able to understand that being able to play video without installing *anything* special on multiple platforms without having a "Windows version, Mac version, Linux Glib X version, Linux Glib Y version...." would qualify as a "feature". Oh, well. I guess a "feature" to somebody with your mind-set only includes a fancy volume button....

4) Why are boot times a rediculous comparison? Thee fact is, it's about as fast to bring up a customer record using Access on WinXP on a multi-Ghz Athlon as it took to bring up similar records on the '286 using FoxPro and MSDOS 5.0. But, I'd choose the Access-based package over the FoxPRO/DOS one any day of the week...

The point is really this - what you call "BLOAT" I call "features". There is UN-NECESSARY BLOAT, and that we should fight with verve and energy. But, take a look at the damn article I quoted in my original post. Then, I'd like to see what your response actually is.

I do not agree. Having a java codec for browsers may as well be having no codec at all. Reasoning:

1) The only users that allow their browser to run java are those that either don't know how to disable it, or don't know what it is....<SNIP>

2. Java is slow and gobbles up resources....

Some of the things that they say about Longhorn (the fact that they need to roll it out on clients and servers at the same time, in particular) makes me think that they will modify the networking protocols enough that Linux servers will no longer be able to play with Microsoft desktops.

And, this would be one of those things that would probably vault Linux forward rapidly. If it's all new, what's the advantage of Windows?

Take a look here for an interesting article on how Microsoft is losing the "API war"...

Joel on Software said it best:

For example, WinFS, advertised as a way to make searching work by making the file system be a relational database, ignores the fact that the real way to make searching work is by making searching work. Don't make me type metadata for all my files that I can search using a query language. Just do me a favor and search the damned hard drive, quickly, for the string I typed, using full-text indexes and other technologies that were boring in 1973.

And on the same matter - a nice one on user interface desing, which the scribus people can actually attest to complying to...

From my minimal experience with DTP - this rocks!

get a free ipod! This really works... 2 more gmail invites left!

[*] I Am A Game Developer

Modern project management is an exercise in managing uncertainty.

More precisely, it's an exercise in managing risk. Developing software involves all sorts of monetary risk, including real costs and opportunity costs (i.e. doing x instead of y yields $10,000 less money). Generally, uncertainty is the biggest contributor to the total risk.

Joel's painless scheduling is a step in the right direction for estimating and learning from previous estimates.

Comparing software to construction is helpful. Construction projects are not as lean as people think, and they sure seem a lot like software projects, when it comes to risk. The best things to learn include several, varied-length schedules (i.e. a daily schedule set at the beginning of the day, a 3-week schedule that is reviewed often, and a long-term schedule). Also, regularity in scheduling is an amazingly helpful habit. Regularly-scheduled builds, regular releases, regular fixing helps estimation and provides incentives for progress and scaling back the impossible. That all helps minimize risk.