Slashdot Mirror

Go to Joels article on Guerrilla Hiring and click the link (in the article) that says "unwashed masses". No wait, if you are reading this, you have already been to the site he links to.
Yeah, those stupid slashd... Uh, wait a second.
Damn!

We relocated to a spot in midtown last year (though, not with the budget Joel had, apparently), and let me tell you, this is even more amazing considering he did in NYC. Take any ordeal with real estate anywhere in the country and multiply it by a 1000... then you're only somewhere near the neighborhood of what it feels like to negotiate digs in the Big Apple. And don't get me started on the wiring jobs and the telecom lines in this city, cuz it's a freakin' mess. His NYC office space advice is here.

You probably mean: if you don't want to be able to interoperate with the rest of the world, stop supporting Microsoft protocols.

Some of us want to use Linux/BSD/whatever but would REALLY like to be able to read/write Microsoft protocols or file formats, because of their work, clients or what else.

The best solution IMHO would be for the open source world to offer flawless read/write filters, so those 'closed' protocols suddenly become open. It's what Microsoft did when they wanted Excel to gain marketshare from Lotus 1-2-3, see also this article by Joel Spolsky.

When you are a small minority, it doesn't help to 'just say no'. You'll be alone in your nay-saying.

The argument that Linux needs some kind of standardization on this front flies in the face of the history of the software business and has no real grounding in reason.

Not really. Early versions of Microsoft Word ported to the Mac were essentially direct ports, depending on control and Function keys rather than Menus and Command key standards (-S save, -F find, -V paste, etc.). They sold very poorly and allowed the competition to get quite a bit ahead. (I know that's flimsy on details, but I can't remember where I read it and I don't have good terms for a google search. I'm willing to admit it may have been WordPerfect or something else entirely, but there was a major application that was ported without following Apple's GUI guidelines and was flatly rejected.)

In other words, if there is no standard then in order to compete with existing products you must either copy how they function or hope that your marketing can convince people that it is so great that the learning curve to relearn simple things like cut, paste, save, etc. is worth the end result. If someone came along with a clock that was never wrong but could only run counter-clockwise, it would probably not do very well. I can't remember which car maker, but someone was designed an new electric car that uses sticks instead of steering wheel or pedals - it may be very good, but too different to sell.

As for your other examples, they prove my point. Every Word upgrade that move things is met with resistance - the only way they 'succeed' is that the file layouts change, so if you work with others who have upgraded you must also. Adobe is a specialist provider for graphics areas - if you needed it, you learned it. It took longer than would have been necessary if they'd followed a Windows standard, though I daresay it is likely that they early interfaces matched their Mac versions where the print/graphics industry started. They may have been aiming at professionals moving from the one platform to the other, so it would have been more beneficial to emulate their other product than to conform to the Windows standards, which probably weren't that well defined at the time anyway.

In my search I found an interesting discussion here, which mentions the problem includes an example with simple OK/Cancel dialogue boxes - the tendency to get creative and use symbols, which only serve to confuse people if you rearrange things as well.

But in my experience, users will choose a window manager that suits them and then stay with that.

Really? Do you mean with Linux users? In my experience, users who aren't computer professionals will learn as much of whatever system is put in front of them as they need to do their job, and nothing more. The same with any tool - how many people have phones in their office capable of all kinds of neat things, but never actually set them up? How many people fully use anything? Watches, PDAs, cell phones - all have features most people ignore. Hell, how many people who aren't in technology-based industries bother cross-programming their TV/VCR remotes? Most remotes are capable of managing either in a matter of minutes with their included charts. But most people would rather just have multiple remotes around than even consider doing it.

different 'generations' of proprietary software have at least as much incompatibility with each other as proprietary vs Free software [...] major OSS server side projects (Samba immediately springs to mind) have fantastic interoperability

Some stuff is getting there, but not everything.

You say you have a problem with trolls. I suggest a "Report to moderator" link added to every post. Every user will be able to report a offending post, but it would require an action of one of the select few to actually edit or remove it. You can be the only moderator, or you can grant the power to a few other users. If the site is small, you don't need much manpower.

It would also help if you could ban IPs of the trolls. I don't suggest requiring registration with e-mail confirmation, because if your site is small, you don't want to present users with additional hurdle.

Also check this very useful site for some hints: Joel on Software - Building Communities with Software.

Did someone say Dave Thomas?

I'd like a Big Bacon Classic, please.

Thanks and keep the change,
Consumer

• arrive @ 8.30
• delete spam
• read emails and logs
• check seti@home proxy status
• check computer mags, blogs (William Gibson], Joel) and slashdot
• 9.00 ready to code & debug

I don't like Joel or anything, but he covered this... basically, it may not be the victowee against Windoze you think it is...

If Explorer 7 will be tied to the new OS, it will take at least another two years (and probably three) before it becomes available.

The famous talk show transcript says: "Further improvements to IE will require enhancements to the underlying OS." I tentatively translate this line as "We cannot improve IE any more" because it fits with an idea I've had in the back of my mind for two years now.

Why is Microsoft unwilling to fix the CSS bugs that everyone's been asking it to fix for ages? I think it's not unwilling but unable to do so. Explorer's code engine cannot be updated any more.

The [Mozilla] Project needs to get its act together, though. No more rehearsing for the Navel Gazing Split Personality Idiot Savant role. No more antique cars stuffed with vague X-technologies nobody understands anyway. And no, not even one web standard. The Project should put Mozilla on a strict diet and star it as the Viable Alternative to the Senile Evil Dinosaur Usurper in the epic multimedial co-production "Browser Wars II: The Saga Continues".

If the Project does so, it has a future. If it doesn't, it will sink further into obscurity and silly names.

Apparently this guys has been out of the loop. I agree the silly name changes, and change in directions hurt, (hell it confused me too), but now they are on a strict roadmap. The Firebird browser is on a strict diet, it's slicker, leaner and meaner than anything Microsoft has to offer. Even some of the biggest Windows advocates have jumped on the bandwagon.

Hopefully enough eyes will be opened, and will see that the future is Firebird.

Mike

What exactly do politics have to do with programming languages?

One word: Ada.

There are no engineering reasons to back down from anything

If cost-benefit analysis indicates that a ground-up rewrite would provide better value than refactoring, even in the face of Joel's article, then what do you do?

The spectacle of CIO's and IT managers, running around like Henny Penny, stressing their desire to "align ourselves with the goals of the enterprise" is truly disturbing.

If the head of Sales, or Marketing, or the legal department, or Finance went running around all over the place reminding each other of their need to get "aligned with the enterprise" they'd be bloody fired. I mean seriously. It'd be bloody scary if the sales team WASN'T aligned with the enterprise. This is not something they need reminding of. How badly have these CIO's mismanaged if they're ONLY NOW picking up on the fact that they're PART OF A BUSINESS?

This kind of consulting is the worst kind of sophistry out there. IT consultants constantly restate the basics with a slightly hipper rap.

Nicholas Carr is spot on when he writes that IT technologies are becoming commodity inputs. Fungibles. There is no strategic advantage to be gained in having a Content Management System. It's useful, but it's not strategic . Soon, the same will be true of "CRM", "Data Mining" and "Data Wharehousing." It's been true of ERP systems for a long time.

Once you recognise something as a commidity you try and reduce its cost as much as possible. Aggresively. You commoditize your complements and your inputs. I harbour a fantasy that one day my company will dump JD Edwards, embrace GNU Enterprise, and happily submit its changes and enhancements back the project because what do we care if our competitors get the same code? In fact, why not band together and jointly fund such a thing? It will reduce costs, without sacrificing what we see as our strategic value or differentiating strengths. Aaaah, pipe dreams. :-)

PS: To me, "book review" implies some kind of analysis or critical thinking. It's not supposed to be a chapter summary. I can get that from the Cliff Notes.

Some solutions are easier to use. For example, building a GUI from a standard set of widgets is dirt simple using Visual Studio. But good design is still hard, and good analysis is even harder. Even assuming that your app doesn't have bugs that crash it, many naive algorithms that work just fine with your sample data don't scale to huge databases or high transaction rates or huge numbers of users.

That doesn't make ease of use bad in itself. However, there is also a very real danger that bosses, customers and users will perceive the project as being done because the GUI looks complete and polished. Joel on Software has a good article on this very problem entitled "The Iceberg Secret, Revealed"

Some solutions are easier to use. For example, building a GUI from a standard set of widgets is dirt simple using Visual Studio. But good design is still hard, and good analysis is even harder. Even assuming that your app doesn't have bugs that crash it, many naive algorithms that work just fine with your sample data don't scale to huge databases or high transaction rates or huge numbers of users.

That doesn't make ease of use bad in itself. However, there is also a very real danger that bosses, customers and users will perceive the project as being done because the GUI looks complete and polished. Joel on Software has a good article on this very problem entitled "The Iceberg Secret, Revealed"

Not just caring more about the subject, but they also are important for their independence. If my company depends on something, you can't expect me have a independent opinion about it. If it would be good for some company to have a mozilla control, how do you know that a rant about a COM control for mozilla is a sincere opinion, or just a claim to have browsers programmers working for free?

90% of all desktop users are using MS. If they attempt to migrate to GNU/Linux and no key-combinations work as expected, they will not think the software is good.

It doesn't matter whether it's hard for them to use because of lack familiarity or just absolutely poor design. The point of your software is that users should be able to get used to it quickly.

It's called the user model. The user model is always right, period. If you are going to switch from the user model to something else, your something else better be at least 100% better. Otherwise, it's not worth the initial cost. Users will never take a second look at it.

The whole point of a GUI is that things should be intuitive. How would you expect to draw something free-form? Probably a pencil for a thin line, and a paintbrush for thicker "painting" strokes.

See Joel on Software, and User Interface Design for Programmers (this is a particularly good read, which *nix developers are direly in need of):

Chapster 1: Controlling Your Environment Makes You Happy

Chapster 2: Figuring Out What They Expected

In short, your program is easy to use (and learn) if it behaves exactly like the user thought it would. The simple fact is, users are not very patient (most of them). And they sure as hell don't read the fucking manual. Why should they? It's a waste of time. When you buy a car, do you read the entire manual before using the car? Do you even read the manual at all, unless you absolutely have to? If they can't figure out how to use your program just by sitting in front of it, then they probably aren't going to bother ever using it again.

Face it. First impressions matter, right or wrong. Maybe Netscape's CTRL+[ really is a better way to go back when browsing the web, as opposed to Internet Explorer's ALT+= (left arrow), once users have associated that key-combo with back. But the problem is that 90% of all users think that ALT+= means back. By changing that, you are pissing them off. This makes them frustrated, and the 15 other "little improvements" of your program will piss them off even more. Which means they won't user your product -- "this fucking sucks", is surely what they will say. And, if you analyze it, ALT+[ isn't necessarily better anyways. Though that key-combo may be eassier to ready, the keys are closer to other keys, so it's easier to make mistakes; furthermore, it is not intuitive. An arrow is intutive for "go in that direction". Brackets are in no way intuitive for that.

When doing user-testing, you do not correct for various factors. You do not say, "oh, well, he's a life-time PC user, or a life-time Mac user, so I should give him or her time to "get used to" my program, then see how well he or she does". In real life, users don't want to "become familiar with your new way". Think about how arrogant it is of you to ask that of them. The user does not want to get used to "your better way" of doing things. Worse yet, they really don't want to get used to your "just as good way" of doing things. What if a car-company made a car with a wheel that operated like the joystock on an airplane...turning it left really turns your car right, and turning it right really turns your car left? Or what if they put the brake pedal to the right of the accelerator? I hope you get the point. Users aren't going to stick with your program if it's hard for them to learn. They will dump it, and use something that's easier for them to learn, irrelevant of the trivial improvements your program may have once they get "familiar with it".

The thing to do is always match the user model. That probably means doing what MS for many things, unless your new way of doing things offers at least a 100% improvement (e.g., having a universal menu-bar at the very top of the screen like Mac would be good, as would bleeding other stuff into the four corners, and screen edges).

90% of all desktop users are using MS. If they attempt to migrate to GNU/Linux and no key-combinations work as expected, they will not think the software is good.

It doesn't matter whether it's hard for them to use because of lack familiarity or just absolutely poor design. The point of your software is that users should be able to get used to it quickly.

It's called the user model. The user model is always right, period. If you are going to switch from the user model to something else, your something else better be at least 100% better. Otherwise, it's not worth the initial cost. Users will never take a second look at it.

The whole point of a GUI is that things should be intuitive. How would you expect to draw something free-form? Probably a pencil for a thin line, and a paintbrush for thicker "painting" strokes.

See Joel on Software, and User Interface Design for Programmers (this is a particularly good read, which *nix developers are direly in need of):

Chapster 1: Controlling Your Environment Makes You Happy

Chapster 2: Figuring Out What They Expected

In short, your program is easy to use (and learn) if it behaves exactly like the user thought it would. The simple fact is, users are not very patient (most of them). And they sure as hell don't read the fucking manual. Why should they? It's a waste of time. When you buy a car, do you read the entire manual before using the car? Do you even read the manual at all, unless you absolutely have to? If they can't figure out how to use your program just by sitting in front of it, then they probably aren't going to bother ever using it again.

Face it. First impressions matter, right or wrong. Maybe Netscape's CTRL+[ really is a better way to go back when browsing the web, as opposed to Internet Explorer's ALT+= (left arrow), once users have associated that key-combo with back. But the problem is that 90% of all users think that ALT+= means back. By changing that, you are pissing them off. This makes them frustrated, and the 15 other "little improvements" of your program will piss them off even more. Which means they won't user your product -- "this fucking sucks", is surely what they will say. And, if you analyze it, ALT+[ isn't necessarily better anyways. Though that key-combo may be eassier to ready, the keys are closer to other keys, so it's easier to make mistakes; furthermore, it is not intuitive. An arrow is intutive for "go in that direction". Brackets are in no way intuitive for that.

When doing user-testing, you do not correct for various factors. You do not say, "oh, well, he's a life-time PC user, or a life-time Mac user, so I should give him or her time to "get used to" my program, then see how well he or she does". In real life, users don't want to "become familiar with your new way". Think about how arrogant it is of you to ask that of them. The user does not want to get used to "your better way" of doing things. Worse yet, they really don't want to get used to your "just as good way" of doing things. What if a car-company made a car with a wheel that operated like the joystock on an airplane...turning it left really turns your car right, and turning it right really turns your car left? Or what if they put the brake pedal to the right of the accelerator? I hope you get the point. Users aren't going to stick with your program if it's hard for them to learn. They will dump it, and use something that's easier for them to learn, irrelevant of the trivial improvements your program may have once they get "familiar with it".

The thing to do is always match the user model. That probably means doing what MS for many things, unless your new way of doing things offers at least a 100% improvement (e.g., having a universal menu-bar at the very top of the screen like Mac would be good, as would bleeding other stuff into the four corners, and screen edges).

As a long term unix developer who tried a job where windows was mandated:

It is an absolute nightmare to do anything on Windows that isn't explicitly allowed by Microsoft.

Have you ever tried to debug some random piece of crap VB dll or vbscript ( two of the four current VB dialects... vb.net, vb6, vbs, vba )? Its a fuckload harder than a horrible shell or perl script. Python scripts are pretty hard to make truly horrible, so those are usually even easier to debug.

COM is really just a horrible hack to make people think there is a C++ abi on Windows. It is an absolute disgrace to actually use. This is the reason so much is done in VB on Windows. Microsoft have made C and C++ into a completely useless platform for doing anything quick. There are over 30 different types of string used in the MS apis... what does that tell you?

Every api seems to have from 9 to 35 arguments. Nobody knows what they are for... its a cut and paste job from MSDN, yet again... and then we get on to business processes.

People start off with a spreadsheet or a word document. They add macros to it. They expand it. They go fucking insane. The next thing you know you are expected to work out what a fucking idiot has created in the worst language known to man, VBA. There are so many random limitations in this crud that even the bog standard excel user hits them on his first macro, and starts making up crazy work arounds, each different than the other. Fuck you, Joel Spoelsky..... . I can't believe that guy is proud of his "Excel macro strategy".

And before you say .NET, yes, cloning Java is a good idea if you can't bring yourself to actually use something not invented here. But people still have to deal with the utterly brain dead attitude of windows, and Windows.Forms is still the absolute worst GUI toolkit in use... You still end up having to use COM, and anyway, why the hell wouldn't you just use Java unless you are a complete MS donkey?

On unix, the first thing is that I have choice... I don't have to go with Apache, or Tux, or publicfile, or roxen, or zope, or roll my own with twisted , my current favorite trick. On windows, if you don't use IIS, you are likely to get screwed over at any point.

Now, be honest. You tried to use unix but you got scared. "Mummy, theres no drive letters! I'm lost!!!!! Waaaaaah!!!!". You didn't want to know what was going on. Windows protects you from knowing what the hell you are doing by restricting you to do only what their focus groups tell them. Have you ever actually worked out what was happening when something broke on Windows? Or did you just give up and abandon that functionality, and blame it on Microsoft? Microsoft, in their incompetence, provide a great scapegoat for Windows developers. If they had to use an Open Source system, this excuse would become fairly hollow...

Anyway, when you have a problem on Unix you don't ever reach some inscrutable, impenetrable barrier. You can look at what every component does, and if required, dive into the source and fix it. There are no artificial limits. The fact that anyone can look at the source means that people are less inclined to publish crappy code... And this effect increases with time.

To your "advantages":

DFS - please. This is a dodgy hack of SMB - it is not "distributed" in any real sense. OpenAFS is about as good as gets there, maybe Coda when it gets stable...

User administration: Huh? Can your helpdesk staff not learn a web front end to do this? Its not very hard to find one.... eg webmin, linuxconf. And this kind of thing is easy to customise - ie force your staff to put the required info..

and frankly it will always be easier
As soon as someone uses the word "frankly", it means "I'm going to say something completely unsupported and expect you to believe it."

Comparing windows to unix is like comparing a swiss pen knife to a fully equipped machine shop, with almost every tool available to you to use. Except you can fit it in your pocket....

Why don't we use more available code? Leaky abstractions for one. And look at the DLL and .so hell we're in now, where we have libraries that depend on libraries which depend on libraries...yik...all that to save a tiny bit of work, ain't worth it. Write your own.

Joel Spolsky had a similar thought on Monday about using VMWare to run webservers in a virtual machine, and to always have similar virtual machines ready, in case the server is hacked etc. (See his June 2, 2003 entry)

And here's a fixed link for the entire article:

(Cross-posted -- sorry)

Joel writes, "Microsoft has settled the lawsuit with AOL, agreeing to pay AOL $750,000,000 in a complicated deal that allows AOL to continue to use Internet Explorer for several years. I'm not sure why the second part is interesting."

In light of the recent news that "IE6 SP1 is the final standalone installation", I think this could be an interesting way of lulling AOL into complacency.

Let's say that the rumors are true, and IE development is at a standstill. What's to prevent Microsoft from putting a ton of resources into the MSN browser and zooming past a totally unprepared AOL?

This would leave AOL with some poor options:
* stick with the vanilla IE6, long surpassed by a superior MSN, or
* get Mozilla/Netscape/Phoenix/Firebird to the point where it could be comfortably used by existing AOL users

Thoughts?

It's notoriously difficult to read other people's code. It would take more programmers to fix a project than it took to write it in the first place. Shouldn't there be a "Clean Code" peering/mentoring group instead, or a "Clean Code" review body? I'd be much more confident if someone was keeping up with the code as it was written, and going back to the programmers before the program ships, asking "What exactly does this do for the program?", or "You do realize that you should decrement this length counter before you use it, right?". And even that pales in comparison to training all the project managers/project analysts to do this with their own teams' code.

I mean, really. A "Clean Code" group is good and all, but it's not a very efficient or effective way to make new products hassle-free, and it certainly doesn't resolve the problems caused by frequent patching. Plus, knowing the scale of large corporations (read: NOT just MSFT), the "Clean Code" group will probably be in the Canadian wilderness, hundreds of miles from the application developers. Be prepared for bogus patches that break more than they fix. I do suppose, though, since Microsoft will never rewrite code from scratch, this is the only way to get older projects up to speed.

Here's hoping the "Clean Code" group at least includes some of the original developers, to move things along. Windows is so incredibly bloated that I doubt we'll see them finish debugging it inside this decade. I guess that's Open Source's biggest strength -- anybody can be a "Clean Code" reviewer, and you don't need an NDA or a fancy degree to do it. You don't even need to ask for permission!

Jasin Natael

What you suggest would be the end of Windows (maybe not a bad thing). An ex-Microsoftie says it well here: Why you should never rewrite from scratch.

Joel Spolsky was theorizing about Sun in what he calls Strategy Letter V. (See the bottom for the paragraphs about Sun.) He wondered why Sun wants Java, and he was not able to guess.

Here is a theory: Sun wants its own software to be secure and fast. However, there is a conflict of interest. Sun makes more money if its customer's software is easily de-compiled. If Sun sales people find one customer doing particularly well, it is easy for Sun's other customers to de-compile the original customer's Java code and re-write it to work for their own purposes. This would benefit Sun because the salesmen could more readily sell the hardware that runs the Java program. Slow and easily decompiled makes more money for Sun.

Did I make enough jokes in my parent comment about Java being slow? They should rename Java and call it InsultMe. Most of the time when I see a Java program, it is so slow and the GUI is so quirky that I feel insulted that someone expects me to think it is acceptable.

The Law of Leaky Abstractions.

As we abstract more, we lose touch with the lower layers. As more abstractions are introduced, new classes of bugs are also introduced.

So while it is easier to optimize software architecture and see other "high level" system design bugs, more "low level" bugs will creep in from this abstraction.

When programmers say that their code is a holy mess (as they always do), there are three kinds of things that are wrong with it.

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.

A second reason programmers think that their code is a mess is that it is inefficient. The rendering code in Netscape was rumored to be slow. But this only affects a small part of the project, which you can optimize or even rewrite. You don't have to rewrite the whole thing. When optimizing for speed, 1% of the work gets you 99% of the bang.

Third, the code may be doggone ugly. One project I worked on actually had a data type called a FuckedString. Another project had started out using the convention of starting member variables with an underscore, but later switched to the more standard "m_". So half the functions started with "_" and half with "m_", which looked ugly. Frankly, this is the kind of thing you solve in five minutes with a macro in Emacs, not by starting from scratch.

It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don't even have the same programming team that worked on version one, so you don't actually have "more experience". You're just going to make most of the old mistakes again, and introduce some new problems that weren't in the original version.

Point one: rewriting from scratch can be a strategic disaster.

Point two: rectifying a "flawed" code base can be done within the framework of good software engineering practice, and is a very marketable skill besides.

Point one: rewriting from scratch can be a strategic disaster.

Point two: rectifying a "flawed" code base can be done within the framework of good software engineering practice, and is a very marketable skill besides.

In EJB there are many many things that can go wrong during deployment of beans ... It seems to take a while to debug.

EJB development doesn't have to be that way. I agree, without the right tools, EJB development can be a painfully laborious exercise in bitter profanity - and that's just the "hello world" EJB.

There's generally two reasons for this - firstly, there's a lot of classes to create (and more importantly maintain). This is where XDoclet comes into its own. XDoclet is a real labour-saver and I recommend every EJB developer add this tool to their bag of tricks.

The second thing that can be painful about the EJB development process is that the edit-compile-test loop can be maddeningly slow. To run your application you generally need to set up an EJB container, configure it and then ou have to package the app in an EAR and then deploy your app to the container and... you get the idea. Some vendors have integrated EJB containers with their IDEs, but they still run at the speed of diseased livestock.

There's a couple of solutons to this - the free solution is to run JBoss and deploy your app to it (JBoss's hot deploy feature is nice for this sort of thing). I am one of the developers working on a better, albeit - commercial (but fairly inexpensive) - solution, Glider. The key thing about Glider is that it has an EJB container simulator so there's no separate deployment step, so you can compile and run/debug your code very quickly. Obviously, I'm biased, but I can honestly say I would use it even if I wasn't one of the developers who has worked on it.

Rob

The open source community didn't produce Bob or Security holes for e-mail viruses. Microsoft has copied or bought everything in sight. Yup, they wrote the code, but IE was a response to Mosaic/Netscape. IIS was an attempt to beat NCSA's httpd. Excel was a Lotus killer. C# was an attempt to create a Java that Sun didn't control. Windows was a response to the Mac GUI. DOS, they just bought. BASIC was invented at Dartmouth.

Microsoft has made some great products and some real dogs. But innovation is not their strong suit as a company. They are in the business of creating mass-market software. You don't get innovative with fast food.

On a related note, from Joel on Software is The Guerrilla Guide to Interviewing.

On a related note, from Joel on Software is The Guerrilla Guide to Interviewing.

At the last company I worked for I was mostly in charge of hiring developers. I used Joel's interview technique very effectively to locate smart people who Get Things Done. This has several sections, one of which is a wild question like "How many trucks does it take to move Mt Fuji".

Unfortunately it was disappointing how few people did well in the interview. I forget the exact numbers of course, but I must have looked at 500 CVs in my time there, interviewed perhaps 30 people, and hired 2.

Another great technique we found was to install a computer with Linux on it in the interview room, and prepare a bunch of tests. Example: create a directory full of filenames in UPPERCASE and ask the candidate to use "any tools available" to convert the names to lowercase. We had the screen projected up on the wall of the interview room so everyone could see, and we gave the candidates no help.

The first thing you notice is: this guy doesn't know Linux. At least 50% of the candidates didn't know about "ls" and "cd"! (These are people who claim Linux on their CVs, interviewing for a job which requires Linux on their desktop).

The second thing you notice is the difference between the top 1% whom we hired and the bottom 75% is something like 20 to 1 differential in their knowledge.

It was an eye-opener. I now no longer trust pimps^Wrecruitment consultants as far as I can throw them.

Rich.

it's always spoken of in awe, but it's actually one of the big mistakes a software developer can make

Let me get this straight, you're going FROM offices TO cubes?

Time to add your company to fuckedcompany.com, methinks. Put a 'SELL' on that those shares, too. Eek. My condolences on your upcoming loss of peace of mind.

A previous poster mentioned a ban on speakerphones, which is a great idea, but doesn't go far enough. Separate out the people who use the phones a lot (project managers, sales, etc.), and move them far, far away, otherwise you'll hear their ringing phones and phone conversations all day long. "Joel on Software" has a lot of strange ideas, but his essay on this topic is spot-on in my experience. Check it out here .

Make sure your new spiffy partitions are very high - as high as possible.

Make sure the ceiling absorbs sound. Dropped ceilings suck, but they do absorb more sound than the trendy 'industrial' bare concrete ceiling look.

Overhead lights - kill them. I had to get out the ladder and remove the fluourescent tubes multiple times before maintenance understood this point. $10 torchiere lamps from Ikea make for much better lighting.

If you want to try to avoid the asking for help syndrome, check out the software at AskMe.com - an interesting idea, though I've not used it. If not this, set up some type of knowledge base intranet.

Make sure people's phones can be set to "do not disturb".

If people listen to music at work, make them use headphones.

Look for a new job is probably my best advice. :)

Joel Spolsky once said:

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

Here's the kicker: Google figured out the "20%"! My God, can you think of anyone else who acheived this?

Actually, they do - they decide it's not worth trying to fix the problems that exist and that an entire new codebase would magically be bugfree. They are almost invariably wrong. Take a look at this for someone who's written this up far better than I could.

I'm currently in the middle of rewriting a server app from scratch, and I hate it, because I'm spending two weeks implementing the stuff I already implemented once. Unfortunately I need to rip it apart almost entirely because the original one was a hack that got out of control and is utterly unmaintainable.

I'm probably making a mistake also, though.

However, I'd venture to say that there are C shops out there who will still hire you (if you want to work in a *nix shop that may be different, it sounds like you've been doing that nasty Windows stuff ;) You can always do like I did to get my first dev gigs: Lie.

Maybe Joel will hire you :) Here's a link to his site with an extremely insightful article on this subject.

You're right though, the nerds on high think that I'm a doofus because I like using VB, but the reason I like it is because I can get things done quickly when people need them.

I tried out Eclipse 2.0, although it seemed to have a number of good features, on the whole I found the user interface very clunky and confusing to use (as well as a bit slow). It certainly didn't make me want to swap from Emacs and ant.

Open a new 'Perspective', change your 'View', select an 'Implementor', navigate 'Resources'. Sure these concepts may be useful ideas for people wanting to add new components to the Eclipse platform but why should you need to understand these terms to use the software itself?

It feels Eclipse was designed by a group of architecture astronauts) with the target audience being developers who will extend the platform more than the actual end users themselves.

Personally, I don't like having the mail client integrated with the browser. I don't want HTML mail support (reading or composition). I certainly don't want any scripting support. I don't want a newsreader built in (I use pan/nget for that). I want smarter filtering capabilities, or no filtering capabilities and lastly I don't want any of the offline reading support. I'm not even sure I want the address book.


In fact, you don't really want the computer. You'd rather chip messages on stone and have a messenger slap on his sandles and run the slabs to the recipient.

You're kidding, right? Personally, I like to have the HTML reading capability (combined with the option to not receive the images, thereby foiling some spammers), and while I don't use the address book that much, the autofill on the address line is indispensable.

But I have to agree with an earlier poster: a rewrite is the WORST possible approach. If they meant "refactor", then I whole-heartedly support the move. Modularization would certainly be appreciated. But read , which directly mentions Netscape, to see why a rewrite would be a Bad Thing.

My boss recently came to me with the idea that we could "rewrite" the application to do X, Y, and maybe even Z. I showed him that article and then sent him an email with a project plan that had us implementing X, Y, Z, and the other 23 letters of the alphabet in a timely manner with a minimum of stress. And y'know what? He was ok with that.

From Painless Bug Tracking:

"""
It's pretty easy to remember the rule for a good bug report. Every good bug report needs exactly three things.

1. Steps to reproduce,
2. What you expected to see, and
3. What you saw instead.

Seems easy, right? Maybe not. As a programmer, people regularly assign me bugs where they left out one piece or another.
"""

I think the root of that difficulty comes from using XML to solve two different problems. One problem is data transmission between systems- which XML was designed for, and handles adequately. When recieving a data chunk from an external source who might not be trustworthy, a safety-concious program really has to read the whole thing and verify it complies with the format. Skipping over some sections to reach the part you're interested in isn't allowed.

But, for data storage within an application (or a set of tightly coupled systems that trust each other to function correctly), XML is less advisable. Traditional (SQL) databases, or hand-rolled file formats, may be a better solution when high speed and scalability are needed.

JoelOnSoftware has an long article on why XML is suboptimal for the latter use.

I'm not that old, but I remember the days (almost 10 summers gone) before there was "one office suite to rule them all and in the darkness bind them". My first spreadsheet was Lotus 123 2 (DOS). Excel, up to 97 at least, has "help for Lotus 1-2-3" and you can even set it to recognise 123's / commands (Tools|transition). One of the Excel programmers, Joel Spolsky, wrote about "barriers to entry" when trying to overtake an entrenched application (which for Excel was 123). These inluded:

• They have to convert their existing spreadsheets: Give Excel the capability to read 123 spreadsheets
• They have to rewrite their keyboard macros: Give Excel the capability to run 123 macros
• They have to learn a new user interface: Give Excel the ability to understand Lotus keystrokes

The blind panic that strikes many now at the very idea of using anything else is a bit disconcerting (a couple of years ago when my boss sent "ILOVEYOU" around the company we had a meeting about viruses, my suggestion to just give up Outlook becasue it was chronically insecure almost got me burned at the stake).

HERE is what a guy who worked for microsoft has to say about the passport login system hotmail and other MS and partner sites use.

Probably why most people balk at having to create accounts and login to these sites.

Like the Tyranny of Email article, Getting Things Done When You're Only a Grunt also suggests that there's a significant productivity boost to be gained from shutting off your email client.

Human Task Switches Considered Harmful and Where do These People Get Their (Unoriginal) Ideas? have more on this topic.

Joel's archives have quite a number of interesting articles.

Like the Tyranny of Email article, Getting Things Done When You're Only a Grunt also suggests that there's a significant productivity boost to be gained from shutting off your email client.

Human Task Switches Considered Harmful and Where do These People Get Their (Unoriginal) Ideas? have more on this topic.

Joel's archives have quite a number of interesting articles.

Like the Tyranny of Email article, Getting Things Done When You're Only a Grunt also suggests that there's a significant productivity boost to be gained from shutting off your email client.

Human Task Switches Considered Harmful and Where do These People Get Their (Unoriginal) Ideas? have more on this topic.

Joel's archives have quite a number of interesting articles.

Like the Tyranny of Email article, Getting Things Done When You're Only a Grunt also suggests that there's a significant productivity boost to be gained from shutting off your email client.

Human Task Switches Considered Harmful and Where do These People Get Their (Unoriginal) Ideas? have more on this topic.

Joel's archives have quite a number of interesting articles.