Slashdot Mirror

Yeah, I have yet to see a system that worked better than the following (find your own open source equivalents if that's truely a requirement):

• Word docs / HTML pages for the requirements and specifications.
• Excel for workitem lists. Enter the data correctly and pivot tables, etc. become very handy.
• SharePoint for managing the above on an intranet.
• Good bug tracking software. For some projects we've imported workitems into the database, especially the unfinished or postponed ones. The bug database should allow you run queries so items for the next release can be filtered out in your daily usage.

Of course, don't forget to implement a good version control system, checkin procedures, daily builds, yadda yadda. Read Rapid Development by Steve McConnell for some good info. This site also has some practical articles and recommendations.

Oh, and above all, this needs to be as transparent and easy to use as possible, otherwise you put an unnecessary burden on your development team.

Note: I'm not a Mac guy.

Often people feel that systems different than what they are used to are "pieces of shit". Joel On Software has a very good article regarding this.

MSFT used to be good on marketing platforms. What happened to them?

Um, no. It would mean that your "state-o-the-art" PowerBook wouldn't run the previous version of the OS.

Clearly your sarcasm detector is set too high. When I said "the one you just bought" that means today (as in just, as in not 64 bit). So when Steve Jobs gets up and says "32 bits is dead" your screwed. Just ask all the people who bought quadras so they would be able to run OS X. Then it didn't appear for a few years and ... yes, they got "Steved".

Doubtful, if a 1GHz GPUL processor runs 2x faster than a 1GHz G4 processor

Clearly you have a short memory. The "emulated" 68k mode of PowerPCs (which were also supposed to be waaay faster) weren't because the emulator didn't fit in the cache. And for christ sakes, who the hell believes what chip companies say about speed anymore?

Yea, right. Since Apple has done such a poor job of allowing old apps to continue to function with a new their new OS, NOT!

I hope your fucking kidding. Clearly your not a Mac developer if you haven't been repeatedly screwed by Apple.

Go back to sleep, you clearly need it

So what's your excuse?

I might have missed it on there, but there appears to be no clear way to sign up: If, at that very instant, I was prepared to pay $36 or whatever for a year, then you would have lost that sale (for the record I did take a peek at what sorts of payments you would accept, but couldn't see any method whatsoever).

On the flip side, the biggest reason, by a long way, why I am very wary of using a ASP type service for email is longevity: If I'm going to send out email addresses, or put them on business cards, or use it for mailing lists, etc, I have to know that it will be there for a long, long time: I've played the email shuffle between too many different companies for far too long. As a prospective user of Gravital, I naturally wonder "Is this is just a hobby that'll soon become boring?" etc. Take a look at Joel's article to get a better picture of what I mean by the cost of change.

With a developer base in the hundreds of active people, there is little need for automated builds.

DO NOT make them solve brain-teasers on the spot, regardless of what joelonsoftware.com might say.

Huh? While Joel has a site with brain teasers (techinterview.org), he discourages using them.

From Joel's Guerilla Guide to Interviewing:

Finally, avoid brain teaser questions like the one where you have to arrange 6 equal length matches to make exactly 4 identical perfect triangles. If it's an "aha!" question, you don't get any information about "smart/get things done" by figuring out if they happen to make the mental leap or not.

I found this a worthy enough read to bookmark it. The author has some good ideas about preparing for an interview and formulating a meaningful evaluation of that individual's skills beyond the basic text-book Q/A dialogue. http://www.joelonsoftware.com/articles/fog00000000 73.html

I think this is a great article - The Guerilla Guide and I encourage anyone who is unsure to read it. You don't have to take all his advice to heart but at least it might give you some new ways to look at the interview opportunity.

Joel Spolsky seems to have a bit to say about this. Try his Guerilla Guide to Interviewing. Of course, not everyone agrees with everything he says, but, in my opinion, he has quite a few insightful points.

You can go here to find all the articles related to growing a software team.

Hope that helps.

Joel Spolsky seems to have a bit to say about this. Try his Guerilla Guide to Interviewing. Of course, not everyone agrees with everything he says, but, in my opinion, he has quite a few insightful points.

You can go here to find all the articles related to growing a software team.

Hope that helps.

1. Why do you want this job?
2. What single accomplishment of yours are you most proud of?

-Renard

I tend to agree with Joel on Software in the Guerilla Guide to Interviewing. The whole goal of your interview process is to determine if the candidate is (1) smart and (2) gets things done. There are a lot of other good tips on that site in various articles. The bottom line is to have them design something so you can see how they think. You're trying to decide if they're smart and get things done. You also want to see if they would fit in with your team (personality). At the end of the interview, if you're not 100% confident it's a HIRE then it's NO HIRE.

I tend to agree with Joel on Software in the Guerilla Guide to Interviewing. The whole goal of your interview process is to determine if the candidate is (1) smart and (2) gets things done. There are a lot of other good tips on that site in various articles. The bottom line is to have them design something so you can see how they think. You're trying to decide if they're smart and get things done. You also want to see if they would fit in with your team (personality). At the end of the interview, if you're not 100% confident it's a HIRE then it's NO HIRE.

Joel (of Joel on Software fame) has an interesting article about interviewing, entitled The Guerrilla Guide to Interviewing. The name is self-explanatory, I guess.

Joel (of Joel on Software fame) has an interesting article about interviewing, entitled The Guerrilla Guide to Interviewing. The name is self-explanatory, I guess.

Free software's dependence upon Microsoft's fonts?

Sorry to be dense, but what dependance is that? My laptop is running a pretty stock RH 7.2 with no MS fonts and seems to work fine. So where's the dependence?

I seem to be missing the point of the furor. Of course, I also think anti-aliasing is a dumb idea, so I seem to be in the minority here when it comes to font issues...

This guy has a lot to say about writing software, managing developers, and running a small business. While I haven't seen his results firsthand, I'd be surprised if you found a way to better them.

We've all heard rumblings about age bias in programming--they'd often rather underpay an desperate, overcaffeinated twenty-year-old than have to listen to that old cuss who can explain why the project is doomed. As a colleague (hi Dan!) put it, the two career paths for a programmer are

1. graybeard
2. management

You can stay focused on coding if you're the local guru who knows the systems inside and out (in fact they might be afraid to try to go on without you), but there's always the risk your expertise will suddenly be obsolete, and many companies don't even realize how much they needed one until they get rid of them.

At 31, I'm slowly picking up project management (mostly by choosing jobs likely to let me do some, and reading), because it's easier to sell (nobody sane thinks they don't need it) and age mostly improves credibility. And somebody's got to oppose the industry's gratuitous complexity (or "cover fire", as Joel Spolsky puts it) in favor of the simplest thing that works.

Not only is "the Zone" quite real in programming, one of the most importent aspects of being a great programmer is being able to acheive this state with reasonable reliability. (Nobody can do it all the time.) In fact, smart managers use that to their advantage when figuring out how to organize and manage their programmers.

IMHO, it's nothing mystical, and treating it as such as some people do, while possibly fun, is counterproductive in the end. You can't guarentee entrance, but there are definate concrete steps you can take to get there.

Whoever the project manager is should have recognized different skill sets or motivations very early on and pursued actions to rectify it. While about 90% of the postings to this thread have been "Boohoo, I'm out of work so fire them all!", the reality is that no business sustains with a "fire them all" mentality (which is why those posts are all by people working for someone else), and the reality is that almost every talented employee has periods of low productivity, sometimes lasting for months. Again, these are just basics of human nature that one has to recognize and plan around.

The reality is that people are motivated by varying things (and "fear of being fired" is the #1 worst motivator and is the cyclical spiral to oblivion for any organization), and a good project manager understands how to understand and utilize those motivations (and it very seldomly is $, by the way): The biggest ___KILLER___ to motivation (and it's a killer in the sense that people will write garbage code, if any at all, regardless of their skillz) is a project death march: A project that has no hope in hell of ever being finished, and is absolutely guaranteed to be killed. Any talented coder will have a brain gnawing at them screaming "THIS IS A WASTE OF TIME!", and the truth of the mater is that in the end, sitting around reading Slashdot all day, or dutifully spitting out lines of code, has the same net result: The project is canned and the code is deleted. There are many projects out there like this, pursued by managers with agendas and severe myopia: If your project is like this then good for you, but realize that it won't be long before you too spend your days wishing for 5pm to hit.

One of interview methods that makes the most sense to me is described in the The Guerrilla Guide to Interviewing.

Interviews should determine two things: whether a person can do the job, and whether they will do the job. Riddles don't really figure into either of those.

--Bruce

Joel explains how Microsoft has crushed Lotus in here

Joel on Software
Many texts to read, some of them really insightful

Devshed
Many tutorials, focus on scripting languages

Grrr. And of course, someone later on points to a blurb that describes SLM:

Joel on Software

If you think Visual SourceSafe is bad...

I had a contract project, a porting job. The platforms were Win32 (where it originated) UNIX/Linux (our port), Novell, and OS/2. We had the command line version because the Linux GUI core dumped every 5 seconds. But the command line version stull sucked, and of course didn't know shit about line endings. We could script it with some extension mapping to try to do dos2unix/unix2dos, but good luck, cause the command line version wouldn't have any useful exit() values. I have no idea what the Novell and OS/2 guys did.

Joel Spolsky (he's been on here before) wrote about sucky SourceSafe a bit and how Microsoft really doesn't use it. Doens't give me a lot of confidence using it. He also had the link to the UseNix verion of the talk given in the story.

The primary issue is that open sourcing previously closed source applications is not something the company can do for free. There's a ton of legal issues that must be considered (use of third party code, etc, etc) before a release can be made, that costs time and it costs a lot of money in most cases.

Then you hit secondary issues like shareholder reaction to the company not only giving its products away for free to whoever wants them, but also giving source code and thus some perceived competitive help (even if its not true) to the company's competitors.

All in all, there are a lot of headaches involved. Its not something most companies will do unless there's some direct market benefit for them, ala commoditizing a compliment (see here).

Have a read on that and some other articles in the archive. I am sure you it will help you put your thoughts in some order. You can then give it a try (diplomatic one) and move the waters a bit.

Just my $0.01

Have a read on that and some other articles in the archive. I am sure you it will help you put your thoughts in some order. You can then give it a try (diplomatic one) and move the waters a bit.

Just my $0.01

You've seen the hundreds of people gawking at anti-aliased desktops, it just looks cooler.

Blurry fonts are not better. Anti-aliasing is a bad way to compensate for poor font design. Don't blur your desktop; choose fonts that work well when rendered as pixels.

Using Mozilla as the basis for their browser is the best decision they could make for their long-term success.

Sure there might be some short-term pain involved, although I rarely see sites that don't work with Mozilla, and nor does my wife who browses more sites and isn't an internet guru.

"Geez, Mom. If you really don't like using F6, just change the code and do the 5-hour recompile. Stop your complaining."

Actually, it's not too hard. It doesn't involve recompiling, it just involves adding a few lines to your user.js file. Maybe in the future they'll add a nice GUI for your mom to use.

My point wasn't that your mom should change the code, but that someone who is capable of such a thing should do so when they want a particular feature and contribute it to the project. And the author of this article is a software developer. But I know he was just trying to make a point, it just wasn't a good example.

Hear hear. anybody who's had to write code for any length of time learns to develop it in their head in spare time. I can't believe the bozos who whine about lack of an IDE (how about four VI terminals?? Stupid punks) and expect a compiler to do all the syntax checking.. too lazy to learn proper grammar? Go build a house. Fscking morons. As you say, development time is considerably less than one would expect from a group of lazy-ass idiot children who can't be bothered to code properly.
I pity the employers of these people who don't think breathe and love code. As Joel says,
At the other extreme, are the brilliant superstars who write lisp compilers for fun, in a weekend, in Assembler for the Palm Pilot. And in the middle, you have a large number of "maybes" who seem like they might just be able to contribute something. The trick is telling the difference between the superstars and the maybes, because at Fog Creek Software we only hire the superstars.

And, just to be totally random, have you found that your Talmudic studies have made you, as a person interfacing with other people, more easy to use, powerful, and fault-tolerant?

One of the cardinal (ahem) rules of Talmud study is you have to pay attention to the exact meaning of every word. A good study partner won't let you say, "Well, I think this sentence means X, so let's move on" -- the partner will say, "How do you know? How does this prefix on this word here fit your interpretation?" Since the Talmud is written in a fifteen-hundred-year-old language, without vowels or punctuation, the beginning/intermediate student (like me) has to make a lot of effort to just get the plain meaning of the text.

Now, as it turns out, this skill is very helpful when you're reading someone else's code, particularly code written in the "Real Programmers can write FORTRAN in any language" style -- because the computer will pay attention to every (uncommented, non-dead-code) word in the program, and if you gloss over the meaning of some line that the computer interprets differently, you're in for a world o' hurt. I wrote a little more on this subject here. (N.B.: I'm not Joel, he just posted an email from me.)

I think it works the other way, too: among geeks with some knowledge of formal logic and logical terminology, some Talmudic discussions become much easier. Sometimes it's a helluva lot more concise to translate a Talmudic sentence into algebra or pseudocode than into English.

OK, here's my question for Moshe: Can you recommend a "Geek's Guide to Talmud Study?" (If not, can you write one? :-)

Even though this will probably get lost in the shuffle, I'd like to add some background on toolbars.

According to Joel Spolsky, toolbars were invented by Microsoft with the release of Excel 3.0 in 1990. Here's a link to his claim. Now, he worked on the Excel team at that time, so I take his claim with a grain of salt.

The "toolbar" that Joel is referring to has two parts: The File/Edit/View (etc.) bar at the top of the program; and the New icon/Open icon/Save icon set below it. This became the de facto standard for most Windows applications, and also a standard feature with most development kits.

I would imagine that many other people can claim to remember a "toolbar" from other types of systems, but I would also imagine that the one in Excel 3.0 looks most like the ones we still use today. If Joel's claim holds up, it appears that Microsoft has been innovative at least once. ;)

Even though this will probably get lost in the shuffle, I'd like to add some background on toolbars.

According to Joel Spolsky, toolbars were invented by Microsoft with the release of Excel 3.0 in 1990. Here's a link to his claim. Now, he worked on the Excel team at that time, so I take his claim with a grain of salt.

The "toolbar" that Joel is referring to has two parts: The File/Edit/View (etc.) bar at the top of the program; and the New icon/Open icon/Save icon set below it. This became the de facto standard for most Windows applications, and also a standard feature with most development kits.

I would imagine that many other people can claim to remember a "toolbar" from other types of systems, but I would also imagine that the one in Excel 3.0 looks most like the ones we still use today. If Joel's claim holds up, it appears that Microsoft has been innovative at least once. ;)

I was curious as to how many people our email request was scaring away. So (sneaky Joel) we changed the demo signup so that 50% of the guinea pigs, er, potential customers had to provide an email address and 50% didn't.

Result: about half of the people gave up when asked to type in an email address. We want people to try the demo, so we changed it to never ask for an email address."

You mean like not hyperlinking your URL's ?
http://www.joelonsoftware.com Preach for water and drink wine ...

...we have the answer to Joel's question.

What's that sound? Ah yes - Joel Spolsky spinning in his, erm, website.

CityDesk

Over the course of my employment--about three years now--I've rewritten over four applications from scratch... and it's the best thing that could have ever happened to the code. ... you're writing a piece of software the second time around, you know what mistakes you made the first time, and can avoid them.

How common is it for the ORIGINAL developers to be the people doing the code rewrite? Rewrites are usually done because the new developers cannot understand how the original code works. Were the four applications you rewrote your code or someone else's code? If you cannot extend your own code without rewriting it from scratch, then you need to learn about information hiding.

Yes, Netscape 4 had many bugs. However, Mozilla also has many bugs. Why do you think it has taken THREE years to release a stable version? Here's a quote from Lou Montulli, one of the founding engineers of Netscape and the creator of Lynx responding to Joel Spolsky's "Things You Should Never Do, Part I" article. Lou says,

"I agree completely, it's one of the major reasons I resigned from Netscape. In 1998, after wasting a year wanking, a group of new but experienced programmers, and one of our misguided founders, decided it was a good idea to rewrite everything. I had alot of vested interest since I had done most of the original design work on Navigator, but I was unable to supply enough visions of doom to divert the effort. The original design had degenerated substantially due to the integration of Java and the rapid pace of zig zag development that went on over the course of 4 years. There was good reason for a large change, but rewriting everything was a bit overboard to say the least. 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."

Mozilla will be a great product eventually, but unfortunately I agree with Joel Spolsky that good software takes ten years to write, and you should NEVER rewrite code from scratch.

I know that as a software developer, I've certainly learned from Netscape's mistake.

Mozilla will be a great product eventually, but unfortunately I agree with Joel Spolsky that good software takes ten years to write, and you should NEVER rewrite code from scratch.

I know that as a software developer, I've certainly learned from Netscape's mistake.

Mozilla will be a great product eventually, but unfortunately I agree with Joel Spolsky that good software takes ten years to write, and you should NEVER rewrite code from scratch.

I know that as a software developer, I've certainly learned from Netscape's mistake.

On the other hand, Joel's in favor of refactoring, which is certainly an option with Perl 6.

Respectfully, No. In fact, a resounding "No."

Existing, running, production code is mature code, by and large. It works, it's had revisions, people have added little bug fixes here and there, and at very worst it has passed the "live QA department's" BFT. Many eyeballs have seen it. And it's harder to read code, even well-commented code than it is to make new code (that old "easier to plant a garden than take care of a garden" analogy fits in here, I think). So translating existing stuff into new code will probably introduce errors.

I found a good article about Netscape 6 which touches on why rewriting code is usually a bad idea. The article says it better than I can. I especially liked the comments from Lou Montulli (creator of Lynx) about the rewrite which took place for Netscape 6:

There was good reason for a large change, but rewriting everything was a bit overboard to say the least. 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.

Of course, there are times a rewrite is needed. But to decide to do rewrite purely because there are new constructs of a new language (which is essentially what Perl 6 is going to be) seems like a real good way to introduce bugs, not find them. Finding bugs is what good design and QA is for...

-B

Respectfully, No. In fact, a resounding "No."

Existing, running, production code is mature code, by and large. It works, it's had revisions, people have added little bug fixes here and there, and at very worst it has passed the "live QA department's" BFT. Many eyeballs have seen it. And it's harder to read code, even well-commented code than it is to make new code (that old "easier to plant a garden than take care of a garden" analogy fits in here, I think). So translating existing stuff into new code will probably introduce errors.

I found a good article about Netscape 6 which touches on why rewriting code is usually a bad idea. The article says it better than I can. I especially liked the comments from Lou Montulli (creator of Lynx) about the rewrite which took place for Netscape 6:

There was good reason for a large change, but rewriting everything was a bit overboard to say the least. 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.

Of course, there are times a rewrite is needed. But to decide to do rewrite purely because there are new constructs of a new language (which is essentially what Perl 6 is going to be) seems like a real good way to introduce bugs, not find them. Finding bugs is what good design and QA is for...

-B

The interview is with Joel Spolsky, a former project manager on Excel. His argument is that rewriting something from scratch is not only uneconomical, but dangerous because it eliminates the collective knowledge built into the code through bugfixes and such.

Spolsky does, however, favor extensive refactoring when time and money are available--he's not saying that you shouldn't fix old code, only that refactoring is pretty much always preferable to a clean sheet rewrite.

It strikes me as ironic that the Slashdot crowd complains about feature bloat on PC software, all the while extolling the virtues of having a gazillion switches for a single command line program.

I'm aware that I've just made a vague, sweeping generalization about just who would complain about Windows bloatware, and that I'm being slightly inflammatory. But bear with me.

My point is that both complaints really amount to criticizing the other side's mental model of How Software Should Work. Bloatware on the one hand, and having a gazillion command line switches on the other, are software developers' different approches to dealing with the same issue: meeting the needs of the user. It's just that the user they have in mind has a different profile in terms of how they expect computers should work. Strange that I should ever agree with Spolsky 100% on this.

So I stand by my characterization of the "by geeks for geeks". Switch that phrase to "by lusers for lusers", and hey presto, you're criticizing Windblows.

And that's the problem I have with this vague non-declared goal of OSS taking over the desktkop, and it's why I think losing NAI PGP is such a big deal.

You -- the Slashdot crowd "you", not the "einhverfr" you -- extol the virtues of "anyone" being able to put together a front end on top of the actual encrypt/decrypt model. Well, that's not what Joe in accounting is willing or able to do. You -- again, the Slashdot crowd "you" -- talk about the importance of encryption evangelization. Well, Joe in accounting thinks it's a pretty good idea, but can't for the life of him figure out what he needs to do to sign his Eudora-sent email in the first place.

In the end, I don't think at all that the UNIX mentality is broken, nor is Winblows' (well, not fundamentally broken, anyway).

I do think that there's a huge userbase demanding (in the economics sense) a package that will fill the gap caused by the loss of NAI PGP, or a non-MS product, or what have you.

It's just a question of whether those with the so-called UNIX mentality are willing to approach the problem from the other point of view. I'm cautiously optimistic.