Archive for April 2002

2002/04/02 02 Apr

Can't Understand It? Don't Worry.

Whenever somebody gives you a spec for some new technology, if you can't understand the spec, don't worry too much. Nobody else is going to understand it, either, and it's probably not going to be important. This is the lesson of SGML, which hardly anyone used, until Tim Berners-Lee dumbed it down dramatically and suddenly people understood it. For the same reason he simplified the file transfer protocol, creating HTTP to replace FTP.

You can see this phenomenon all over the place; even within a given technology some things are easy enough to figure out and people use them (like COM's IUnknown), while others are so morbidly complicated (IMonikers) when they should be simple (what's wrong with URLs?) that they languish.

2002/04/07 07 Apr

Whenever I start to read a review for a new "bloat-free" MS Office competitor, I know what the script is going to be:

  1. Office is overpriced and "bloated" with too many features that you "don't need"
  2. Luckily, <company X> made a smaller leaner one without all the bloat
  3. But I'm never going to use it, because it doesn't have <insert my favorite feature> or word count.

It's actually quite amusing how often this exact script, including the "word count" gripe, recurs.  Here's one from 2001. And another from 1997.  Oh, look, it happened again.

Remember, kids, the trouble with the "everyone only uses 20% of the features" myth is that everybody uses a slightly different 20%, and the journalist who has to review your exciting new BloatFreeWrite has been told to write a 250 word story.

(For review: Bloatware and the 80/20 myth. No matter how much it bothers you neat freaks, the market always votes for bloatware.)

2002/04/10 10 Apr

Guerrilla Marketing

For reasons that are explained in today's ship date article, my company's current marketing efforts are focused on low profile, word-of-mouth marketing, not Superbowl ads.

As a company founded by programmers, it's no surprise that a lot of what we do for sales and marketing is done by writing code, not by making phone calls or hiring ad agencies! In that spirit Michael has finished setting up an affiliate program for Fog Creek Software. A little ASP code, some database magic, three thousand pages of lawyer-approved legalese, and hey presto! an automatic sales program that costs very little.

If you have a web site, you can link to CityDesk or FogBUGZ and earn 15% any time someone buys our software through your link. We also decided to actually allow you to link to Joel on Software and TechInterview with the affiliate program. A lot of people hear about our software through these sites. So web sites that would link to JoelOnSoftware anyway can make money if anyone they refer eventually buys software from us (it works using a 30-day cookie).

To get the new program off to a good start, I'm going to raise the commission to 20% for anyone who signs up by Friday. And if you make your first sale before May 1st, we'll boost your commission to 25% permanently. You could make almost $500 if someone you refer to us buys a single FogBUGZ site license.

Today's Article: Picking Ship Dates

One of the best reasons to make a detailed schedule is because it gives you an excuse to cut features. If there's no way to make the ship date and implement Bob's Singalong MP3 Chat feature, it's easy to cut that feature without making Bob feel bad.

But -- how do you pick a ship date?

 

2002/04/11 11 Apr

According to the New York Times, Microsoft has pretty much abandoned their plans to centralize everyone's personal data.

The plan, a version of Passport on steroids called Hailstorm, never had a chance, for three reasons. First and foremost, Microsoft could never get any other company to go along with it. Partially this is because nobody trusts Microsoft any more; more significantly, it's because there's no real benefit to the other companies. Second, consumers weren't about to trust Microsoft with all their juicy personal data. There was just too much of an uproar. And finally, as in now becomes clear, this was Rick Belluzzo's pet project, and, as anyone could have told Rick, Microsoft doesn't really like executives brought in from outside, even though they keep bringing them in.

Moving to .Net

I wrote up our current thoughts about moving to .NET at Fog Creek.

2002/04/12 12 Apr

Whitelist spam filters are probably the last hope for dealing with spam in a meaningful way, and I can tell that people are starting to use them -- the last notification email I sent out resulted in a few replies saying "please respond to this message with blahblah in the subject line if you want me to read it" which is what the whitelist programs bounce back.

I can't really process all of these bounces manually; my mailing lists are managed by a professional service provider (Whatcounts; recommended). The moral of the story is that if you have a whitelist filter, please make sure that *@whatcounts.com is allowed or you won't get the mailing list. Also, all mailing list messages will always contain [JoelOnSoftware] in the subject line.

Open Source and Usability

Matthew Thomas, a Mozilla contributor, wrote something interesting about why free software usability tends to suck.

Coupons are Fun

We just implemented coupons for our web shop. Nifty. Here's a treat for the weekend: enter MISSPIGGY in the coupon box to get CityDesk Home Edition for $59 instead of $79. Expires April 15th.

(The serious point of coupons is that they let you try different offers on different people and figure out which ones are the most profitable. For example we could send 1000 people a coupon for $20 off, and 1000 people a coupon for $40 off, and compare the response rates).

2002/04/19 19 Apr

I've been having a lot of fun developing The Fog Creek Control Panel with ASP.Net. It's a web page that allows us to track critical business data in real time. I can see things like how many people are registering the CityDesk starter edition, how many affiliate applications need to be processed, how many bug reports have arrived from customers (2 so far today), and so on. This morning I added two features: one gets detailed order information for any purchase in our database, and the other lists open purchase orders people have placed with us. Elapsed time to implement both features: 20 minutes.

To be fair not everything about .NET is peaches and cream. Here are a few steps backwards I've noticed so far:

  • the IDE is amazingly sluggish on my PIII/600 laptop. (Speaking of which, why the heck can't I get a Thinkpad X-series with a 1.7 GHz P4M already? Does anybody know of any ultralight notebooks with this chip?)
  • since destructors aren't called when an object drops out of scope, if you have a SqlConnection object, you positively have to remember to close it because you can't wait for the garbage collector to come around. I suppose this limitation of GCs has been argued to death when Java came around, and it's not a big deal, but it is a step backwards
  • that 20 MB runtime is a real showstopper. Yes, this is an advantage to Delphi. I'm starting to suspect that Microsoft doesn't care -- they are perfectly happy to have a development environment that is excellent for internal/corporate applications, where they don't compete, but borderline useless for shipping, commercial, shrinkwrap, where they do compete.

 

2002/04/25 25 Apr

There's a lot of SOAP backlash these days. For example Paul Prescod is moping about how SOAP is so much more complicated and less efficient than what he calls XML/HTTP/URI. Everything he says is factually correct, but his conclusion is a bit off the mark.

Yes, SOAP is more complicated than URIs with XML responses, but only if you are the kind of person who hand codes your web services calls. The point of SOAP is that you use higher level languages to call it and to implement it and then it's easier and better and typesafe and all that good stuff.

Many things in SOAP are there to make it easier. WSDL is there so that I can type "google" followed by a dot and immediately get a little intellisense popup telling me what methods I can call. Then I can choose doGoogleSearch from the popup list and get intellisense again prompting me for all the arguments, and I can get little wavy red underlines in my editor if I pass a string where a long was expected.

This is all stuff that makes the API easier to use. The claim that SOAP is bad because the wire format is ugly and hard is like claiming nobody should use Pentiums because their instruction sets are so much more complicated than the instruction set for the 8086. Yeah, it's true, but we have compilers that take care of that, and lo and behold, all those complicated hard things like rings and virtual memory actually make it easier for the many who use compilers at the expense of the few who write compilers.

I think most of the criticism of SOAP can be traced back to a few grumpy language vendors who don't feel like doing the hard work to support it (especially WSDL), or are still living in the archaic land of variants, not intellisense, so they can't really figure out how to do WSDL. Ten years ago, we used variants extensively in our scripting languages (ExcelVBA, JavaScript, perl) because the kinds of novice programmers who were getting their feet wet didn't understand types, and even experienced programmers knocking off quick-and-dirty scripts didn't want to bother with types. Today, when you have a strongly typed language, a good type library (IDL, WSDL, Java reflection) documenting your classes, and an IDE that knows how to show you that type library as you code (i.e. Intellisense), it's even easier to use types than variants, so the trend is away from variant-bound scripting languages (VBScript, PHP, perl) towards typed code (C#, JSP).

Prescod's most valuable point is the performance issue, which happens to matter for Google because they have thousands of servers, but it doesn't matter as much for 99.99% of the web services that are going to be deployed in the real world. (Assuming the post-Web-Services-Hype-backlash doesn't kill us all before then...)

The real problem with SOAP is that it's a completely inadequate remoting system. It doesn't have events (which makes it useless for large classes of applications). It doesn't support references (ditto). It has about 10 years to go before it gets to where CORBA and DCOM were 10 years ago. And we're supposed to be all excited about this because we can sneak through the firewall. Gee, I wonder what the firewall vendors are working on these days? As soon as they're done, we're even further back than we started.

Actually...

The real problem with SOAP is that it's the poster boy for Web Services, which are just the next step in a long line of technologies that has been way overhyped by bored trade rag editors and conference organizers and web pundits. You know that something is overhyped when every stupid VC funded startup feels compelled to change their strategy to get behind the latest flavor of the day. Look at poor KnowNow; with all the hype about Web Services they confused their already muddled and misunderstood message by trying to jump on that bandwagon ... but the Hype Kingmakers at InfoWorld were not falling for it! No Sirree! KnowNow was officially scolded for not being real Web Services.

Attention, young startups: the trouble with jumping on InfoWorld's fake hype bandwagons is that by the time you get there with real products, you'll be smacked in the face by the Tyrannosaurus Rex tail backlash. It's like the VCs who watched the Lycos IPO and suddenly decided to fund portals. By the time the products came to market, Lycos was over and long gone and everybody was ridiculing portals.

Just watch, I predict within three weeks InfoWorld runs out of ideas for Web Services stories and has to run a big spread on how Web Services were "overhyped" and now CTOs are "revolting" against "vaporware."

2002/04/26 26 Apr

I'll be at the Cutter Summit this week.

2002/04/27 27 Apr

The New York Times: "Things are so needlessly complex because featuritis sells products," Dr. Tenner said. "People buy them for a feeling of control, then complain that they are so hard to manage. But show them something simple and rugged, and most of them will call it boring."

Featuritis sells products, but choices reduce usability. The really great designs are the ones that appear to eliminate a choice. You know you're doing your job as a designer when you figure out a way to take a complicated feature and make it simpler. Windows NT has a complete two-way folder synchronization feature hidden behind a single menu checkbox "Make Available Offline." Sometime around 1992, the Excel developers managed to reduce the sorting feature to a single click -- this actually took a lot of work internally, because it has to figure out which column to sort, where the table really is, and whether there are row headings that shouldn't be sorted. Today I'm writing JavaScript client code to make bug editing a little bit smarter in FogBUGZ, which will completely eliminate the Move command for moving bugs from project to project (because you'll be able to just edit the bug to change the project). This takes more code and more validation and I have to make sure it works even if the browser doesn't support JavaScript. It usually takes a lot more code to make a simpler interface.

2002/04/28 28 Apr

Ah good; free high speed Internet access in my hotel room.

Extreme Programming

One of the things that I thought made Extreme Programming inappropriate for shrinkwrapped software was the fact that XP calls for frequent iterations, which is usually interpreted to mean frequent releases. With shrinkwrapped mass market software, you just can't do that. Tech support would become completely impossible if some customers were using Windows May 15, 1998 while other customers had Windows May 16th (Second Release), 1998. There are similar problems with embedded software. You really can't rerelease the embedded software that runs your BMW engine every day or every week.

Picture of Kent BeckTalking to Kent Beck about this today, he pointed out that the simple solution is to do frequent iterations but only release on a longer schedule. Thinking more about this, I think we might move to a model at Fog Creek where a select group of volunteer customers receive very frequent releases in exchange for providing very frequent feedback, while the rest of the world gets far less frequent releases. The nice thing about this is that we can design something, implement it, and realize that the design was wrong and then be able to change it without having to maintain backwards compatibility with the old, "wrong" design (CityDesk customers following the whole URL naming convention switcheroo will understand what I'm talking about, here.)

Some other notable Beck quotes: "The fundamental project management question is: we're halfway through, are we halfway done?"

And on the topic of rolling out XP to a large organization: "It's not divide and conquer, it's conquer and divide." Get your XP teams working right first, then split them and add new people to each half. Building a consistent culture for code development requires that everyone is on the same page. Add people too fast, and you'll find yourself with lots of different cultures, which creates conflict, inconsistency, and problems at the edges.

2002/04/30 30 Apr

Tom DeMarcoToday at lunch I finally got a chance to do something I've been waiting for ten years to do: I sat down with Tom DeMarco to talk about office space. I've been a strong believer in private offices for developers, something which Tom advocates in his bestseller Peopleware. I asked him about how pair programming can be reconciled with private offices; I imagined that a buzzing room full of developers working in pairs would be too distracting an environment to get into flow and stay there. Tom said that groups of people who work in the same style on the same kinds of tasks will not distract each other. Programmers working on the same project would not distract each other; a room full of sales reps who spend most of the day on the phone don't distract each other; etc. You get in trouble, though, when you put a programmer in a room with the sales reps. We generally agreed that if you keep the noise level down and keep the outside interruptions away, it's OK to have an open space floorplan for your development team.

That said, if you're doing pair programming, you're not going to spend more than 3-4 hours a day working with your code buddy. For all the other things you do (phone conversations, design discussions at the whiteboard, etc.) it's nice to have private offices. And when you're trying to recruit superstar programmers they will expect a plush private office. (Just try and get Tom Cruise to make your movie if he doesn't get his own dressing room.) So now I'm envisioning the ideal development interior plan as one where programmers have private offices but they meet in labs with their buddies to get production programming done. No email, phones, or non-programmers would be allowed in the labs. All the non-programming work you do -- design, negotiation, scheduling, reading, thinking, and Tetris -- could be done in your private office.

World's Worst Misinterpretation of The Mythical Man Month

When I read this article by Scott Rosenberg for Salon, I thought it was a complete misapplication of the Mythical Man Month. Reviewing a large body of existing code to find security problems is easily divided up among huge teams of people, and should not suffer from any of the Mythical Man Month problems. The article is just flat-out wrong. The nice thing about being at the Cutter Summit is that I can ask Mark Seiden, one of the world's foremost experts on computer security, if I'm crazy. "You're right," he said, "it doesn't apply. There are no interdependencies to speak of."

Current News >>

Historical Archive

1111 posts over 14 years. Everything I’ve ever published is right here.

1999           Dec
2000  MarAprMayJunJulAugSepOctNovDec
2001JanFebMarAprMayJunJulAugSepOctNovDec
2002JanFebMarAprMayJunJulAugSepOctNovDec
2003JanFebMarAprMayJunJulAugSepOctNovDec
2004JanFebMarAprMayJunJulAugSepOctNovDec
2005JanFebMarAprMayJunJulAugSepOctNovDec
2006JanFebMarAprMayJunJulAugSepOctNovDec
2007JanFebMarAprMayJunJulAugSepOctNovDec
2008JanFebMarAprMayJunJulAugSepOctNovDec
2009JanFebMarAprMayJunJulAugSepOctNovDec
2010JanFebMarAprMayJunJulAugSepOct Dec
2011JanFebMarAprMayJun  Sep   
2012JanFebMarApr  Jul     
2013  MarApr  Jul     

Now that you’ve read all that —

There’s a software company in New York City dedicated to doing things the right way and proving that it can be done profitably and successfully.

Fog Creek Software