Slashdot Mirror

Constant interuptions are a major evil.

Developers need to huddle once in a while, but that should happen in a neutral space.

..I'll admit, I've never used it, but just from reading about it, and knowing who the main architect is, it seems like a pretty decent product.

Check it out here :CityDesk

Joel Spolsky argues that offices are essential for developers because it's the only way to get into "the zone." Without a door to close, cubicles invite interruption. Somebody innocently asks a question and bang! all of the variables, procedures, and methods drop out of your head. Takes a good 5, 10, 15 minutes or more to get back to find your place. Considering how much programmers are paid, that adds up to serious money.

Or, like I just did, you might just start reading Slashdot. I gotta get back to work...

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

Read any book on managing programmers, and you'll discover that programmers are much more efficent in an office than in a cubicle.
Read: This article
Basically programmers need concentration to work, and being in a cubicle all day mean that they are constantly being interuppted.
Not good!

Actually, although his company, FogCreek Software, sells proprietary software, they do provide the customer with a copy of the source-code for some (all?) of their products. It's not Open Source (and certainly not Free Software) but you can review the code yourself, fix bugs, etc...

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

Discussions about software construction are always good IMO. Sometimes I agree with the person and other times I have no frame of reference (eg., making shrink-wrap software) and sometimes I just flat out think they are wrong.

I do like his list of books.

Discussions about software construction are always good IMO. Sometimes I agree with the person and other times I have no frame of reference (eg., making shrink-wrap software) and sometimes I just flat out think they are wrong.

I do like his list of books.

Yes, you just did it.

In fact, I don't care. It seems not many people realize how right Joel is in most of what he says. That's because it's difficult to understand some grim realities of software development, particularly about project management, without real experience in a similar setting. I run my own software company, so I fight daily the problems Joel talks about. My clients are corporations, and my software is custom, so my context is not the same as his. Nevertheless, I've failed less often thanks to his advice. I want to give credit when credit is due.

I see that many posts try to point out what Joel does not get right. I know that he is spectacularly right about at least one thing. Why not read about it in his own words?

Joel thinks that rewriting things is a bad idea because it loses information embedded in the old code (original anti-rewrite essay, search for "Nancy" to find a good example) and then says in the interview:

Half the time when I go into a function to fix a little bug, I figure out a cleaner way to rewrite the whole function

This is the same guy who wrote Yet Another Bug Tracking System while observing that such things were a dime a dozen, and then went on to write Yet Another Content Management System without defining its target market, even as he criticized others for such undirected development. Apparently, Joel's quite comfortable stating commandments for others while living by different rules himself. His articles are unfailingly interesting, but should by no means be accepted as authoritative (as is true for anyone who spends more time on the pundit circuit than actually programming)

Yes! Joel Spolsky identified this tactic as "cover fire":

Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET - All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That's probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can't spend writing new features.

This is a small excerpt of Fire and Motion, IMHO the best article he's written yet (which is really saying something).

With this hack, at last, XFree can deliver similar aesthetic results to Mac OS X's or Windows' rendering engines.

Ah, so blurry text is an "aesthetic result"?

"Anti-aliasing" just means blurring, and is in general not a good thing. And this particular hack turns off hinting, to make it every blurrier.

Like headaches? Install this.

I'm really not trying to troll here but anti-aliased text has always looked fuzzy to me. In the screen shots, for example, the spacing and sizing of the AA text is certainly nicer but the default text seems shaper and crisper. Am I wrong here? Joel Spolsky agrees with me but everyone else seems so excited about AA text that I have to wonder if I'm missing something.

I suppose we also need documentation that describes the overall structure of the system etc. But this can be kept at a fairly high level and it should not change much.

As far as hiring people, I've hired plenty and ran across few that interviewed well, but turned out to be a disaster.

Finally, regaring hiring I found this article The Guerrilla Guide to Interviewing really helpful.

Listen to the clever people. Not me, but Joel Spolsky.

From his book, User Interface Design for Programmers:


Usability is not everything. If usability engineers designed a nightclub, it would be clean, quiet, brightly lit, with lots of places to sit down, plenty of bartenders, menus written in 18-point sans-serif, and easy-to-find bathrooms. But nobody would be there. They would all be down the street at Coyote Ugly pouring beer on each other.

(he also said that on his site in Nov 2000.)

Joel's a far more clever guy than I, and is always much more eloquent in expressing ideas. You should listen to him, too.

J.J.

Listen to the clever people. Not me, but Joel Spolsky.

From his book, User Interface Design for Programmers:


Usability is not everything. If usability engineers designed a nightclub, it would be clean, quiet, brightly lit, with lots of places to sit down, plenty of bartenders, menus written in 18-point sans-serif, and easy-to-find bathrooms. But nobody would be there. They would all be down the street at Coyote Ugly pouring beer on each other.

(he also said that on his site in Nov 2000.)

Joel's a far more clever guy than I, and is always much more eloquent in expressing ideas. You should listen to him, too.

J.J.

Linux is ready for the desktop, and has been for years. Are migrating desktop users willing to learn how to use Linux on the desktop? Not yet.

Oh I see, it's the users' fault.

As soon as they stop acting so st00pid Linux will take over on the desktop.

People don't want to learn a new environment unless there's a concrete benefit to doing so. Not supporting "Right click/Properties" just to be different or for the convenience of developers makes Linux a little bit harder to learn. Add up a bunch of these subtle interface incongruities and your users will feel furstrated, upset and angry.

Linux brings more to the table than a re-arranged GUI with different colors and fonts. So why not try to match the familiar (Windows) interface on commodity OS elements (copy/cut/paste keystrokes, file property menu location and other common right-click behavior, basic File menu commands and Edit menu commands, even task bar/dock and start/apple menu) in as many cases as possible while adding subtle, unobtrusive improvements to interface components where Linux can excel (paticularly software upgrades, since most apps upgrade for free under linux and can almost always do so online, and doo dads like a graphical uptime monitor that highlight Linux' strengths).

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

Same here. If managers realized that they didn't exist to be the boss, but to serve the development group, then you have a situation that works well. I've been there. It's nice. What Joel Spolsky would call "managers that move furniture out of the way" or something like that.

The correct link is In Defense of Not-Invented-Here Syndrome. Putting a URI in plain text on a Web site is ridiculous.

Thanks for the link. Lots of good articles there. The URL as posted doesn't quite work, so here's a cleaned-up version.

why would you give oral to an isreali

Because he's Joel

(Joel is a talented developer. He's also a former Isreali paratrooper and a homosexual, at least according to his website

Just because your competition is well funded does not mean you necessarily need to "sellout" to VCs. Check out Strategy Letter I: Ben and Jerry's vs. Amazon by Joel Spolsky. He compares Ben & Jerry's profitable, slow-growth business model to Amazon's get-big-fast model. Do Ben & Jerry style companies have to stay small? No. Consider that Microsoft has been successfully chugging along since the 1970s.. and growing.. and growing..

The website wasn't always buzzword bingo. It used to be reasonably informative, although with some amount of Greenspun-style bombast (which you might think is worse). You can probably find some of the older content still on there, 'ACS Developer Journal' articles, tutorials and so on. The site developer.arsdigita.com is where most of the info moved to.

As Joel Spolsky suggests, you could take the decline in the website's usefulness as indicating the general health of the company.

Of course, you can't have an announcement of Mozilla without a complaint about the slowness of Mozilla development, so here's something one up on that: a link to Joel on Software, so here it is.

Deadlines aren't the problem: unreasonable, inflexible deadlines are the problem. All the vices associated with coding under deadline pressure come from bad time management, not the simple fact that some thing needs doing by some specific time.

Joel Spolsky goes on at great length about proper scheduling of software development, and seems to get it right.

Agreed! It is a common misconception that the only way to fix a problem is to start over. Here is a good article about not needing to rewrite code just because it sucks, and where it is better most of the time to revamp the existing code rather than throw it out the window:

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

The manager was Joel Spolsky, the article is here, and his site is Joel on software which has a lot of good articles. Since he's a manager with (it appears) a proven track record, bosses might just listen if programmers go to them with his articles. By the way: the place I work at now gets 0/10 on his software development methods test.

czth

The manager was Joel Spolsky, the article is here, and his site is Joel on software which has a lot of good articles. Since he's a manager with (it appears) a proven track record, bosses might just listen if programmers go to them with his articles. By the way: the place I work at now gets 0/10 on his software development methods test.

czth

The manager was Joel Spolsky, the article is here, and his site is Joel on software which has a lot of good articles. Since he's a manager with (it appears) a proven track record, bosses might just listen if programmers go to them with his articles. By the way: the place I work at now gets 0/10 on his software development methods test.

czth

The unique thing about software is that it is infinitely clonable. Once you've written a subroutine, you can call it as often as you want. This means that almost everything we do as software developers is something that has never been done before. This is very different than what construction workers do. Herman the Handyman, who just installed a tile floor for me, has probably installed hundreds of tile floors. He has to keep installing tile floors again and again as long as new tile floors are needed. We in the software industry would have long since written a Tile Floor Template Library (TFTL) and generating new tile floors would be trivial.

from http://www.joelonsoftware.com/news/fog0000000337.h tml

Reading both of them it becomes obvious that it's better to get something out there, as long as it's not unacceptably bad, and then auger in on perfection.

I can remember when the IBM PC and Apple were going head to head. What it came down to is that you could get your work done on the IBM PC without having to pay the huge sums Apple always demands. People voted with their pocket books. They always do.

Now Gates, et al., have a deathlike grip on the world of popular computing. Apple may have the right thing, but the right think always costs too much and takes too long to arrive.

When I use Mac OS X, I can *feel* that somewhere in Cupertino there's an English major who was losing sleep at nights trying to make the text in the dialog boxes as clear and understandable as possible.

Quality. Art. The "soul" of a machine.

For those of you who haven't programmed using Cocoa or haven't messed around much with OS X or actually seen and used a recent iMac in person, there's no substitute for the tangible results of Apple's years of dedication.

I wrote an article about the method we use at Fog Creek for making software schedules which I've seen work very precisely, consistently, on projects from a week to two years. The basic approach is to make sure that the granularity of the tasks that you are estimating is fine. If you itemize the tasks at the procedure level (write subroutine x), where each task is less than 2 days, your schedule will work. The reason most people's estimates don't work is because they pull them out of the air, instead of actually thinking about what tasks they will need to complete. Getting down to the procedure level forces you to figure out what you're actually going to do, which is how you get a real estimate.

Oh but of course. And that's why Excel wasn't successful until it was both forwards and backwards compatible with Lotus 123?

Read this.
Read Joel's other stuff too.

And as much as I hate to say it, this also provides ammunition to the people who claim that open source is very good at copying other projects' work, but terrible at innovating. Honestly, of all the high profile open source projects, how many of them are a significant innovation, and how many are merely an attempt to produce an equivalent of feature Z of Windows or Unix or Mac OS on Linux?

Yeah? And what proportion of "high profile" closed-source projects really innovate?

In the days of Excel 1.0 through 4.0, most people at Microsoft thought that the most common user activity was doing financial what-if scenarios, where you do things like change the inflation rate and see how this affects your profitability. When we were designing Excel 5.0, the first major release to use serious activity-based planning, we only had to watch about five customers using the product before we realized that an enormous number of people just use Excel to keep lists. They are not entering any formulas or doing any calculation at all! We hadn't even considered this before. Keeping lists turned out to be far more popular than any other activity with Excel. And this led us to invent a whole slew of features that make it easier to keep lists: easier sorting, automatic data entry, the AutoFilter feature which helps you see a slice of your list, and multi-user features which let several people work on the same list at the same time while Excel automatically reconciles everything.

I have person at work that actually typed a column of numbers into a spreadsheet, added them up with a calculator, and entered the total back into the spreadsheet. Talk about underutilization!!

"my first software released under GPL (November 1988) -- now the Slashdot kiddies have to shut up; I was writing GPLed software before they were born, bwa ha ha!"

Posted Thursday, December 13, 2001 on his site..

He has alot of good thing to say about software management and programming.. read and learn instead of getting caught in Microsoft bashing..

Joel Spolsky has an article up on his blog site that speaks to this point.

He uses Netscape's decision to rewrite Netscape 6 from scratch as an example, and expands upon many of the points mentioned above.

Some here are warning you that major changes always require a total rewrite; yet in real life, total rewrites result in inability to compete (look how long the Netscape rewrite paralysed Netscape, unable to meet Microsoft's challenge!). There's some good discussion of the danger of rewriting at a former MS software engineer's site, and some limited advice about how to get away without doing it.

But you've decided to rework rather than rewrite, you say, so I have no doubt you'll ignore the naysayers here. So what CAN you do? After all, as you recognise, reworking is dangerous!

The following rules have worked for me; I've refined my own experience with advice from Fowler's Refactoring, a book as useful as Design Patterns, and with study of Extreme Programming, a design methodology forged in the traditions of Smalltalk, and in the knowledge that maintainance, the most important and expensive part of software engineering, is also the least studied.

First, do the simplest thing that could possibly work. Don't EVER take your program out of commission for more than a day; make sure it runs at the end of each day. If you're doing something and at the end of the day your code base is broken, STRONGLY consider throwing away your changes and going back to the design stages.

Second, rely on unit tests extensively. Start every change by writing as extensive of a unit test as possible. Unit test every function you touch, BEFORE you touch it, and after. Unit test every change you make, and run the unit test BEFORE you make the change to ensure that it fails (i.e. it detects the change). Write your unit tests BEFORE you write code, whenever possible; you'll objectively know your code is done when your unit tests pass.

Third, don't design too far ahead; you don't know what tricks the old code is going to throw at you. Implement one feature at a time, bringing the code into compliance. Once everything has a unit test (thanks to your following the above principles), THEN you can safely embark on larger design changes -- and in the meantime, you have working code with new features, a win even if your customer/boss/manager decides not to continue.

Fourth, don't be afraid to redesign your own code. The stuff you wrote has more tests, so it's safer to change, but it's more likely than the old code to lack some critical understanding only age can give.

Fifth, use the principles of refactoring. Whenever possible split each code change into two parts: first, a part which changes the structure of the code without changing its function (and which therefore allows you to run the same unit tests); and second, a part which uses the new structure to perform a new function (thereby requiring new unit tests).

Good luck. If you want more advice, read up on Extreme Programming.

-Billy

He says the exact same thing as you, only better.

I read Joel's original article on this subject("Things You Should Never Do, Part I") a few months ago. Despite the rampant /. kiddie practice of posting a strong opinion without reading the article being referenced, I encourage you to read it now:

Things You Should Never Do, Part I

OK, so you didn't read it, I'll quote a juicy part: "You are putting yourself in an extremely dangerous position where you will be shipping an old version of the code for several years, completely unable to make any strategic changes or react to new features that the market demands, because you don't have shippable code. You might as well just close for business for the duration."

The point is that if you have all the time and money in the world, of course you should rewrite from scratch when things get yucky. The problem is that in the real world, companies need new releases to keep selling upgrades, so you need to keep steadily improving the product. Similarly, customers adopt the product, use it a bit, and then learn what they want next - they want to invest in the product more. Meanwhile, the purist coders at the vendor are busy taking three years to make the architecture pretty, which will pay off big-time in year 4 and 5 when they'll be able to add new features at a breathtaking pace. Customers get pissed and go find someone who will sell them a product which is about as buggy as the one the first company made, but which now has a few key features.

Coders don't necessarily understand the sales angle of this, because they're trying to avoid inefficiencies in development, such as wasting time hacking on a crufty code base to try and add a feature. They'd rather invest early and reap rewards later. The problem is, most software companies don't have the luxury of investing heavily from a payroll standpoint, not even considering the customer attrition problem.

As a perfectionist myself, I really hate the fact that this is true, but it is. Business realities suck sometimes. There's a sci-fi business parable about this...

Two space empires are at war. One side is starting to lose, but one day their leader announces that they will soon be victorious! Their scientists are working on a doomsday device which will wipe out the enemy. Time passes and the war is going badly, but no one is worried about the heavy casualties because they know they will win any day now. Planet after planet is captured, ship after ship destroyed. Finally, one day the lead scientist who is working on the homeworld screams "Eureka!" because he knows that the device finally works. He races to the office of the imperial leader and bursts in, full of excitement, only to see enemy soldiers standing over him with guns drawn as he signs his name to articles of surrender, because they've lost.

Unfortunately for the scientist and his empire, they didn't think to refactor, or design APIs between modules... :) If they had they'd be able to clean things up module by module, because they designed robust APIs early and then wrote quick and dirty implementations that could be fixed later when there was both time and need.

eXtreme Programming has some interesting things to say about this too. Basically, don't implement anything that isn't in the requirements now (that is, don't overgeneralize to a fancy-pants API and module system if you're only gonna write one module on top of that API), also known as DoTheSimplestThingThatCouldPossiblyWork, and RefactorMercilessly to clean up code continuously as you maintain it.

Finally, remember that testing makes maintenance immeasurably easier. The reason that maintenance sucks so bad is usually that some cowboy coder thought that documentation is what you do when the code is finished, which of course (a) is wrong and (b) never actually happens. If docs are demanded up front, including test cases, coding is much easier as is maintenance, and you don't have to bite your fingernails wondering if your tiny bug fix un-fixed 100 other "fixed" bugs. If you have tests, you can RefactorMercilessly and rip out the most egregiously gross code, and get it all back together and working, without it blowing up in your face. So make sure somebody writes a basic spec, then write test cases and code that performs them so you can code with impunity and so you can go on vacation :)

Joel, I read the interview on your site and then followed the comments here. No one has seemed to point out is that it is a total rehash of things you've posted to joelonsoftware.com

Either you are amazingly consistent or you let someone sew a bunch of selected paragraphs together...

His site's FAQ ("What's going on here?") includes unsolicited praise for the discussion group: "The forum is great because you attracted a group of thoughtful people who can write clearly. No flames. No all caps. No crap. Little HTML showing where it shouldn't. No one replying just to be the first to reply."

And then he gets featured on Slashdot. Poor Joel. Poor discussion group.

One of the things in particular that striked me as suprisingly simple but yet powerful is the Zero Defect concept : in theory, you try to eliminate all bugs before adding any new code to a product. The reasons being

1. it's harder to hunt the bugs later when the amount of code is even higher
2. the longer you wait, the less you'll remember about the code containing the bug
3. with zero/few bugs, you can always ship a product when you have to, not "later on" when you will have "removed the bugs" -- you can always ship right here, right now, with zero bugs, only maybe not all the features you'd want.

Lacking a PGP key, I'll have to direct you to look on Joel's homepage. Am I really THAT famous?

Yes, it's true. If you make a major mistake, you get killed, often by Microsoft. Some people think it's a pretty sad state. I just think it's capitalism and evolution. Dodo birds are extinct, and so is Visicalc. I don't want to be extinct, so I try to learn from the mistakes of the companies that have tried to go up against Microsoft. It's easy for me because I was inside and I know something about the way R&D worked at Microsoft. I've tried to share many of these lessons on my site.

To succeed in commercial software you have to get beyond being shrill and angry about Microsoft. You have to be cool headed and smart and study the past and make the right decisions for your company, not the right decisions for some arbitrary sense of aesthetics (although of course I am as big a fan of clean documented code as anyone.)

Production code is not so pretty. Open source code is not so pretty. No real code is all that pretty. It takes time to study it, understand it, and read it, to understand how it got the way it is. The more widely the code is used, the more true that is. For Fog Creek's latest software product, CityDesk, we stayed up one night tracking down a bug that only happened on Chinese Windows, where asc(chr(x)) turned out not to be equal to x, an assumption we had been making. How many of you ever thought about getting your code to work on Chinese Windows? No matter how well that piece of code was designed, I'm sorry, I've been programming for 20 years and I never realized that asc(chr(x)) was not always equal to x on some platforms, and I designed it wrong, and until someone tried it on Chinese Windows, I never would have known. Now the code uses byte arrays instead of strings and doesn't have that problem. There's a nice comment in the code saying "use byte arrays instead of strings because of MBCS versions of Windows." The code now works perfectly, but the byte arrays are a little bit uglier than strings. If ten years from now somebody rewrites CityDesk from scratch, I'll guarantee you that 95% of the Windows programmers working today would make the same mistake again, and stay up all night again.

If a piece of your code is ugly and doesn't work, by all means, rewrite that piece. If it's ugly and works perfectly, you're wasting valuable hours rewriting it, time that could be spent doing something that will gain you market share. If you really have an undecipherable mess of spaghetti, 9 times out of 10 you're just being lazy about deciphering it because it seems like more fun to create it from scratch, but it's the ultimate in arrogance to think that your newly created from-scratch version is going to be all that great.

I have learnt a lot of good practices from one or two of Spolsky's articles, and for that I was prepared to put up with his cocky know-all attitude and routine rubbishing of every software company except the ones he has stock in, but lately he is full of tendentious statements like

In 1993, Microsoft Excel 5.0 took up about $36 worth of hard drive space. In 2000, Microsoft Excel 2000 takes up about $1.03 in hard drive space. All adjusted for inflation. So stop whining about how bloated it is.

So the space it takes on the hard drive is the only cost of bloatware? Try downloading IE 6 on a dialup connection and then check your phone bill.

I have learnt a lot of good practices from one or two of Spolsky's articles, and for that I was prepared to put up with his cocky know-all attitude and routine rubbishing of every software company except the ones he has stock in, but lately he is full of tendentious statements like

In 1993, Microsoft Excel 5.0 took up about $36 worth of hard drive space. In 2000, Microsoft Excel 2000 takes up about $1.03 in hard drive space. All adjusted for inflation. So stop whining about how bloated it is.

So the space it takes on the hard drive is the only cost of bloatware? Try downloading IE 6 on a dialup connection and then check your phone bill.

No, but you used it as though you believed it. In my experience, now that it's no longer the '60s or '70s, the phrase gets thrown around by people who know little about software development, usually to sell a product or idea.

Translation simply takes whatever you have written and converts it into the optimum bit sequence for the machine to deal with.

Or for that matter, Translation from whatever form to whatever target form that is defined. Like Human to human Translations (i.e. English voice input to german audio/spoken output.)

The translation mechanics are going to be the same.

You might want to read Joel Spolsky's piece on "Architecture Astronauts". Suggesting that all translation from any language to any other language involves the same translation mechanics, to me simply indicates that you've never actually done any work or studying in this field, and are indulging in armchair speculation. Any abstraction at that level will be essentially useless to the task of actually translating the material in question.

Take a look at what's involved in rewriting code in a functional language to a compiled form - an area that's enjoyed a lot of academic attention - and compare that to tools which translate human languages. The commonality there is minimal, at the level of stratospheric overviews like "get input; translate input; produce output". Architecture astronauting indeed! Dare I point out that all computation follows this pattern - "translating" a problem into a solution - so once your universal translation mechanics have been developed, we'll never have to write another line of code? "O great translation mechanics, what is the answer to the question of life, the universe, and everything?" Sounds good, let me know when you're done!

Painless Software Schedules is a great one and you will get sucked in just following the links from this one essay.

Joel Spolsky, another engineer-turned-architect writes thoughtful, entertaining, straightforward essays on these topics and other elements of software management based on his experiences at MSFT (regardless of your opinion of their business practices, they are certainly successful at orchestrating large, complex software projects) and, more recently, at his own company.

This stuff is such good reading that I've converted most of it into Plucker format for browsing on my PalmOS device. You never know when you'll need it for reference or inspiration.

Some personal favorites: The Joel Test of effective s/w development processes, painless software schedules, writing effective (read: convincing) functional specifications, and plenty of other gems.