Bush on the importance of court orders

Now, by the way, any time you hear the United States government talking about wiretap, it requires—a wiretap requires a court order. Nothing has changed, by the way. When we're talking about chasing down terrorists, we're talking about getting a court order before we do so. It's important for our fellow citizens to understand, when you think Patriot Act, constitutional guarantees are in place when it comes to doing what is necessary to protect our homeland, because we value the Constitution.

That's President Bush, touting the Patriot Act in April 2004. By the time he made that statement, the President had already personally approved warrantless wiretaps at least sixteen times.

It sure looks like the wiretap thing was illegal to the point of showing utter contempt for democracy and the law, not to mention the Constitution, but I'm not a lawyer. Regardless of its legality, it seems very clear that the program sidesteps checks and balances between secret police and the courts and between the President and Congress.

Web services standards rated

It's been a few years since I did any Web stuff. Lately I've been skimming through the new open standards from the past 4-5 years.

My ratings, uninformed by significant experience, on a scale of -4 to 10 (anything 0 or less makes me want to bang my head against the wall).

• XML: 7. Okay, this isn't new, but it's worth talking about how well it's aged. XML scores huge points for usefulness. In hindsight, some of the design decisions were mistakes. As it turns out, the attention to SGML compatibility was misguided. DTDs and external entity references should have been jettisoned. Entity references such as é probably should have gotten the boot, too—get a Unicode-capable editor for crying out loud. CDATA is questionable. Arguably comments should nest, for programmer sanity.

• XML Schema: 3. The things they decided to implement were implemented with intelligence and taste. But. The spec is unreadable and ugly. It's hard to get a straight answer from it when you have a question. It has so many features that complete implementations are rare. Part 1 alone is 195 pages. Some features depend on XPath, which itself is hard to implement; those features should have been put in a separate, optional module. XML Schema has a lot of features that aren't particularly useful, like <xsd:notation>, fixed attribute values, and simple types derived by restriction (other than maybe pattern). It has two of everything, except when it can get away with having three: two different flavors of final; two completely different takes on subclassing (derived types and element substitution groups); prohibited substitutions, substitution group exclusions, and disallowed substitutions (which are apparently three slightly different things); nillable and optional elements.

  The worst part is, XML Schema doesn't solve the right problems. Validating documents is convenient and helpful. But XML Schema goes far beyond validation to provide a thorough type system for XML. There are two major problems with this: (1) the type system doesn't map to ordinary programming languages or relational databases; (2) no API is provided for programmers to access the type information that's supposedly present in schema-compliant documents.

• SOAP: -4. Pointless. Presumably I'm missing something.

• WSDL: 9. Everything a standard should be. Purposeful, simple, easy to implement, readable, concise. It loses a point for refering to SOAP. But you can (and should) use WSDL without using SOAP.

Colts

I meant to say this last Monday before the game, and I meant to say it before today's drubbing started. If Peyton Manning and Edgerrin James stay healthy, I think the Colts are going to have their perfect season. I haven't seen the team that can beat them. They have an offense a geek can really appreciate, by the way. I say Edgerrin James not because he's such a great player, but because their offense banks on flexibility, and James is their running game.

Maintenance costs and software engineering decisions

It's an adage of software engineering that most of the cost of a project is maintenance after the initial development effort. But is this really true?

Organizations certainly don't seem to act like it's true. Software shops tend to discourage refactoring because the perceived short-term cost (in breakage) is more than the long-term benefit (in maintainability). Possible explanations:

1. Software shops are shortsighted. They should refactor more.

2. Engineers don't distinguish between productive refactoring and useless tinkering. Managers can't tell the difference either.

3. A lot of code doesn't benefit from refactoring. Most of the maintenance costs of a project are concentrated in certain areas of the code. The trouble is, it's impossible to tell which areas until you've already shouldered the maintenance load and it's too late.

4. The venture capital model of funding software development has an overwhelming cash flow problem that basically destroys any company that thinks long-term (before it gets to the stage where that strategy would pay off).

5. So many projects fail that the best strategy is to get your project to the point of cancellation as soon as possible. (Too cynical?)

6. Refactoring really works, but it's not the best use of your time. You can outgrow your debt. Invest your time in work that grows your company (like shipping the product sooner). The maintenance costs will seem insignificant tomorrow, as long as you keep growing. (Too optimistic?)

Hmm. Ideas 4, 5, and 6 all suggest that internal software departments in large non-software companies (intranets, accounting systems, that sort of thing) should have better code hygiene than hotshot startup companies. Is this true?