Five Worlds: not all software development is the same.

PS. There is a large grey area between internal, consultingware, and shrinkwrap – the three worlds are often a continuum. Often products start out as internal products, then the business guys have the bright idea of selling it to other companies, but it is so brittle and makes so many assumptions about its environment that it takes weeks to install it at other customers’ sites, which is how consultingware is born. (cf. Vignette StoryServer which started as c|net’s inhouse content management system and now costs millions to get running.) Theoretically the software should then migrate towards shrinkwrap as the customer base grows, with increasing emphasis on ease of installation, but these companies get so addicted to their consulting revenue they don’t see any benefit in making it easier to use off-the-shelf. And many internal developers have no prior experience with making software run in the wild, so it doesn’t.

Why Religious Wars are Stupid

Yesterday I made what I thought was a lightweight claim about how the “choice” of languages in .NET is not as much of a choice as you might think.

Some people assume that this means I am against .NET, or I’m “clueless,” because I don’t understand the productivity benefit of managed code.

OK, they didn’t read what I wrote less than a month ago praising the productivity of .NET.

Of course, when I wrote that, some people assumed it meant I was for .NET, and dug up an old article from two years ago in which I complained that an early white paper on .NET didn’t say anything. (It was true, the white paper didn’t, and .NET didn’t ship for 2 years). So I’m a hypocrite because I used to be against .NET and now I’m for .NET.

Anything as complicated as .NET is bound to have many positive aspects and many negative aspects. Duh. The stupid thing about religious wars is when one person says, “you don’t get as much language choice as you think” and the other person says, “you are clueless, because you’re 4-6x more productive!” What a waste of time.

The World Is Complicated. Get Used To It.

Some people can’t. Look at how angry Michel gets because I point out that (a) features sell products and (b) choices reduce usability. So? The whole point of design is that you have different goals that you need to resolve. Want to design a trashcan for street corner? You have to make it light so it can be emptied easily. You have to make it heavy so it won’t blow away. You have to make it big so it will hold lots of trash and the trash won’t blow out. You have to make it small so it won’t take up too much space. You have to make it easy to throw trash in so people don’t miss and litter. You have to make it hard for trash to get out so when it’s windy the street doesn’t litter itself. Design is all about making hard choices and, hopefully, sometimes, hitting upon elegant solutions that solve conflicting goals. But when you can’t solve conflicting goals, you have to be smart enough to decide which goal to solve, and not just be a lazy punter and pretend that adding a checkbox to the options dialog will solve it.

Boom

Don’t use Verisign. They suck, and there’s no reason to use them. I’ve been using register.com for domain names (although namebargain.com is cheaper and run by register.com with the same excellent interface) and Commercelock, also run by register.com, for digital certificates. Commercelock is actually provided by Baltimore Technologies which charges a heck of a lot more for exactly the same thing.

Why do developers choose one programming language over another for a given task?

Sometimes I choose raw C when I need blazing speed.

When I want something that will run on Windows with as small a distribution as possible, I often choose C++ with MFC statically linked.

When we need a GUI that will run on Mac, Windows, and Linux, a common choice is Java (although the GUI will not be perfect, it will work.)

For rapid GUI development and really smooth UIs, I like Visual Basic, but I know that I’m going to have to pay the price in the size of the distributable and the fact that I’ll be locked into Windows.

For a command-line tool that must run on any UNIX machine and doesn’t need to be fast, perl is a good choice.

If you have to run inside a web browser, JavaScript is the really the only choice. In a SQL stored procedure, you usually get to choose between one vendor’s proprietary SQL derivative or go home.

What’s the Point?

But I hardly ever choose a language based on syntax. Yeah, I prefer the {}; languages (C/C++/C#/Java). And I have lots of opinions as to what makes a “good” syntax. But I wouldn’t accept a 20 MB runtime just to get semicolons.

Which makes me wonder a bit about .NET’s cross-language strategy. The idea is, choose any language you want, there are zillions, and they all work the same way.

VB.NET and C#.NET are virtually identical except for tiny syntactic differences. And other languages that want to be part of the .NET world need to support at least a core set of features and types or they won’t be able to Play Well With Others. But how do I develop a UNIX command line utility in .NET? How do I develop a tiny Windows EXE in less than 16K in .NET?

It seems like .NET gives us a “choice” of languages precisely where we couldn’t care less about it — in the syntax.

Today 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.”

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.

Talking 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.

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.

I’ll be at the Cutter Summit this week.

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.”

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.