Slashdot Mirror

I also like alot of the things Joel has to say. However, at no point in time would I term his product "remarkable". Given how much Joel talks about "great software", I'm a bit disappointed by FogBugz. Like I said, it's a good product, but hardly remarkable.

Again, just my two cents.

Grub has been the best bootloader, but unfortunately, it is fugly and has stagnated.

Apparently it has been undergoing an ill-advised complete rewrite for the last several years. Why couldn't they just have refactored?

Wouldn't it be nice to have a grub with nice graphics, a real menu system, and all the bug fixes from the last several years in one release? Might even be as cool as XOSL was 10 years ago. But instead we get nothin' but vapor. It's sad.

Joel Spolsky, in my humble opinion, has some excellent advice on software development culture, including some compelling arguments you might use. Here he lists the '12 steps to better code'. Arrange for you boss to read this:

http://www.joelonsoftware.com/articles/fog00000000 43.html

If that doesn't work, I would recommend reading his article 'getting things done when you're only a grunt' - basically, it says that you should just go ahead and set these things up for your own use, and then maybe even get others to start using them, and occasionaly show off your amazing documentation/source control/bug tracking system by retrieving the code the boss lost, or by producing the history of some bug or a report on bugs fixed this week.

http://www.joelonsoftware.com/articles/fog00000003 32.html

Personally I think that all of his 12 points are important and I work hard to establish these things when I start work on a new project (sometimes 'unofficially', but invariably 'unofficial' bug tracking/source control/... tools soon become official as nobody can actually live without them and remain highly productive). There are some things that I would add to his 12 points however (and this is getting slightly off topic from your discussion of bug tracking):

13. Dogmatically provide automated unit testing for all code, with as close to 100% coverage as possible; design code from the ground up to best tested
14. Always write self-documenting code (Javadoc for Java, doxygen for C++/PHP etc)
15. Use all available automated tools to improve code quality (code duplication detection, lint, valgrind/purify, ... you name it, if it works and especially if it's free, use it on your code, it will only get better)

Another excellent source of advice is the Pragmatic Programmer's book, From Journeyman to Master, which discusses the practice of programming (as opposed to programming itself) in detail.

Thomas

Joel Spolsky, in my humble opinion, has some excellent advice on software development culture, including some compelling arguments you might use. Here he lists the '12 steps to better code'. Arrange for you boss to read this:

http://www.joelonsoftware.com/articles/fog00000000 43.html

If that doesn't work, I would recommend reading his article 'getting things done when you're only a grunt' - basically, it says that you should just go ahead and set these things up for your own use, and then maybe even get others to start using them, and occasionaly show off your amazing documentation/source control/bug tracking system by retrieving the code the boss lost, or by producing the history of some bug or a report on bugs fixed this week.

http://www.joelonsoftware.com/articles/fog00000003 32.html

Personally I think that all of his 12 points are important and I work hard to establish these things when I start work on a new project (sometimes 'unofficially', but invariably 'unofficial' bug tracking/source control/... tools soon become official as nobody can actually live without them and remain highly productive). There are some things that I would add to his 12 points however (and this is getting slightly off topic from your discussion of bug tracking):

13. Dogmatically provide automated unit testing for all code, with as close to 100% coverage as possible; design code from the ground up to best tested
14. Always write self-documenting code (Javadoc for Java, doxygen for C++/PHP etc)
15. Use all available automated tools to improve code quality (code duplication detection, lint, valgrind/purify, ... you name it, if it works and especially if it's free, use it on your code, it will only get better)

Another excellent source of advice is the Pragmatic Programmer's book, From Journeyman to Master, which discusses the practice of programming (as opposed to programming itself) in detail.

Thomas

Great article on bug tracking here. Yes, he makes a bug tracker, but this article (and others on his site) goes into detail about *why* and *how*, not just "buy my product." Also good info here.

"If you are developing code, even on a team of one, without an organized database listing all known bugs in the code, you are going to ship low quality code. Lots of programmers think they can hold the bug list in their heads. Nonsense. I can't remember more than two or three bugs at a time, and the next morning, or in the rush of shipping, they are forgotten. You absolutely have to keep track of bugs formally."

Great article on bug tracking here. Yes, he makes a bug tracker, but this article (and others on his site) goes into detail about *why* and *how*, not just "buy my product." Also good info here.

"If you are developing code, even on a team of one, without an organized database listing all known bugs in the code, you are going to ship low quality code. Lots of programmers think they can hold the bug list in their heads. Nonsense. I can't remember more than two or three bugs at a time, and the next morning, or in the rush of shipping, they are forgotten. You absolutely have to keep track of bugs formally."

I think you misunderstood that comment (and didn't bother to read the links). The previous poster asked "Where is ALT OS for sale preinstalled that do NOT cost more then MS. Even if the OS is Linux that can be gotten for free?". I responded with "Just because other OSes aren't undercutting Microsoft and may understand economics more than you do doesn't mean it's Microsofts fault.", referring to the cost not market penetration. My implication was that if a computer manufacturer was going to offer a non-Microsoft OS because "it is better", then they should charge more because there's a cultural perception that you get what you pay for. If you offer a non-Microsoft OS because "it is free", then many people will assume it isn't as valuable as Windows. This is the idea behind price as a signal. This is probably culture senstive, so it might not apply to other countries.

Microsoft has long had a price tier structure for productivity software. They offer Works, Word, Office Standard, Office Professional, etc. Computer manufacturers offer several different choices for productivity software. Dell defaults to Word Perfect and the customer choses if they want to pay more to get Works or Office.

(As the article mentions) Microsoft has also started selling Windows Starter Edition in developing countries. Just because other OSes aren't undercutting Microsoft and may understand economics more than you do doesn't mean it's Microsofts fault.

Microsoft has long had a price tier structure for productivity software. They offer Works, Word, Office Standard, Office Professional, etc. Computer manufacturers offer several different choices for productivity software. Dell defaults to Word Perfect and the customer choses if they want to pay more to get Works or Office.

(As the article mentions) Microsoft has also started selling Windows Starter Edition in developing countries. Just because other OSes aren't undercutting Microsoft and may understand economics more than you do doesn't mean it's Microsofts fault.

This is my "Realtime Air Traffic Control: For People" working at vehicle resolution...
http://www.mindpixel.com/chris/2005/07/end-of-anon ymity-good-thing.html
http://discuss.joelonsoftware.com/default.asp?off. 9.250603.31

"So, imagine a Google Maps interface to all the public cameras in the world. Anyone can look through any camera at any time. That's phase I. Phase II: Universal Continuous Identification of all people in public space. Think air traffic control for people. Collision alert when known sex offender nears an unsupervised child?"

I often ask how well they score on The Joel Test: http://www.joelonsoftware.com/articles/fog00000000 43.html

At one interview, I heard that they have an "interesting source control system." That was a red flag.

A number of other people had good questions, so this is not everything I'd suggest; I just didn't see this on a quick perusal.

Ask about their development practices. The Joel Test is a good place to start, even if you don't agree with everything he says or all of his points. I definately make sure to ask about unit testing, for instance, without which you are wasting everybody's time, especially mine as a developer. If you're going to yell at me for that, I want to know up front.

To highlight the other things I consider a bare minimum: Source control is an absolute must, or again, you're going to have to pay me a lot more to deal with the stress. Bug databases of some kind are a must. In both of those cases, it is possible to deploy such things on your own initiative, as long as no-one is actively undercutting you. You'll also get a pretty good sense of what you're going into; if the answer is not just "no", but "why the hell would you want that?", then you're in trouble.

Of course, if you yourself don't use any of these things... well, uh, more power to you and, ah, good luck with that "programming" thing...

The good news is that this will tend to greatly impress anybody else who knows what you're talking about. I pretty much sealed my last two jobs with two little words, "unit test".

You do realize this is Microsoft we're talking about...the company that famously doesn't "get video games" and yet releases a video game system....err..home media center...err...online service whatchamacallit 360.

Combine this with "Music Television" that doesn't play music. Or, for that matter, "get" consumers. Teens watch it because every other teen is watching it. Thankfully years of public education has taught our future generations that they are what they own.

And multi-tiered pricing? That's what they labels are doing to have more power over artists. Check out: http://www.joelonsoftware.com/items/2005/11/18.htm l (Article is Titled "Price As A Signal").

It WILL be WMA.
It WILL be chock full of DRM goodness.
It WILL not have any music worth listening to for less the $.79 (realistically, maybe $.99 -- but something new and hot will be $2.00 because labels still think that everyone is a dumb as that idiot who spends $3.00 for a Green Day Ring Tone)
It WILL NOT have a good ease of use or conveinence factor.
it WILL NOT be compatible with existing devices (like the Xbox 360)
It WILL be bundled with Vista, and even after you install iTunes, BitTorrent, eDonkey, and Limewire (for all your music needs of course) it will still pester you ALL THE TIME to buy their crap.

The headline for this could be "Largest Software Monopoly and Largest Media Monopoly launch Doomed Venture, Destined to Profit."

As Joel said it : Incentive Pay Considered Harmful

Well, I'm always curious. So, I watched the video "Evolving your database schema without sweat". I watched for 10-15 minutes where the guy types furiously for 15 minutes to avoid typing "alter table add author varchar".

I guess I just don't get it. What's the excitement?

You can't abstract too far away from the database when you get into big, complex tables and want to keep performance up. I've seen a 30-second query reduced to 50 milliseconds merely by changing the order of join in a large, complex, 12-table join on PostgreSQL.

Yet, it seems that Ruby on Rails goes to great lengths to avoid (gasp!) SQL. See Joel's great article on leaky abstractions.

I don't mind SQL statements - prepared statements make it so much more manageable - but what about code changes dependent on changes to the database schema? That's something I might be interested in!

Using "FUCKING IDIOT" in caps on a mailing list is fairly childish behaviour

Perhaps, but his point is dead-on. He says the same thing as Joel's Bloatware and the 80/20 Myth.

http://www.joelonsoftware.com/uibook/chapters/fog0 000000057.html/ Spolsky would probably say both are crap - and I tend to agree.

"Five Jim Davis's -- creator of that unfunny cartoon cat, where 20% of the jokes are about how Monday sucks and the rest are about how much the cat likes lasagna (and those are the punchlines!) ... five Jim Davis's could spend the rest of their lives writing comedy and never, ever produce the Soup Nazi episode of Seinfeld." Link

Joel on Software posted a very useful book list, which extends more to the management of programming than to any specific language. This makes it more generally useful than yet another C book.

You might be interested in this for a different take on bloatware. Software requirements haven't gone up as quickly as hardware specs, at least as Joel proves through the power of anecdote. Those resources are there for a reason. It's not bad to use them.

Another issue is that Price sends a Signal.

Why do movie theatres have a static price instead of something that varies based on popularity? Because if the movie theatre tells you a movie's only worth $4.00 instead of the usual $10.00, they're letting you in on a secret. It's got Ben Afleck in it, and it's crap.

http://www.joelonsoftware.com/items/2005/11/18.htm l

Another issue is that Price sends a Signal.

Why do movie theatres have a static price instead of something that varies based on popularity? Because if the movie theatre tells you a movie's only worth $4.00 instead of the usual $10.00, they're letting you in on a secret. It's got Ben Afleck in it, and it's crap.

http://www.joelonsoftware.com/items/2005/11/18.htm l

Another issue is that Price sends a Signal. Why do movie theatres have a static price instead of something that varies based on popularity? Because if the movie theatre tells you a movie's only worth $4.00 instead of the usual $10.00, they're letting you in on a secret. It's got Ben Afleck in it, and it's crap. http://www.joelonsoftware.com/items/2005/11/18.htm l

[...] it's so easy to get knocked out of the zone. Noise, phone calls, going out for lunch, having to drive five minutes to Starbucks for coffee, and interruptions by coworkers--especially interruptions by coworkers--all knock you out of the zone.

Why because they have a balanced life? Why does software have to be "inspired," it just has to function. Zealots can spend too much time including nice-to-have features than accomplishing the main objectives on schedule. You don't need to think about computers 24/7 to do a good job.

This is a terrible comment. Please don't tar people who are good at their job and have a passion for what they do by calling them zealots. If I were interviewing you for a position at my company, and you said, "Why does software have to be 'inspired,' it just has to function," I would stop, kindly thank you for your time, and ask you to leave. An attitude like that means you're just phoning it in; that your life begins at 5; that you don't understand the passion driving the co-workers around you.

Don't get me wrong. I have nothing against having other interests. But having other interests and writing inspired software are hardly mutually exclusive.

Great companies foster cultures that draw employees who are looking for inspiration. Take Google, for example: "Google engineers all have '20 percent time' in which they're free to pursue projects they're passionate about." And it's worked for them: "This freedom has already produced Google News, Google Suggest, AdSense for Content, and Orkut - products which might otherwise have taken an entire start-up to launch."

Ironically enough, since this article is related to Fog Creek Software, Joel Spolsky has written very well on this subject already. I suggest you read it. Slowly. Then go back and read it again.

Really great programmers, the kind who want software to be "inspired," are worth their weight in gold. Good management identifies them early, pays them a ton of money, and makes sure they're always happy. If they lose them, they tend to throw chairs around the room. That's how valuable they are. The rest tend to plod along in the IT development of, say, General Motors, writing crappy Perl CGI scripts to automate HR tasks (poorly).

http://www.joelonsoftware.com/

Of course the real profit is in increased exposure to Joel's company and the highlighting of his internship program, which likely promises an even better crop of students next summer.

Yes, that's right, the marketing guy Yaron Guez. If you read the blog you can see for yourself how he was always the one staying up till 3 partying, he was the one who screwed up the logo designs and posters and had to be bailed out by the techie interns, he was the guy who came up with the rediculous "sidepilot" naming gimmick.

Here are examples discussing his general ineptitude.

Its a bit of a surprise given how good at marketing Joel himself is.

Yes, that's right, the marketing guy Yaron Guez. If you read the blog you can see for yourself how he was always the one staying up till 3 partying, he was the one who screwed up the logo designs and posters and had to be bailed out by the techie interns, he was the guy who came up with the rediculous "sidepilot" naming gimmick.

Here are examples discussing his general ineptitude.

Its a bit of a surprise given how good at marketing Joel himself is.

Yes, that's right, the marketing guy Yaron Guez. If you read the blog you can see for yourself how he was always the one staying up till 3 partying, he was the one who screwed up the logo designs and posters and had to be bailed out by the techie interns, he was the guy who came up with the rediculous "sidepilot" naming gimmick.

Here are examples discussing his general ineptitude.

Its a bit of a surprise given how good at marketing Joel himself is.

Restart from scratch? Are you insane? Do you think new code will have fewer vulnerabilities? Solid code it code that has been out there a long time and has had many people hitting against it again and again. Code doesn't 'rust' when it gets old.

You just couldn't recreate Windows from scratch. It took a long time to get to where it is. Projects that large fail 100% of the time. It has to be done in smaller iterations.

Joel wrote a really good article on how restarting from scratch is the single worst IT mistake you can make. I refer people to this article a lot. The 'ugly' part of windows is one of the reasons why it works so well, because the ugly parts are bug and security fixes.

Your programming example would remove the need for mutexes, but that's about all. Spawning a thread, while faster than an entire process, has cost.

In your example, the context of the current thread would have to be duplicated (how does the compiler know what data operation() will use). They can't run from the same data - what if doSomeThing() modifies a field that operation() uses?

Java's FutureTask requires extra work, but it protects you from concurrent data modifications errors. (Or, it appears to. I'm not familiar with it...)

Your idea is good. We're eventually going to need a revolutionary way to parallelise computation on a larger scale (larger than instruction-level, anyway). But don't forget - at some point, all abstractions leak.

Even if we could split all function/method calls out to separate threads, there will still be waste. Just as instructions must wait for their inputs, so must your functions/methods. To get a well-optimised program, a software engineer will still be stuck with managing the critical path of execution.

Perhaps you could share with us your incredibly accurate estimation technique?

You set set your priorities, and when the coding deadline arrives, you stop. You then proceed to final testing (because of course you were doing some testing as you were coding as well).

This won't necessarilly work for all projects, but it's probably the easiest way of having new releases that have both new features and a stable release.

it's useless.
AJAX is a simple concept. Really, it is. Getting three different coding paradigms to work together harmoniously is not so simple. Throw in available AJAX libraries, JSPs and Atlas pages and you've got layers upon layers of coding cruft that need to be understood before a functional, stable, web-app can be built.

If this book stays at the architecture astronaut level without ever delving into the why of the code structure of the example programs, then it may serve as a cookbook but certainly not as an informative manual that can provide a baseline from which coders can build their skills.

Perhaps the book is better than the reviewer makes it out to be, but he offers no real justification of the 9/10 score awarded, so it's hard to say. Just for giggles, I should note that when Richard Stevens' seminal Advanced Programming in the Unix Environment, 2nd Ed. (being possibly the most comprehensive and useful programming book I've ever read) was reviewed it also received a 9. How do these two books compare?

I must say I am quite surprised to see this article on slashdot, mostly because I just had an interview with Rural Sourcing and was given a job offer. A whopping $27,000. I'm sorry but I quickly sent a polite email saying, "No thanks." I made more than that my sophomore year working at SAS.

The driving reason for declining their offer is that I just do not believe they will be able to keep smart graduates in Greenville, NC at that rate. There are just too many jobs on the east coast for IT workers. They are basically trying to hire my entire graduating class since I seriously doubt they will be about to coerce kids from coming from anywhere else.

On my second interview I was invited to their job site where I was shown the master plan for upgrading their cube-farm. They want to have 45 employees by next summer and 100 by Dec 2006! They have 12 now. I think they would be best to take a look at http://www.paulgraham.com/start.html and consider hiring people based on need. If they had fewer employees they could offer better wages and have a ghost of a chance of keeping smart people in Eastern North Carolina. There's plenty of great evidence showing that smart programmers can consistently be 10 times more productive than average programmers. Here's just one link http://www.joelonsoftware.com/articles/HighNotes.h tml Just one bad hire can kill a team and it really takes a good programmer to know a good programmer. It's safe to say their manager (named "Buddy") is not a programmer. He's a great guy and moderately buzzword-compliant, but he's not a programmer.

I am graduating from ECU (the university mentioned in the Wired Articles) this Decemeber and I believe that our program (although practically unheard of) is very competitive. Plenty of our graduates go on to be successfull just like other schools and some of our graduates find out that by not taking their career into their own hands they have effectively received a degree in Common Sense(tm). I'm afraid that Rural Sourcing's idea of trying to grab every graduate from ECU is going to be a disaster. The smart ones will go other places, the ones who have NO CHOICE will stay in Greenville and work at Rural Sourcing.

Hungarian notation is only lame when misused: http://www.joelonsoftware.com/articles/Wrong.html

I don't know where you saw it but it looks like they were taking this advice.

Yeah, but Joel's an ass.
[...]
Dude needs to work on his street cred.

He worked at Microsoft as a program manger for the Excel development team (I believe had some other positions as well there). That's his street cred, and also one of the reasons he's popular among Microsofties. Why Slashdotters like him I'm not sure, maybe his article How Microsoft Lost the API War earned him some fans.

Although he's written a few good articles here and there (but not recently), I do agree that he's an ass.

Talking about Hungarian notation, You haven't seen the worse.
Function name with prefix for the return value ! Yes, like a gorry :
int nGetHostByName(char *szHost, int nNamelen);
Surely once, one guy in this company will think about writing as well the variable types in the function name !
How usefull !
(They should just hire _better_ programmer)

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

And finally, all people who use Hungarian notation are locked in the basement and given menial tasks until they repent their sinful ways.

Don't forget that there is a difference between 'system hungarian' and 'apps hungarian'.

System Hungarian I agree is a waste of time. The compiler already knows the types of each variable.

Application Hungarian - the original intention of the inventor, Charles Simonyi - though is another matter entirely and seems quite sensible.

I'm not a friend of a hungarian notation.

Neither was I until I read Joel's take on it... After that, the correct use of Hungarian Notation seems to be a much better idea... I can also see how pointless the dark-side of Hungarian is...

I think there should be more style-guides emphasizing the appropriate use of Hungarian...

I used to have that feeling about Hungarian too. Until i read Joel's view of how Hungarian is meant to be . There are definitely some times when it is a Good Thing. Not for your str_ThisIsString variables, but to put you in a mindset so that you know whats going on. Its not something to use everywhere (maybe 5-10% of your variables will need it), but if you put it where its needed, its something that definitely helps code maintainability.

Yeah, that's great as far as coding standards go. The moral of that article is "some coding standards are actually meaningful and useful". But it's also very easy to create coding standards that are just nauseating.

Most importantly, keep in mind that whatever standards you come up with better stand up over time. Eventually, they'll be being used by a young generation of poli sci majors. It's not the standards, it's who's applying them.

Has several excellent articles on the subject This is about as good of a starting place as any.

"You know, I agree with your point about continuous burn. The reason we need this uninterupted distratction-free time is because there are a heck of a lot of juggling balls that we have to keep in the air all at once. As soon as the phone rings or a boss comes in or an email needs to be read balls start dropping. And that frustrates us because we were on a roll and now we've got to figure out where we were and get ramped back up again."

Or as Joel explains in a way which the managers can understand (or at least, trust):
http://www.joelonsoftware.com/articles/fog00000000 22.html

Revered? Irreverant is more his style. Authoritative? He's pretty authoritative on early versions on Excel and on running a small business and staying afloat. Interestingness (or lameness) is subjective and you are entitled to your opinion, but I dare say the reason the reason people link to him is because they do find him interesting.

And oh, about that 'lame blog entries' dig? A lot of people like blogs because they reveal a lot about the person. They sure make for more entertaining reading than PR pap, Unix man pages and the typical low S/N mailing list. Sure, you get angst-ridden teenagers, but you also get law professors, call girls, people who run their own small business, SGML and XML gurus. On message boards like Slashdot, though, you get dupes and the same old tired arguments about Open Source and Digital Freedoms and (bonus!) Slashdot commenters complaining about how lame other people are. Oh the irony.

Actually, Joel (from http://www.joelonsoftware.com/) was complaining about that recently. He was like, Yeah, Google gives us a lot more hits, but most of them are from villages in India or China. Google is losing the trust of some advertisers, which could hurt them a lot.

Don't forget about all the fraudulent clicks ey... It seems like they're having a lot of problems with those...

The ads on their own pages may work well, but AdSense is not without its problems.

A long time ago. Someone already posted this link, but here you go: http://www.joelonsoftware.com/articles/fog00000000 07.html