Social and political requirements gathering

I was originally going to talk about API: Design Matters and Cocoa, but, and I believe the title of this post may give this away, I’m not going to now. That’s made its way into OmniFocus though, so I’ll do it sooner or later. No, today I’m more likely to talk about The Cathedral and the Bazaar, even though that doesn’t seem to fit the context of requirements gathering.

So I’ve been reading a few papers on Requirements Engineering today, most notably Goguen’s The Dry and the Wet. One of the more interesting and subtle conclusions to draw from such a source (or at least, it’s subtle if you’re a physics graduate who drifted into Software Engineering without remembering to stop being a physicist) is the amount of amount of political influence in requirements engineering. Given that it costs a couple of orders of magnitude more to mend a broken requirement in maintenance than in requirements-gathering (Boehm knew this back in 1976), you’d think that analysts would certainly leave their own convictions at the door, and would try to avoid the "write software that management would like to buy" trap too.

There are, roughly speaking, three approaches to requirements elicitation. Firstly, the dry, unitarian approach where you assume that like a sculpture in a block of marble, there is a single "ideal" system waiting to be discovered and documented. Then there’s the postmodern approach, in which any kind of interaction between actors and other actors, or actors and the system, is determined entirely by the instantaneous feelings of the actors and is neither static nor repeatable. The key benefit brought by this postmodern approach is that you get to throw out any idea that the requirements can be baselined, frozen, or in any other way rendered static to please the management.

[That’s where my oblique CatB reference comes in – the Unitary analysis model is similar to ESR’s cathedral, and is pretty much as much of a straw man in that ‘purely’ Unitary requirements are seldom seen in the real world; and the postmodern model is similar to ESR’s bazaar, and is similarly infrequent in its pure form. The only examples I can think of where postmodern requirements engineering would be at all applicable are in social collaboration tools such as Facebook or Git.]

Most real requirements engineering work takes place in the third, intermediate realm; that which acknowledges that there is a plurality among the stakeholders identified in the project (i.e. that the end-user has different goals from his manager, and she has different goals than the CEO), and models the interactions between them in defining the requirements. Now, in this realm software engineering goes all quantum; there aren’t any requirements until you look for them, and the value of the requirements is modified by the act of observation. A requirement is generated by the interaction between the stakeholders and the analyst, it isn’t an intrinsic property of the system under interaction.

And this is where the political stuff comes in. Depending on your interaction model, you’ll get different requirements for the same system. For instance, if you’re of the opinion that the manager-charge interaction takes on a Marxist or divisive role, you’ll get different requirements than if you use an anarchic model. That’s probably why Facebook and Lotus Notes are completely different applications, even though they really solve the same problem.

Well, in fact, Notes and Facebook solve different problems, which brings us back to a point I raised in the second paragraph. Facebook solves the "I want to keep in contact with a bunch of people" problem, while Notes solves the "we want to sell a CSCW solution to IT managers" problem. Which is itself a manifestation of the political problem described over the last few paragraphs, in that it represents a distortion of the interaction between actors in the target environment. Of course, even when that interaction is modelled correctly (or at least with sufficient accuracy and precision), it’s only valid as long as the social structure of the target environment doesn’t change – or some other customer with a similar social structure comes along ;-)

This is where I think that the Indie approach common in Mac application development has a big advantage. Many of the Indie Mac shops are writing software for themselves and perhaps a small band of friends, so the only distortion of the customer model which could occur would be if the developer had a false opinion of their own capabilities. There’s also the possibility to put too many “developer-user” features in, but as long as there’s competition pushing down the complexity of everybody’s apps, that will probably be mitigated.

Posted in Business, metadev, mythicalmanmonth, usability | Leave a comment

The Dock should be destroyed, or at least changed a lot

I found an article about features Windows should have but doesn’t, which I originally got to from OSNews’ commentary on the feature list. To quote the original article:

The centerpiece of every Mac desktop is a little utility called the Dock. It’s like a launchpad for your most commonly used applications, and you can customize it to hold as many–or as few–programs as you like. Unlike Windows’ Start Menu and Taskbar, the Dock is a sleek, uncluttered space where you can quickly access your applications with a single click.

Which OSNews picked up on:

PCWorld thinks Windows should have a dock, just like Mac OS X. While they have a point in saying that Windows’ start menu and task bar are cumbersome, I wouldn’t call the dock a much better idea, as it has its own set of problems. These two paradigms are both not ideal, and I would love someone to come up with a better, more elegant solution.

The problem I have with the Dock (and had with the LaunchPad in OS/2, the switcher in classic Mac OS, and actually less so with the task bar, though that and the Start Menu do suffer this problem) is that their job basically involves allowing the internal structure of the computer to leak into the user’s experience. Do I really want to switch between NeoOffice Writer, KeyNote and OmniOutliner, or do I want to switch between the document I’m writing, the presentation I’m giving about the paper and the outline of that paper? Actually the answer is the latter, the fact that these are all in different applications is just an implementation detail.

So why does the task bar get that right? Well, up until XP when MS realised how cluttered that interface (which does seem to have been lifted from the NeXT dock) was getting, each window had its own entry in the task bar. Apart from the (IMO, hideously broken) MDI paradigm, this is very close to the “switch between documents” that I actually want to perform. The Dock and the XP task bar have similar behaviour, where you can quickly switch between apps, or with a little work can choose a particular document window in each app. But as I said, I don’t work in applications, I work in documents. This post is a blog post, not a little bit of MarsEdit (in fact it will never be saved in MarsEdit because I intend to finish and publish it in one go), the web pages I referenced were web pages, not OmniWeb documents, and I found them from an RSS feed, not a little bit of NetNewsWire. These are all applications I’ve chosen to view or manipulate the documents, but they are a means, not an end.

The annoying thing is that the Dock so flagrantly breaks something which other parts of Mac OS X get correct. The Finder uses Launch Services to open documents in whatever app I chose, so that I can (for instance) double-click an Objective-C source file and have it open in Xcode instead of TextEdit. Even though both apps can open text files, Finder doesn’t try to launch either of them specifically, it respects the fact that what I intend to do is edit the document, and how I get there is my business. Similarly the Services menu lets me take text from anywhere and do something with it, such as creating an email, opening it as a URL and so on. Granted some app authors break this contract by putting their app name in the Service name, but by and large this is a do something with stuff paradigm, not a use this program to do something one.

Quick Look and Spotlight are perhaps better examples. If I search for something with Spotlight, I get to see that I have a document about frobulating doowhackities, not that I have a Word file called “frobulating_doowhackities.doc”. In fact, I don’t even necessarily have to discover where that document is stored; merely that it exists. Then I hit space and get to read about frobulating doowhackities; I don’t have to know or care that the document is “owned” by Pages, just that it exists and I can read it. Which really is all I do care about.

Posted in aqua, metadev, rant, usability | 2 Comments

Yeah, we’ve got one of those

Title linkey (which I discovered via slashdot) goes to an interview in DDJ with Paul Jansen, the creator of the TIOBE Programmer Community Index, which ranks programming languages according to their web presence (i.e. the size of the community interested in those languages). From the interview:

C and C++ are definitely losing ground. There is a simple explanation for this. Languages without automated garbage collection are getting out of fashion. The chance of running into all kinds of memory problems is gradually outweighing the performance penalty you have to pay for garbage collection.

So, to those people who balked at Objective-C 2.0’s garbage collection, on the basis that it "isn’t a 4GL", I say who cares? Seemingly, programmers don’t – or at least a useful subset of Objective-C programmers don’t. I frequently meet fellow developers who believe that if you don’t know which sorting algorithm to use for a particular operation, and how to implement it in C with the fewest temporary variables, you’re not a programmer. Bullshit. If you don’t know that, you’re not a programmer who should work on a foundation framework, but given the existence of a foundation framework the majority of programmers in the world can call list.sort() and have done with it.

Memory management code is in the same bucket as sorting algorithms – you don’t need for everybody to be good at it, you need for enough people to be good at it that everyone else can use their memory management code. Objective-C 2.0’s introduction of a garbage collector is acknowledgement of this fact – look at the number of retain/release-related problems on the cocoa-dev list today, to realise that adding a garbage collector is a much bigger enhancement to many developers’ lives than would be running in a VM, which would basically go unnoticed by many people and get in the way of the others trying to use Instruments.

Of course, Objective-C and ApPLE’s developer tools have a long history of moving from instrumental programming (this is what the computer must do) to declarative programming (this is what I am trying to achieve, the computer must do it). Consider InterfaceBuilder. While Delphi programmers could add buttons to their views, they then had to override that button’s onClick() method to add some behaviour. IB and the target-action approach allow the programmer to say "when this button is clicked, that happens" without having to express this in code. This is all very well, but many controls on a view are used to both display and modify the value of some model-level property, so instead of writing lots of controller code, let’s just declare that this view binds to that model, and accesses it through this controller (which we won’t write either). In fact, rather than a bunch of boilerplate storage/accessors/memory management model-level code, why don’t we just say that this model has that property and let someone who’s good at writing property-managing code do the work for us? Actually, coding the model seems a bit silly, let’s just say that we’re modelling this domain entity and let someone who’s good at entity modelling do that work, too.

<

p>In fact, with only a little more analysis of the mutation of Objective-C and the developer tools, we could probably build a description of the hypothetical Cen Kase, the developer most likely to benefit from developing in Cocoa. I would expect a couple of facts to hold; firstly that Cen is not one of the developers who believes that stuff about sorting algorithms, and secondly that the differences between my description of Cen and the description used by Apple in their domain modelling work would fit in one screen of FileMerge on my iBook.

Posted in cocoa, metadev, nextstep, objc, openstep | Leave a comment

Tracking the invisible, moving, unpredictable target

An idea which has been creeping up on me from the side over the last couple of weeks hit me square in the face today. No matter what standards we Cocoa types use to create our user interfaces, the official Aqua HIG, the seemingly-defunct IndieHIG, or whatever, ultimately producing what is considered a usable (or humane, if you like) interface for Mac OS X is not only difficult, but certainly unrepeatable over time.

The “interface” part of a Cocoa user interface is already hard enough to define, being a mash-up of sorts, and to differing degrees, between the Platinum HIG which directs the default behaviour of some of the *Manager controls and the OpenStep HIG which describes the default behaviour of most, if not all, of the AppKit controls. If that isn’t enough, there is an inexact intersection – some controls work differently in (what are loosely called, and I’m not getting into the debate) Cocoa apps than in Carbon apps. There have also been innovative additions on top of the aforementioned guides, such as sheets, unified toolbars and (the already legacy) textured interfaces. There have been subtractions from both – miniwindows still exist but nobody uses ’em, and window shading went west with Rhapsody.

But all of that is related to the user interface, not to user interaction (I’m in the middle of reading Cooper’s The Inmates Are Running the Asylum, I’m going to borrow some terminology but studiously avoid discussing any of the conclusions he presents until I’m done reading it). It’s possible to make HIG-compliant inspectors, or HIG-compliant master-detail views, or HIG-compliant browser views and so on. It’s also possible to make non-compliant but entirely Mac HID views, coverflow views, sidebars and so on. But which is correct? Well, whichever people want to use. But how do you know which people want to use? Well, you could get them to use them, but as that’s typically left until the beta phase you could ask usability gurus instead. Or you could take the reference implementation approach – what would Apple (or Omni, or Red Sweater, or whoever) do?

Well, what Apple would do can, I think, be summed up thus: Apple will continue doing whatever Apple were previously doing, until the Master User takes an interest in the project, then they do whatever the Master User currently thinks is the pinnacle of interaction design. The Master User acts a little like an eXtreme Programming user proxy, only with less frequent synchronisation, and without actually consulting with any of the other 26M users. The Master User is like a reference for userkind, if it all works for the Master User then at least it all works for one user, so everyone else will find it consistent, and if they don’t find it painful they should enjoy that. The official job title of the Master User role is Steve.

All of this means that even inside Apple, the “ideal” usability experience is only sporadically visited, changes every time you ask and doesn’t follow any obvious trend such as would be gained by normalisation over the 26M users. Maybe one day, the Master User likes inspectors. Then another day he likes multi-paned, MDI-esque interaction. On a third day he likes master-detail control, in fact so much so that he doesn’t want to leave the application even when it’s time to do unrelated work. Of course you don’t rewrite every application on each day, so only the ones that he actually sees get the modernisation treatment.

So now we come back to the obvious, and also dangerous, usability tactics which are so prevalent on the Windows platform, and one which I consciously abhor but subconsciously employ all the time: “I’m the developer, so I’ll do it my way”. Luckily there are usability, QA and other rational people around to point out that I’m talking shite most of the time, but the reasoning goes like this. I’m a Mac user, and have been for a long time. In fact, I might know more about how this platform works than anyone within a couple of miles of here, therefore(?) I know what makes a good application. One problem which affects my personal decisions when trying to control the usability is that I’m only tangentially a Mac person, I’m really a very young NeXTStep person who just keeps current with software and hardware updates. That means I have a tendency to inspector my way out of any problem, and to eschew custom views and Core Animation in favour of “HIG is king” standard controls, even when other applications don’t. And the great thing is that due to Moving Target reference implementation, I can find an application which does something “my” way, if that will lend credence to my irrational interface.

The trick is simply to observe that taking pride in your work and expressing humility at your capabilities are not mutually exclusive. If tens of other Mac users are telling me they don’t like the way it works, and I’m saying it’s right, apply Occam’s razor.

And if there isn’t enough fun for you in one usability experience, a bunch of us are presumably going to be providing the iPhone HIG-compliant V on top of our Ms and Cs before long.

Posted in aqua, carbon, cocoa, openstep, usability | Leave a comment

Come back, purple button, all is forgiven!

As a great philosopher once wrote: don’t it always seem to go, that you don’t know what you got ’til it’s gone? Previews of Mac OS X had a user interface feature, known by all who saw it as the Purple Button. Look at this screenshot from System Preferences:

The boiled sweet on the top-right of the window would go purple, hence the name. Clicking on it activated a single-window mode. All documents except the one that you were working on would be minimised into the Dock, and switching between them would minimise the earlier one before restoring the newly-focused document. Of course, the problem with this in the developer previews/public beta which rendered it unusable were performance-related. The “lickable” eye-candy in Aqua was ambitious even on the top-end G4 systems available at the time, and so time spent in the Genie or Scale effects was really noticable. Add to that the effect of applications being slow enough not to update their views in time – the System Preferences application you can see above is a Cocoa-Java app, and back then the JVM wasn’t amazing for performance – and you have a really sucky single-window experience.

On the other hand, it’s really bloody useful. Look at apps like WriteRoom or GLTerminal, which go out of their way to get rid of all that other clutter. Or Spaces (or CDE virtual desktops, WindowMaker virtual desktops… you get the idea), also designed to let you forget all those other apps are there. Well, spaces is quite nice (and a little more flexible than purple button was), but playing spaces ping-pong tends to make me a bit seasick. Not to mention the time it wastes being about as great as the unperformant purple button switching…so please, purple button, come back!

Some environments provided the same user experience out of a lack of choice – for instance, OZ couldn’t show more than one application if it wanted to, and certainly running more than one at once was out of the question (it would simulate multi-tasking by suspending background tasks).

Posted in aqua, cocoa, FTFF, usability | 1 Comment

How exciting

Today I was pleasantly surprised by Interface Builder. Not shiny, new, where the hell have they put that buttonstreamlined IB3, but boring old IB2 which even Slowlaris users could work out how to use. I dragged a header defining a category with an IBAction onto IB, and lo, nay even behold, it did the right thing.

That may seem unexciting and even expected, but it’s one of those nice cases where it’s pleasing that everything just works. I thought category headers might be edge-case enough to confuse the thing; many people would put their IBAction definitions in the “regular” @interface header so that the IBOutlets are in the same place.

Posted in whatevs | Leave a comment

Broke track mounting

For some reason, CDs occasionally don’t automount for me on my iMac. Luckily that’s easy to work around:
kalevala:~ leeg$ diskutil list
[…]
/dev/disk3
#: TYPE NAME SIZE IDENTIFIER
0: CD_partition_scheme Audio CD *620.3 Mi disk3
[…]
kalevala:~ leeg$ diskutil mountDisk disk3
Volume(s) mounted successfully

Job is, as they say, a good ‘un.

Posted in darwin, leopard | Leave a comment

Nice things about ObjC

Title linkies to a post by an F-Script guy (the F-Script guy? I’m not sure, I don’t really follow F-Script development) about nice things he likes about the Objective-C language. Remembering that he wrote a Smalltalk scripting environment for Cocoa, some of the list is fairly unsurprising, much is made of the dynamic runtime, multiple-level dispatch and so on. I think the article is mainly bang on, though I do disagree with the author in a few places. The next paragraph is not one of those places.

Classes are objects. ++ This is the coolest thing ever about proper object-oriented languages, and one of my strongest arguments for design patterns are not language independent. Do patterns such as Prototype need to exist in ObjC code, when the Factory Method +new will give you an unconfigured typical instance?

Dynamic typing… Optional static typing. This is one of those slippery slopes where both edges are sharp enough to give you the rope required to shoot yourself in the foot. Duck typing (i.e. if an object looks like a duck, and quacks like a duck…) is useful in some cases and damned annoying in others. To avoid runtime exceptions with duck typing you either have to [i]mentally assert correctness in your code, [ii]perform all the runtime introspection needed to ensure your messages will be handled, or [iii]eschew the duck type completely and downcast to either an instance of a class or a conformant of a protocol (or both; you could do something like GLModelObject <NSCoding> * if you really felt like it). Another issue with the ObjC implementation of duck typing is that it doesn’t always work as you’d think. When it does work, it’s very powerful – when it doesn’t, you probably won’t find out until runtime, and could be spending a long while working out what happened.

Categories. No, afraid not. Nice idea, badly implemented. The point of categories is to let you decorate a class with additional functionality by adding methods – currently not ivars – in additional code objects, not all of which need be present at launch. This lets you work around the visibility contract of the class (can’t see an @private ivar? Just chuck an instance method in!), though in fairness so does KVC. But perhaps the worst crime a category can commit is killing someone else’s category. Or overwriting an “undecorated” method.

I still love Objective-C, mainly because I love Cocoa and GNUstep and making code that works like them, it’s definitely powerful and fun too. But it’s not without its rough edges and sharp spiky bits.

Posted in cocoa, gnustep, objc | Leave a comment

My discs have been Americanised!

<

p>For some reason, even though l10n and i18n have been fashionable terms in computing for the last few years, no-one seems able to localise properly into the lingua franca of computing, English. It may surprise some readers to learn that there’s more than one dialect of english, and some of these even have their own ISO codes (such as en_GB, en_US and so on…I’m ignoring the "ang" language for now). Some words in these different dialects are not spelled in the same way. I live in the United Kingdom of Great Britain and Northern Ireland (Land of hope and glory, mother of the free…) and therefore those round things are known as discs. Indeed, when I insert my Mac OS X installer disc, it is called “Mac OS X Install Disc 1”. Then I launch the Firmware Password application, which tells me: “The firmware password is used to prevent others from starting your computer with a different disk.” Gah!

Posted in rant | 3 Comments

“Patently” obvious

Due to a lack of digit extraction I’m not at FOSDEM this weekend. That’s unfortunate because as well as catching up with my friends at Brainstorm and on GNUstep, I really enjoyed the weekend last year and drank plenty of great Belgian beer and ate plenty of nice moules-frites.

So I’ve been spiritually living the Free lifestyle by reading what RMS and Torvalds have to say. Mostly I’ve been going over the essays in Free Software, Free Society. I find it very easy to accept the premises RMS uses, easy to follow, comprehend and agree with the arguments he presents but then somehow (perhaps for illogical reasons on my part, his part or both) hard to agree that the conclusions he draws are inevitable.

For instance, I agree that copyright law exists directly to benefit the public, and indirectly to benefit the authors (by providing incentives for authors in the shape of limited term monopoly over their authored content) and not at all to benefit Industry Associations. It even says that here, in the first ever copyright law: …for the Encouragement of Learned Men to Compose and Write useful Books; May it please Your Majesty, that it may be Enacted… certainly doesn’t seem to mention greedy lawyers or management.

Letters patent were never created for the same reason, of course. But because it became clear that patents from the Crown were obtained uppon Misinformacions and untrue pretences of publique good, many such Graunts have bene undulie obteyned and unlawfullie putt in execucion, to the greate Greevance and Inconvenience of your Majesties Subjects, contrary to the Lawes of this your Realme, and contrary to your Majesties royall and blessed Intencion soe published, so the whole system was rebooted so that patents were only grantable … to the true and first Inventor and Inventors of such Manufactures, […] soe as alsoe they be not contrary to the Lawe nor mischievous to the State, by raisinge prices of Commodities at home, or hurt of Trade, or generallie inconvenient….

The situation we find ourselves in now is that industries claim copyrights and inventions from the authors and inventors and lobby for more and more restrictive variants of the above laws, ignoring the previously-granted rights of the public at large and extending the previously-ungranted rights of the rights-owners, simultaneously removing those rights from the people granted the rights in the first place. So why in the case of copyright do the FSF assume copyright, but in the case of patents they refuse to deal with them? That inconsistency I don’t understand.

Posted in Business, FOSDEM, fsf, GNU | Leave a comment