Oh boy, this sort of thing really fills me with confidence:
Even better though, there's no Cancel button (aka "Just Say No")... It's like the worst kind of software registration dialog:
"Please may we spam you with daily special offers and sell your details on to a slavering army of evil third-parties, some of whom have wings and fangs?
Yes | Remind me again in 30 days"
Here's my latest article at The Register:
The latest incarnation of Visual Studio had a difficult gestation, with critics pointing to the slowness and instability of the beta release...
... This isn't just a criticism leveled solely at Visual Studio; it's against all the modern IDEs out there - VS in day-to-day use is not so different from what we were doing with the first version of Visual Basic 19 years ago. Somehow, Microsoft managed to fatten Visual Studio up to porcine levels and yet using the product feels like you're trapped in the 1990s.
Java IDEs suffer from the same problem, to an extent. IDE evolution has become a game of feature creep, each new release touting bold new features, drawing in concepts well outside an IDE's core competency - half-baked UML support springs to mind - and packing it all into a single frame. The notion of "doing one thing, and doing it well" has been laughed out the window.
And the reason for this stagnation of innovation in the IDE space? The industry leaders have become portly, comfortable, and middle-aged. Eclipse is smoking its logical representation of a pipe, content to let plug-in developers pad out its ecosystem. NetBeans plays perpetual catch-up while its fate is decided for it. IntelliJ no longer sells itself on productivity, having fallen into the "feature checklist" trap.
The time is ripe for a brand-new contender to stroll in with something fresh and steal developer mindshare from beneath the leaders' pipe-yellowed moustaches - just as a young Eclipse once did to NetBeans.
The bubblicious Code Bubbles IDE could be just that new contender. It puts a leash around Eclipse to do the donkey work for it, but invents an entirely new front-end so that programming becomes more like playing with Matey in the bath. A prototype from Brown University in New England and video about Code Bubbles has passed the frothy developer test, with viral emails flying around the workplace.
A user story is not a use case.
That might seem as obvious as saying "A door is not a cat", but there's enough scope for confusion - not just in the similar names - that user stories and use cases are often used interchangeably (when describing what to do next in a software project) when they probably shouldn't be.
Alistair Cockburn sums it up nicely: A user story is to a use case as a gazelle is to a gazebo.
But also:
A user story is not a story.
In other words - this is not a user story:
"The user types in a story and clicks Submit. The system publishes it to the website so that other users can read it."
It's really a use case. But it also doesn't help that there are many definitions of "use case", and many opinions on how much detail should go into one. But generally, the one consistent aspect of a use case is that it's a narrative: a description of a user's journey through the UI, and the system's responses as he clicks and types his way along: "The user does this or that; the system displays XYZ data in response. Next, the user does this... etc." In other words, the text of a use case is really a story.
A user story, meanwhile, is anything but a narrative. And this, I think, is the main source of the confusion. The name "user story" implies a story - a narrative. And it really doesn't help matters that the name is often shortened to "story". But a user story is anything but a story - at least in the narrative sense. I could see people starting to call narrative-based requirements "stories", but it's a false etymology, as they say.
Continue reading "User Story != Use Case - but User Story != Story, Either" »
My latest article at The Register:
The biggest coup for JavaFX three years after its unveiling at JavaOne is its integration into Vancouver2010.com, in a spinning-wheel app that shows countries' medal counts dating back to 1924. It's a nice use of data visualisation, a cross between tag clouds and a time-traveling version of Risk. But oh my word, the jaggedness of the text. Don't these people know that Java can do antialiasing very nicely? Even the "Powered by JavaFX" logo has embarrassing color bleed.
The Winter Olympics app is a rare moment of fame for JavaFX, in an otherwise bleak and underperforming history. The brazenness of JavaFX.com suggests otherwise. It's all flashing lights and bold headlines, as if the marketing team are standing around Frankenstein's [monster's] corpse sending shockwaves of electricity into it and insisting: "Look! Look! It lives! No, really, it does!"
Read more...
... Firefox can be made to look just like it.
Let’s face it, we’re all shallower than we like to admit when it comes to our web browsing experience. The web itself is mostly words and pictures painted across a million miles of surface gloss. Of anyone who tried the beta of Google’s Chrome browser, I bet you all initially rushed to install it because of the concept of each tab running in an isolated sandbox, and the prospect of V8, the powerful new JavaScript engine... but what really wowed you about Chrome when it revved onto your screen? Yep, its cool streamlined appearance. Don’t know about you, but that more than anything tempted me to switch from Firefox and make Google’s stealthy new beast my main browser.
The isolated processes stuff sounds important, but it solves a problem I didn’t know I had (aside from Firefox eating up resources and needing the occasional restart). And the other touted big advantage of Chrome, its faster JavaScript engine, may already have been left in the dust by Firefox's in-the-pipeline TraceMonkey engine. So for all the hype and excitement (which has admittedly died down considerably now) around Google’s new browser, what’s the main attraction of Chrome? Its looks.
Continue reading "What I like most about Google's Chrome is..." »
Sun Microsystems recently released the JavaFX Preview SDK. I decided to revisit what is Sun's last, best hope to recapture both the desktop and the browser in the face of stiff competition.
The big question with Java FX is why anyone would want to adopt it when they've already got Adobe Systems' Flex and Microsoft's Silverlight, which is doing rather well in presenting the Beijing Olympics.
On paper, the most compelling feature could be the most difficult one for Sun to pull off: the ability to run the same JavaFX app unaltered on both Java Standard Edition (Java SE) and Java Micro Edition (Java ME) runtimes.
To achieve this, Sun is taking a Laszlo-like approach - Laszlo allows the same program to run in the browser using a JavaScript base or a Flash base. The Java SE runtime renders using Swing components, for example. It would truly be a top achievement from Sun if the same JavaFX program could run unaltered on your mobile phone and desktop.
Whether this pseudo-multi-platform approach turns out to be practical in the long run is another matter. Any program of a significant size is bound to step outside the rosy JavaFX garden and make use of the "core" Swing and Java APIs, shackling it to your desktop. We won't find out to what extent Sun can achieve their lofty ambition until Java ME support appears, which at the last estimate is Spring 2009.
Here's part two of my look at the Rich Internet Application world that JavaFX is being breach-birthed into:
Sun Microsystems lost the first Rich Internet Application (RIA) war when Macromedia (now part of Adobe) ate its applets for lunch following a schoolyard brawl. Now Sun has a second chance.
But, to succeed in such an unforgiving market, Sun needs something special. A mature, powerful platform, a buzzing community, some seriously talented people with an eye for visual design, and some butt-kicking WYSIWYG tools so that non-programmers are invited to the party as well.
JavaFX ticks some of these boxes, and it has tools on the way. These tools, though, are going to make or break its chances. And they're a little late, to be honest. Spring 2008 was mentioned for the visual development environment. Spring has given way to glorious summer.
[...] If Sun's goal is to compete with Adobe's Flash or Silverlight from Microsoft, then a Matisse-based visual editor should have been one of the first toys to be pulled out of the box. It should be right at the center of the rich client development experience rather than a "potential add-on some time", leaving third-party vendors to pick up the slack. [...]
Over at The Register I wrote about my recent experiences playing with (whoops, evaluating) JavaFX. (Note this is part 1 of 2 articles). Judging by the comments, and also comments from the folks in the JavaLobby community, the article's being read as "This guy's saying that JavaFX is doomed already."
Yes in a sense, if the project remains on its current course. A pretty major problem is that Flex, already at version 3, is leaps and bounds ahead. But Flex also happens to be more well thought out.
One example that I don't mention in the article is with stylesheets. Whilst trying out JavaFX, I found myself thinking: "It would make so much more sense if these components could be styled using a separate CSS file."
Sun lost the first round of the Rich Internet Application (RIA) battle to Macromedia (now part of Adobe), when Flash outshone Java applets. At the time, applets were ugly and slow to start up.
Now, Sun has a second chance with its promising new hybrid offering, JavaFX. This time, though, the competition is fiercer, and the prize arguably much greater: ownership of the mobile web – rich, collaborative computing on the move. (JavaFX Mobile will of course help rather a lot here). To even participate, let alone win the race, JavaFX applications need to look good with a minimum of effort.
So it worries me immensely when I see this sort of thing:
Subject to Change: Creating great products and services for an uncertain worldby Adaptive Path (aka Peter Merholz, Brandon Schauer, David Verba and Todd Wilkens)
I thought my own book took the prize for the longest title, but this one trumps it by an extra yard or two. The title evokes a sense of rapid development in “Internet time”, with requirements changing at a fundamental and product-warping level right up to the release date. A book of that sort would read more like an agile manifesto; a celebration of chaos. However, I’m happy to report that this isn’t that book.
Instead, Subject to Change provides level-headed advice on how to develop new products and services in a world that’s subject to change without notice. The key to the book’s approach is to put user experience at the heart of it all. True, there is a chapter on agile development, but it isn’t quite the gibbering chaos-monger that I’d feared.
Over at The Register
