Author: dlambert

I was doing some development recently using Rocky Lhotka's excellent CSLA framework.  This framework lets you easily connect multiple tiers of an application with HTTP Web Services, WCF, Remoting, or Enterprise Services (you can even change transports just by changing your config files - cool!).  In my case, I was using WFC, and I had occasion to change a value in the config file.

The next thing you know, i was looking at this error box (just to be clear, this is a WCF error - not a CSLA error).

Now, in this case, the error message led me right to the source of the problem, so A+ for the efficacy of the error dialog.  D- for the API, though.  If you already know that two values in the config file have to be the same,

[Pause for effect]

Why... are... there...

[Another pause.  At this point, I'd like you to picture Lewis Black belting out this last bit, his outstretched finger pointed toward Redmond and quivering slightly.  If you're not a Lewis Black fan, use Jackie Gleason from Smoky & the Bandit.]

TWO   CONFIG   VALUES???

I'll allow for the possibility that this was lots more cathartic for me than it was for you, but I think you've got the picture.  If you already know the answer, then don't ask me the damned question, ok?  If you already know that both of these config values have to be the same, then one of them has to die.

The point in all this ranting is that API's have usability, too.  If your users are developers, and you do things in your API that frustrate your developer-users, they're not going to be big fans of your product.  Microsoft has traditionally been head-and-shoulders above the competition when it comes to API usability, and I truly believe this played no small part in the rise of Windows.  A better API means developers will enjoy writing for that platform, which implies more apps for users and more success for the platform.

Ignore this rule at your peril, though, because unhappy developers will avoid your platform whenever possible, and you'll soon find you don't have nearly as many people complaining about your API anymore.

Or, you could try this:

It's a popular misconception that if you throw some SOAP, WCF, or J2EE service layers on top of an application, it's automatically easy to integrate.  I place the blame for this misinformation squarely on PHB's and Gartner conferences, because this is simply a case of management by buzzwords.

A good friend of mine used to tell me all the time that the reason we're entertained by a dancing bear isn't that the bear dances well - it's that the bear dances at all.  There once was a time when just being able to talk to a mainframe routine from Java, or talk to Java from .Net, or talk to a routine on one of your partners' computers was a major technical triumph.  Web services made the bear dance, it's true.

Now that we've seen the bear dance, though, we're looking for a few new steps and a little more rhythm.  We want the bear to dance well.  We want quick integration.  We want security.  We want reuse across our enterprises, and yes, Virginia, we want mashups like those kids are doing on face-space, or my-book, or whatever the hell it is they're using.  We drunk the Gartner kool-aid, and we want some of that Web 2.0 stuff, too.

But sadly, integration isn't something you pull out of your Web 2.0 Conference swag bag like a door prize.  You will, in fact, have to know what you're doing to achieve any really meaningful results.  Here are a couple of places where conference-oriented development gets tripped up.

Misconception #1: If we're using web services, no additional effort is needed to make our systems integrate well.

Even though nobody actually makes this claim in black and white, lots of executives (and even some software architects) seem to believe it at some level.  Even Garter will tell you that SOA is a lot of work, but somehow, that's not the message that people seem to internalize.

The truth is that integration on an Enterprise scale is still hard work, and your results are still dependent on planning and execution.  It's true that web services make integration easier than it was in days gone by, but you won't end up on the cover of CIO magazine just because you can spell WSDL.

This may not be a popular point of view, but I believe you've really got to treat integration as a product in its own right in order for it to truly be successful.  The API's you create have users, and that means you've got to consider the usability of your API's just as seriously as you'd consider the usability of a flagship application.  I won't go into detail here on what usability means for an API, but it's really comprised of exactly the same factors as application usability.  If you don't pay attention to the people who are going to use your API, your integration isn't going to be much more successful as an application that all your users hate.

Misconception #2: We can mask our business problems by using web services.

Sorry again.  I've seen this a bunch of times, and it never ceases to amaze me.  If you've got a business problem you can't seem to solve without the benefit of a web service, it's unlikely that a web service (by itself) is going to fix your problem.  Data problems?  If you've got data integrity rules to enforce, a web service is great at enforcing them, but if your data is already messed up and you don't have clear algorithmic rules to fix the data, a web service isn't going to help you very much.

Similarly, if you've got a well-defined business process, a web service may be just the thing to expose that process to other applicaions.  If your business process isn't well-defined, or (worse) if your business users can't agree on a process or other requirements, a web service won't bridge that gap.

Business issues like these really have to be raised up and dealt with in cooperation (at least) with your business leaders.

So embrace SOA and web services, yes.  But don't blindly trust that they're going to fix your problems for you.

It's rare these days that a Web 2.0 startup lands a round of financing, and the funding is completely overshadowed with bad news.  Twitter isn't just shooting itself in the foot - it's mowing itself down with a chain gun.

Problem #1 is uptime, or lack thereof.  Anyone who's been on Twitter over the last month or so has experienced a *severe* up-again, down-again roller coaster ride at Twitter.  Every day, it seems like there's an outage, and some of them have lasted for hours.  I've seen by far more blog traffic about "Twitter's down again" than I've seen talking up the service itself, and that's not good.  Let's not forget that Twitter is still solidly in "early adopter" territory, and they're not going to attract too many mainstream users if the site's down.

Twitter has taken some heat for lack of transparency during this episode, and even that has been entertaining.  They're blogging about what's going on (to some degree), but as a commenter pointed out, they're Twitter for Pete's sake -- Twitter about it!! It's slightly disturbing that this didn't come as second nature to these guys, since this is what they do.  I've also noticed that the manner in which they "splat" is singularly ungraceful.  When Twitter crashes, I see (on my mobile browser) the PHP equivalent to a blue-screen, not a buttoned-down page explaining that there's a problem and someone's working on it.  Here's another take on their error reporting.

Now, I understand that one of the purposes of this round of funding they just landed is to shore up their infrastructure and get some of this stuff ironed out, but I wonder if it'll happen in time.  Fixes for problems like these, in my experience, are a long time in coming, and an infusion of cash today is still months away from paying dividends once you use the money to hire help, buy servers, configure the servers, install the servers, fix the software, test the software -- you get the picture.

But as bad as this all sounds, uptime may not be Twitter's biggest problem.

Read this.

From everything I've seen so far, Ariel's account of events is undisputed and accurate.  Twitter's response is pathetic.  After sandbagging for months, they're now hiding behind the "we're an infrastructure company, not a content regulator" argument.  Totally lame, and totally inadequate.

I'm not aware of anyone who's learned about this and hasn't been outraged, and I'm not aware of anyone who's defending Twitter's response to-date.  Sometimes, stories like this have a grey area where you could argue either side of the story, but that's not true in this case.  Twitter is simply alienating users as fast as this news travels, and it's traveling fast.

The only good part about this story (for Twitter) is that it's taking attention away from their downtime.  As far as silver linings go, that's pretty lousy.

Aside from just condemning Twitter, though, why would we, as software professionals, care about Twitter's agony?  That's easy - we want to learn from their mistakes.

The Ariel Waldman mistake is big and obvious, and the lesson is pretty simple, too: Don't be a jackass.  If there's a problem, acknowledge the problem and meet it head-on.  Don't lube up and try to slither past the problem, because it's going to keep haunting you until you kill it dead.  The stall tactics, the wordsmithing, the "we're just a humble little infrastructure company" line are all just ways to bide time in the hopes that the story will just go away on its own.  How's that working out, Twitter?

The second lesson seems just as simple, but I don't believe it really is.  "Don't build a crummy infrastructure," you say.  Sure, but how?  The data model Twitter provides isn't as easy to model as you might initially believe.  Here's an excellent discussion of what their architecture might look like.  So it's very possible that they're facing some architectural challenges far beyond those most of us see in our careers.

Add to that the startup culture of "features first, then users, then scaling and monitization," and you can end up with a code base that works really well at low volumes, but just breaks apart when you start putting a real load on it.  A friend of mine used to tell me all the time that "the thing that makes you successful today will kill you tomorrow."  In this case, that means that our architectures have to be able to absorb change on a wholesale scale.

I really hope Twitter figures this out and pulls through.  They've got a lot going for them, and they're close to making the leap to the next level, but they need to get with the program in a big way, like *right now* if they're going to pull out of this nosedive.

It's said that the gauge (width between tracks) of American railroads can be traced from bureaucracy to bureaucracy back to the width of Roman war chariots.  It turns out that this is just another urban legend, but if you've ever worked in an organization of any size, you've experienced the organizational inertia that makes this legend so plausible.

I ran into a great one today, for instance.  I'm doing some work in a place where I don't get to set the standards (yes, it's a government agency).  One of the real winners is a standard that mandates that all SQL queries for an application be stored in an XML file, with the queries and their corresponding parameters specified.

I actually learned about this one quite some time ago, and of course, I asked this requirement existed.  This is a proprietary structure, and none of the modern conveniences of .Net development know a thing about this file, so it really slows things down.  The file also tends to grow large and unruly over time, and it's difficult to find anything in it because, again, .Net doesn't know anything about its syntax.

The reason, I was told, is that the DBA's want to be sure that all of the queries for the entire system could be found in a single place so they'd be easy to review and tune.  I bought this, hook, line, and sinker.  I may also be interested in a bridge if you have one for sale.  After paying close attention to the ongoing flurry of intense DBA activity that consistently failed to materialize around this file, though, I began to have my doubts.

So today, I was debugging a really nasty instance of this mess -- a search query.  The "advanced search" screen has a collection of fields that the user can search, and like most advanced search screens, the user only fills in the fields she wants to search - the rest are left blank.  When we search, we query on the fields containing data and ignore the rest.

But that's not how our search works.  Since we've got to store our queries in XML and substitute parameters to alter the queries, we have a huge, awful SQL statement that joins all of the tables that might possibly be used in a search.  Not very efficient, and not certainly not easy for developers.  This mechanism has been difficult, slow, and error-prone since day one.

On top of everything else, the production Oracle servers have really been struggling lately, and the DBA's are looking under rocks for any performance improvements they can find.  Since this bungled search technique is really, really inefficient in terms of database execution speed (in addition to being a gaping black void of development time), I thought I'd run this by the DBA's again.  After all, they'd probably seen the "normal" queries as they're encoded in XML, but maybe they'd never seen one of these search monstrosities, so I asked.  "What's up with the XML file?" I asked.  "Haven't you seen what that does to these search queries?  Haven't you seen all the extra joins we don't really need?  Wouldn't you like those database cycles back?"

Do you know what the DBA said?  "Tain't me that's forcing the XML thing - go find another tree to bark up."

Now, that means that the "architecture people" are blaming the use of this file on the "database people", and the "database people" are blaming it on the "architecture people".

Sigh.

Yes, this is a government agency, but I'd bet you'll run into this in some other places, too, because this is one of the universal truths of organizational dynamics.  I haven't run this one all the way to ground yet, but I clearly should have known better.  I don't fall for "that's the way we've always done it" anymore, but I'm going to have to work on my screwy-reason radar so I don't let another one like this by me.  Pay attention so you don't buy any bridges (or wagon wheels), either.

Just for kicks, by the way, here's a version of the original "chariot wheels" story that claims that the railroads gauge is more than just a coincidence.  You can draw your own conclusions - the XML query file still stinks.

Here's a quick way to add a mobile interface for your web site: Wirenode.com lets you feed in your site's RSS feed or edit pages by hand to create a mobile-friendly site in just a minute or two. Of course, I made one, too.  Give it a try!

I just got a new smartphone - a T-Mobile Wing, in fact, and I like it a lot.  I've never used Windows Mobile for any extended length of time, though, so I'm still learning a few things.  This morning, while trying to figure out what a button did, I caught myself doing something astounding, and I gained a whole new appreciation of affordances.

This phone, if you're not familiar, is a touch-screen smartphone with a slide-out keyboard, so if I'm doing anything remotely complicated, I'm usually using a stylus to point to the screen.  This is sort of interesting all by itself, because in many ways the stylus acts as an interface metaphor for a mouse, which is, in many ways, acting as an interface metaphor for a finger.  It's no wonder parts of the UI are screwed up!

So I was looking at the Calendar - a screen I'd used a few dozen times, and I wanted to move to the next week.  I knew I could go to the menu to do this, but I thought perhaps there was an easier way to get there (I've been finding all sorts of those while learning to use this phone).  There was a little button on a little toolbar, and I didn't know what the button did.  So I took my stylus and held it still, poised a few millimeters above the touch-sensitive screen.

I was waiting, obviously, for the tooltip that never came.  I expected the button (especially a toolbar button), to have a tooltip.  This is an affordance of toolbar buttons, and my misguided gesture was a failed attempt to exercise this affordance.

There are several interesting observations to be had here, beyond the obvious, "Dave's a moron" one.  Here are a few that sprang to mind:

• In the week or so I've had this device, I've adopted the stylus as a seamless analog to a mouse, to the extent that I don't differentiate the things that one can do that the other can't.
• As users gain experience and UI metaphors grow in penetration, they become their own UI "primitive".  If I hadn't been using toolbars with tooltips on their buttons for the last (mumble, mumble) years, I would never have been conditioned to look for them on a new interface.
• The smartphone (and the Windows smartphone in particular) is a horribly difficult device to support as a developer.  I've been quite aware as I've used this interface that some of the actions I perform with a stylus would be really difficult to support well on a phone without a touch-sensitive screen, and yet you see a lot of applications try to support both platforms with one version of software - a pretty tall order if your interface is non-trivial.  The whole portait-to-landscape pivot every time I pop our my keyboard would be enough all by itself to make this difficult.
• Given the above, I think you have to tip a hat once again at Apple for the design of the iPhone.  Granted, their tight control of the whole hardware-software platform is the only way that this is possible, but I think it's still great execution.  This format is *not* easy.

Finally, from a design standpoint, this underscored for me the need to obtain real-world usability information about a system.  I'm no Alan Cooper, but I'm better than your average bear at UI design, and I never would have seen this one coming if I hadn't done it myself.  It's just too hard to relax all of your preconceptions and pre-loaded context when you're designing a user interface.  Real-world usage of a system will almost always turn up a few gems like this.  If you don't know about them, it doesn't mean they're not happening - it means you need to get your head out of the sand and pay attention to your users.

Here's a useful little chunk of code to put in your toolbox.  I need to display file sizes to users, and I want to format the displayed file size as you'd see it in Explorer -- 10.1 KB, 23.31 MB, and so on (not 112230103 bytes, for example).  After a quick google search, I turned up a post on forums.asp.net that got me really close.  I cleaned up a couple of issues and built a unit test to make sure things were working correctly, and it's ready to go.  Read on to see the working code.

///
/// Format bytes suitably for display to user (ex: 12.3 KB, 34.41 MB).
/// If you need to handle sizes > Exabyte size, you'll have to modify the
/// class to accept ULong bytes and format accordingly.
/// Based on code as published here: http://forums.asp.net/t/304193.aspx
/// By Bart De Smet -- http://bartdesmet.net/members/bart.aspx
/// Algorithm fixed to handle KB correctly and modified to use Long
/// instead of int to handle larger file sizes.
///

public struct FormattedBytes
{
#region ctor
public FormattedBytes(long size)
{
_bytes = size;
}
#endregion
#region Bytes property
private long _bytes;
///
/// Get or set bytes.
///

public long Bytes
{
get { return _bytes; }
set { _bytes = value; }
}
#endregion

public override string ToString()
{
double s = _bytes;
string[] format = new string[] {"{0} bytes", "{0} KB",
"{0} MB", "{0} GB", "{0} TB", "{0} PB", "{0} EB"};
int i = 0;
while (i < format.Length @@ s >= 1024) {   //replace @@ w/ ampersands
s = (long) (100 * s / 1024) / 100.0;
i++;
}

return string.Format(format[i],s);
}
}

And here's the unit test I'm using to test the routine:

///
/// A test for FormattedBytes ()
///

[TestMethod()]
public void FormattedBytesTest()
{
FormattedBytes bs = new FormattedBytes();
Assert.AreEqual("0 bytes", bs.ToString(), "FormattedBytesTest - incorrect value (1).");
bs.Bytes = 10000L;
Assert.AreEqual("9.76 KB", bs.ToString(), "FormattedBytesTest - incorrect value (2).");
Assert.AreEqual("1.17 MB", new FormattedBytes(1230000L).ToString(), "FormattedBytesTest - incorrect value (3).");
Assert.AreEqual("434.87 MB", new FormattedBytes(456000000L).ToString(), "FormattedBytesTest - incorrect value (3).");
Assert.AreEqual("73.48 GB", new FormattedBytes(78900000000L).ToString(), "FormattedBytesTest - incorrect value (4).");
Assert.AreEqual("1.11 TB", new FormattedBytes(1230000000000L).ToString(), "FormattedBytesTest - incorrect value (5).");
Assert.AreEqual("1.09 PB", new FormattedBytes(1230000000000000L).ToString(), "FormattedBytesTest - incorrect value (6).");
Assert.AreEqual("1.06 EB", new FormattedBytes(1230000000000000000L).ToString(), "FormattedBytesTest - incorrect value (7).");
}

Last time, I hinted that there was more than Google-phobia driving this attempted purchase, and there is.  In addition to vaulting overnight to a relevant search power, there are a few other areas where a combined company would become a real market force.

Go read the article - there are more traffic numbers there.  My point is that when Yahoo! still has the eyeballs and the clout to swing traffic like this, they're a jewel worth getting excited about.

Of course, Microsoft would have their work cut out for them.  The mere fact that despite all this traffic, Yahoo's financials have lagged expectations begs the question of how Microsoft could improve on that performance.  There's also the issue of culture.

Detractors of the Microhoo deal believe that Yahoo's open culture is going to clash mightily with Microsoft's, but I think they're wrong.  I've seen a big change in Microsoft over the last few months.  There's a greater embrace of openness than they've ever shown, and it's taking root and flourishing.  Microsoft is ready for Yahoo's sort of culture, and I really think there are parts of Yahoo! that could stand a little infusion of Ballmer's enthusiasm - maybe even a swift kick.  This could be a pretty cool partnership.

Anyone not living under a rock knows that Microsoft is trying to buy Yahoo!, but so what?  What difference could it possibly make to an end-user or a software developer whether Yahoo! remains independent or not?

Clearly, this is a buyout of historic proportions.  The size alone is impressive: at $45B, this is a serious chunk of change and a sizable improvement over the market valuation of Yahoo! prior to Microsoft's offer.  But this buyout isn't notable just for size.  This is a pivotal moment in the growth and maturation of the net: a marquis player is quite possibly going to cease to exist independently, and another is at a "make or break" moment.  As far as brands go, this is an impact on the order of seeing Netscape fade away or AOL get gobbled up by Time Warner. Like AOL, it's quite conceivable that the brand will live on for a long time, but it's clear that it'll never again live with the vigor that it's had in the past.

So just like that, Microsoft is set to gobble up Yahoo!, and the giant from Redmond marches inexorably onward, right?  Not so fast.  Remember how that AOL / Time-Warner deal worked out?  Other industries have shown us the dangers of mega-mergers, as well - Sprint / Nextel has been in the news a lot lately as Sprint slowly continues its death spiral.  Most analyses of Sprint's current woes begin with theNextel takeover and end with gigantic accounting charges to reflect this failure and a mass exodus of (mainly ex-Nextel ) subscribers.  These failures can't be overlooked; Microsoft could catch a world-class case of indigestion if they're not careful.

So why is Microsoft doing this?  Nobody's holding a gun to Ballmer's head, right?  Or are they?  Conventional wisdom holds that Microsoft is making this move strictly out of fear of Google.  Microsoft is trying to buy search traffic (and the associated advertising revenue) because they haven't been able to capture that market share directly.  There's more to it than this, of course, and I'll go into a little more depth in a future post.

In the mean time, keep watching the developments in this buyout, because win or lose, this battle is going to change the face of software.

Alan Greenspan's in the news again after he was quoted as saying the current economic meltdown Is "the most wrenching since the end of the second world war."  Now, I know this isn't directly related to software design, but since I've got a degree in Finance, I can't help watching this train wreck, and let's face it - this "situation" has now reached the point where it's impacting the economy as a whole, including software.

I'll be honest - I don't think it's too beneficial for Greenspan to be skulking around the funeral parlor right now offering commentary on the medical care of the deceased. This man was single-handedly responsible for the most prolonged, sustained, and stable economies in the history of this country, and for that, we're all eternally grateful.  But he's got to realize that he's still incredibly quotable, and the best thing he can do for the economy right now is to just shut up and let the Fed work.  You don't see Bill Gates offering opinions to the Wall Street Jounal about how Ballmer's doing, and I'll bet you won't see Favre giving interviews next year about the play of their new quarterback, and we don't need to hear from Greenspan about how the economy's doing, either.  I know this is the way politics is done - look at the way Bill is campaigning for Hillary.  But Greenspan was always above that, so to see him doing this now is disappointing.

Finance, of course, suffers from its own case of jargon overload, so if you're looking for a really clearly-spoken commentary on our current mess, check out this interview with Princeton economist Paul Krugman.  It's light on financial jargon and deep on content, including a really interesting jab at Greenspan about what he might have done to limit the severity of the subprime mess.

P.S.: