Category: Uncategorized

Lipstick on a pig

If you’ve ever seen one of my project plans, there’s a chance you’ve seen a task at the end that says Add pretty. With good use of stylesheets, you can radically improve — or damage — the look of a website even after all the coding and most of the testing are done. A different person or group with a different skill set can take over from the programmers and work some magic with little interaction.

You might think, based on this, that other parts of development can be pushed to the end after “real” development is done. You’ll know someone was thinking that when you see a task late in a project plan that says “Add fast”. This is usually a sign of excessive specialization. People think that they just have to get the user interaction right and leave performance tuning to someone else.

I suppose I can live with the idea that there will be some performance tuning that’s best done once everything else is complete. And on some projects just throwing more hardware at the problem is cheaper than a programmer’s time to fix it. But actually improving the performance of an application is hard, and the changes pervasive.

Another side-effect of excessive specialization, one that always raises the brown flag, is when I see “Add security” at the end of a plan. It’s simply inexperience that allows anyone to think they can graft a security model onto a codebase after the fact without significant amounts of rewriting.

“But this is a quick hack, and we only need the numbers for this one meeting.” Sure, a report you’ll only ever need once. I guess such a thing could exist, but I’ve never seen it. In the first place, nothing lasts as long as a temporary fix that works well enough. And in the second place, many (most?) large, successful products started out as small, successful products.

End/begin dependencies look really great on a Gantt chart. Activities that invite and incorporate feedback don’t look so neat and clean. Treating security as something that can happen to a product after it’s already done is no better than … well, see the title of this post.

The Digital Dark Ages

I’ve been paying my mortgage for about three years now. Unless I change something, I’m going to keep paying on it for another 27 years. I try not to think about the fact that although I have an actual physical copy of the mortgage agreement, with real pen-and-ink signatures, I don’t have any proof that I’ve ever made a payment.

At the risk of sounding like a Luddite, it bothers me that I have to trust the bank’s computer system to keep track of all 360 payments I’ll have made by the time it’s over. I’m not just being paranoid. I had an issue where a bank said my wife still owed money on a loan we had paid off three years earlier. We didn’t have anything in writing for each payment. The bank couldn’t even tell us the history of the loan; just that the computer showed we still owed money. And if a bank says you owe money, unless your lawyers are bigger than their lawyers, then you owe them money.

If you go to museums, you’ll see ledgers from banks in the 1800s and earlier. Over two hundred years later and we still know who paid their bills and when. But five years in the past … it doesn’t exist.

This could change with new regulations and retention requirements. But the big difference is what is standard vs. what you have to work at. A hundred years ago everything was written down. If you wanted to get rid of records you had to make an effort to identify what you wanted to delete, somehow separate it from the rest, and physically destroy it. Today, we only keep data as long as we have to. We only bother with long-term storage when the law or financial necessity makes us.

Let’s assume we have some data that we really want to keep “forever”. What is that going to take?

First, you’ll want to store it on something that doesn’t degrade quickly. Burning it to a CD or DVD seems to offer better longevity than VHS. Well, maybe. Second, you want to store it in a format that you’ll be able to read when you want to. This might be a harder problem than the physical longevity, when you start to consider how much data goes into a modern file format.

Look at the problem from the user’s perspective: The document format (the same applies to music and video) is just a way of saving the document in a way that it can be opened and look the same way at a later time, maybe on the same computer maybe not. When Windows 97 handles table formatting and text reflow around images a certain way for instance, the document format has a way of capturing the choices the user made.

If I open that Word 97 document in Word 2003, either the tables, text and images look the same or they don’t. If they look the same, it’s because there’s an import filter that understands what the old format means, and Word 2003 has a way of representing the same layout. If I then save as Word 2003, while the specific way to represent the layout has changed, the user doesn’t see the difference nor care.

If, on the other hand, that Word 97 document doesn’t look the same in Word 2003, it really doesn’t matter to the user if problem is a bad import filter or if Word 2003 doesn’t support the same features from Word 97. (Maybe they used flame text.) So a format that technically captures all the information needed to exactly recreate a document is utterly useless without something that can render it the same way.

Okay, so we need long-term media, and we need to choose a format that is popular enough that there will still be import filters for it in the foreseeable future. Eventually we’ll still reach the end of those paths. Either the disks will degrade, or the file format will be so out of date that no one makes import filters any more. When that happens, the only way to keep our data will be to copy it to new media, and potentially in a new format.

What should that format look like? We’ve already got PDF, which is based on how something looks in print. We’ve got various audio and video formats, which deal with playing an uninterrupted stream. But what about interactive/animated documents designed for online viewing?

Believe it or not, I’m going to suggest a Microsoft solution, though it’s one they haven’t thought to apply this way: PowerPoint. Today nearly everyone has a viewer, but not so long ago most of the slideshows I got were executables. If you had PowerPoint installed you could open the executable and edit the slideshow the same way you can edit a PDF if you have Acrobat.

As much as people complain about the bloat that Word adds to simple files, I think the future of file distribution will be to package the viewer along with the file. At some point storage becomes cheaper than the hassle of constantly updating all those obsolete file formats. The only question is how low a level the viewers will be written to: OS family, processor architecture, anything that runs C, etc.

Meet the new boss, same as the old boss

In case you haven’t noticed yet, we’re going through another round of power struggles in the IT industry. Oh, that might not look like what’s going on. On the surface what people are saying is that it’s a matter of web-based vs. desktop applications. Frequently these conversations are based on the premise that it’s a discussion of the technical merits.

Nope. It’s the return of the glass house. Peel back all the rationalizations about easier deployment, easier support, more consistency, and what it really comes down to is more control. If we can just keep the software out of the users’ hands then everything will be okay.

But what history shows us is that users like having control of their “stuff”. Taking that control away requires either redefining “their stuff” to be “our stuff”, or convincing them that they aren’t qualified to handle their stuff.

Is this what your customers are hearing from you?

Maybe I’m the one missing something

Magicians make a living at misdirection, getting you to look at their right hand while they’re hiding the ball with their left hand. You’d think journalists would want to be a little more direct than that. But Neil McAllister did a whopper of a slight-of-hand recently, using more than half his column to summarize a Joel Spolsky post before jumping to a completely unrelated conclusion.

Joel’s point, and the first more-than-half of Neil’s summary, was shooting down the idea beloved of suits that programming can be reduced to a set of building blocks that can be snapped together by a non-programmer. (For a hysterically painful example of how wrong this is, and how far people will go to try to do it anyway, see The Customer-Friendly System at The Daily WTF.)

Joel covered the ground pretty well, so I was wondering where Neil was going with this. Once I got to it, I had to re-read the segue three times to see what connection I was missing:

Don’t you believe it. If, as Brooks wrote, the hard part of software development is the initial design, then no amount of radical workflows or agile development methods will get a struggling project out the door, any more than the latest GUI rapid-development toolkit will.

And neither will open source. Too often, commercial software companies decide to turn over their orphaned software to “the community” — if such a thing exists — in the naïve belief that open source will be a miracle cure to get a flagging project back on track. This is just another fallacy, as history demonstrates.

If there’s a fundamental connection between open source and “Lego programming” I don’t know about it. Maybe Neil makes the connection for us:

As Jamie Zawinski recounts, the resulting decision to rewrite [Netscape’s] rendering engine from scratch derailed the project anywhere from six to ten months.

Which, as far as I can see, has nothing to do with the fact that it was open source. In fact it seems more like what Lotus did when they delayed 1-2-3 for 16 months while they rewrote it to fit in 640k, by which time Microsoft had taken the market with Excel. Actually that’s another point that Joel made, sooner and better.

Is Neil trying to say that Lego programming assumes that code can be interchangeable, and man-month scheduling assumes that programmers are interchangeable? Maybe, and that’s even an interesting idea. But that’s not what he said, and if I flesh out the idea it won’t be in the context of a critique of someone else’s work.

Or maybe it was an opportunity to take a shot at the idea of “the community”. Although in his very next column he talks about the year ahead for the open source community, negative community reaction to the Novell/Microsoft deal, and praise from the community for Sun open-sourcing Java. Does he really dispute the existence of a community, or was it hit bait?

Okay, so where did I start? Right, with misdirection. So the formula seems to be: quote a better columnist making a point that I like, completely change the subject with the word “therefore”, summarize another author making my second point, and send it to InfoWorld. Am I ready to be a “real” pundit yet?

Here’s a crazy thought

Corel should sue people who use Photoshop without paying.

Huh?

Think about it. Graphics professionals pay for Photoshop. Lots more people do some graphics, but not enough to be worth $650. But many of those people possibly would agree that their use is worth $80.

So there are probably people using cracked copies of Photoshop who, if they didn’t have the crack, would instead have bought Paint Shop Pro.

It seems reasonable that if we’re going to report losses to “piracy” in terms of lost sales, we should be counting the potential sales that are really lost.

Writing a test approach

If this is the first time someone has asked you to produce one, it’s kind of an odd exercise.

First, recognize that you have some pretty significant prerequisites, and second that you have to consider multiple audiences. But what it all comes down to is making sure that the application does what it’s supposed to do.

The prerequisite comes from needing a good definition of “what it’s supposed to do.” I wish this were as easy as it sounds. Look at how much is written about whether/how to write specifications to see what you’re up against.

Once you have a good spec, you have two questions to answer. It’s really the same question answered for two audiences, but the answers can be pretty different: How do you ensure that it does the right thing; and how do you demonstrate to your client that it does the right thing?

Answering the first question will involve unit testing, regression testing (for upgrades), creation and execution of test scripts, etc. It’s possible a large part of the execution will actually be done by the developers.

Answering the second question — satisfying the client — requires that you talk in terms of: user interaction, use cases, end-to-end scenarios, scalability/performance/load testing, support and training needs, etc.

Imagine you are presenting a sales pitch to a client, and you need to describe how you will demonstrate the value and correctness of your application. Write a narrative proposal, eg:

Working with end users and subject matter experts (name names if possible), we will define use cases that describe the expected functionality of the application. This process should take X hours of the users’ time over the course of Y days.

These use cases will be executed and verified by someone, using volume of data extracted from source. Developers will also create automated scripts to be executed on toolname, simulating how_many concurrent users executing how_many transactions per second for how_long.

You’re not trying to actually write the test scripts yet. Start out with the higher-level description of what types of testing you expect to do, and who is responsible for writing and executing each type. Theoretically you may not know the performance figures in that second paragraph, but I find it’s better to put some numbers in front of the stakeholders and let them disagree.

Can someone give me the name of a good buggy whip maker?

No really, I want to talk to one. There should be several in every large town, just like there used to be. Because it would be immoral to deprive them of their “right” to make money in the way that they want to.

“But that’s absurd,” you say, if you’ve never heard the argument before. “You’d have to outlaw cars to protect the buggy whip manufacturing business.” Yes, and that’s exactly what the buggy whip makers tried to do: ban the car.

Copyright does the exact same thing buggy whip makers tried to do: it protects a specific business model. The “right to control copying” exists to encourage people to go into the business of creating new works.

We, as a society, benefit from having new works. We have agreed to grant creators of those works a temporary monopoly on reproducing and selling those works. If the specific method that we’re using to encourage creation actually serves to restrict creation, our method needs to change.

Everyone who thinks the RIAA is responsible for increasing the net creative output of the world, raise your hand … Everyone who thinks the MPAA is the creative force behind independent film, raise your hand …

Copyright law was a specific solution to a specific problem. It doesn’t codify some inherent human right. If the “solution” has been pushed too far in one direction, which I believe it has, it’s time to re-think the balance. Or maybe come up with some new way to encourage creation of easily-copied works.

Apples and Oranges …

… are actually pretty damn similar.

How did “like comparing apples and oranges” get to be our standard phrase for indicating that two things are so different as to resist comparison? They’re both fruit, typically about the size of a baseball, have a skin and seeds, are mostly water. There are more similarities than differences.

I assumed there was some history to this phrase, some context where it made sense. The only thing I can find is a one reference suggesting, “that the phrase appeared as apples and oysters in John Ray’s proverb collection of 1670.” Okay, that makes a bit more sense. Or at least it works better for what people mean when they say it.

But I suspect it’s more like the phrase, “You can’t judge a book by its cover.” Really? Put a Unix textbook next to a Harlequin romance and I’ll bet I can tell you a whole lot about it. That phrase originated in a time when all books were printed with blank bindings, and covers could be applied by the seller or the customer. So back then no, you really couldn’t tell a book by its cover.

No one cares about “average”

No one wants to be average. We just want to treat everyone else like they are. That’s why we generalize, form stereotypes. It leads to goth and emo, as kids try to be unique and different from average people … but in exactly the same way as everyone else in their preferred group. (Oops, was that cynical?)

It also leads to being pretty spectacularly wrong in your conclusions, even when you’re completely right in your premises. Take for instance what Joel Spolsky had to say about OSS development:

Development [on OSS projects] is much more likely to be geographically dispersed, which results in a radically different quality of team communication. It’s rare in the open source world to have a face to face conversation around a whiteboard drawing boxes and arrows, so the kind of design decisions which benefit from drawing boxes and arrows are usually decided poorly on such projects.

His premises are correct: development is often dispersed; design can suffer. His conclusion, that OSS projects usually just clone existing (closed source) software is not technically wrong, but is irrelevant for the same reason traditional media is wrong when they discount blogs as “real writing”: The average doesn’t matter. If the best blog — or the best OSS product — is better than the leading commercial media or closed software, it will gain market share.

As Paul Graham says:

Those in the print media who dismiss the writing online because of its low average quality are missing an important point: no one reads the average blog. In the old world of channels, it meant something to talk about average quality, because that’s what you were getting whether you liked it or not. But now you can read any writer you want. So the average quality of writing online isn’t what the print media are competing against. They’re competing against the best writing online. And, like Microsoft, they’re losing.

The “average” application on SourceForge may be derivative and just plain bad, but you don’t install averages. You install applications. I don’t use an “average browser”, I use Firefox.

This holds true for games, too. As a Slashdot poster says of open-sourcing a game:

we will see millions of variations of modifications that will be incompatible with each other and that will bring down the quality of the game. Some will be much worse than the original, probably few will add high-quality content, but some may become very good indeed.

Software, writing, games, in fact all digital media, tend toward a winner-take-all outcome. In the age of infinitely-reproducible goods, it doesn’t matter what process yields the best average outcome. What matters is what process yields the single best outcome.