|Home » Learning Curve » Developers Workshop
Designers Gone Wild
5 + 95 > 95 + 5.
A Lisp guru once lamented the fact programmers seemed to spend 5% of their time writing their code and 95% fixing it.
They rush into things and write write write - and only afterwards realise what they've done.
And at that point are confronted with a truly impossible task: delousing code that should never have been written like that in the first place.
Good luck with that.
Things are done differently at this company where we took the Lisp guru's words to heart and decided we'd rather spend 95% of our time writing the code and only 5% - at the very most - debugging it. And we're not alone in that sentiment: the legendary Brian Kernighan has gone on record to say 'debuggers' are to be used sparingly 'if at all'. And why? Because a good programmer doesn't need them.
And our total time to market (our '95% + 5%') is but a fraction of what others waste with their '5% + 95%'.
The classic course delegate is the one who sits right up in front centre - near Teacher and with his computer screen in full view of most of the other delegates - so everybody can see what a whiz he is with the debugger.
And he runs that debugger like Quake. He's got windows open all over the place; he flips between them at a breathtaking pace; there's just one snag.
He never finishes a single programming assignment.
And after a while he starts to make low noises. Moans and winces. So Teacher wanders over. The guy's got some kind of deflector shield set up around him so nobody gets too close but now Teacher has to penetrate the defences.
'It just doesn't work', he complains to Teacher.
'Let me see your source code', says Teacher. 'Where's the source?'
The guy points to this two inch square in the middle of the screen. The source. All the rest of the screen is covered in debugger windows - stack traces, register contents - and the question is whether this person knows what any of those windows do. Or whether he thinks any of that is really important.
As if the whole point of the exercise is to whiz a bunch of windows around on screen.
'I need to see the whole source file', protests Teacher.
Mr Debugger pretends he didn't hear. After a while Teacher gives up and moves on.
Over in the corner, unobtrusive, sit two corporate colleagues to Mr Debugger. They don't demand attention and in fact have not called attention to themselves for three days. Teacher wanders over and asks them how they're doing.
They show Teacher an incredible hack. They've taken non-native code and forced it into a shared library and somehow made it work. Minor sensation.
But no fanfare. And without fifteen zillion gajillion debugger windows.
Teacher asks about their colleague Mr Debugger. 'How do you get along with him at work?'
They both roll their eyes as if to say 'you don't want to know but you already know'.
The best programmers can be put under a lot of pressure by marketing and management. 'Just implement this one extra feature and we won't bother you again. We really really need this feature. Please.' And so forth.
Brian Kernighan's second rule of programming is 'build it in stages'. By the time you've got to this rule you already have accepted the first rule: 'keep it simple'. And you're almost ready for his third and final rule - in essence: 'don't reinvent the wheel'.
A case in point might be the ACP framework's search classes. These classes govern searches in table views and text views alike. The one of them is patterned in terms of UI after David Hyatt's search panel for the original Safari.
There are no doodads put into client applications; everything is run from the framework itself. There's no alteration of client application code whatsoever: the framework classes automatically suss out what's going on, who the targets are, and how to access them - and in the case of text views how to modify their contents as well.
All without touching the targets, without rebuilding the client applications. The ACP framework search classes simply 'hover' over their clients and do their work. And the same code runs in all clients. The wheel is not reinvented.
And it's one piece of code too: it's in a single place. To change the behaviour of all affected applications only one instance of the code needs to be modified. It's 'simple'.
And it was built in stages. The first stage was to get the code running natively in a client application. Once that was working properly the code was carefully migrated to the framework and tested there. And after that all the ACP applications could benefit.
Templates vs Coding
A postgraduate course in systems development saw twenty five programmers broken down into five groups of five programmers each. Their final project was to put together a monster system of forty programs working as a single unit.Getting the Upper Hand
Each group got five programs to write; and Teacher was to supply the remaining fifteen programs to glue the whole thing together.
One group of five saw an interesting development right away. One of the five came namely upon a radical idea.
'Hey I got an idea', he told the others. 'Why don't we write the templates first and then build on them incrementally? That way we should be finished way ahead of time and maybe we can get a look at some of the thirty five other programs.'
Using an IDE such as Apple's you already get templates for your projects but you still have to fill in a bunch of things - you have to design your windows, name your classes, figure out how the code is going to work, make the first connections, and so forth. That's a lot to test.
And the idea was to get all of that out of the way first - not only because that's the easy part but more importantly because it narrows down the target area when you're hunting bugs: you already know the template is error-free. And if you add incrementally to the template and test every increment you don't have to hunt far to find bugs if they occur - they're in that latest snippet you just added.
'Nah!' said the other four scornfully. 'You go play with your templates - WE'RE GOING TO WRITE THE CODE!'
Several weeks later when it was time to present one's work those four asked for an extension to finish their final program.
The fifth of them who worked incrementally from the templates was not only finished with his five, not only finished with the other twenty assigned to the class as a whole - he'd also completed the fifteen additional programs Teacher was supposed to supply.
The other four complained to Teacher when their extension was running out. They complained to their fifth colleague as well.
'It just doesn't work!' they protested. 'We wrote that program perfectly and it just doesn't work!'
'But you can't have written it perfectly if it doesn't work?' their colleague commented.
'But we did!' they blurted. 'We did! We wrote it perfectly! Perfectly! And still it won't work!'
Apple are known for putting form over function. It doesn't matter as much if a program works as long as it looks good. Featurism is allowed to creep in everywhere until it's oozing out of the seams. But what's good enough for a wise programmer is not enough for the marketing department.
A case in point might be Safari's original cookies sheet. The way it originally was laid out and worked was brilliant. And as with all things elegant it was deceptively simple.
Don't worry about the title bar. You've never seen it because it's never shown. This is a panel (NSPanel) run as a sheet. So it doesn't pop up - it comes out of a window. The title is never seen [and not needed but that's another matter].
And don't sweat the focus rectangle either. This is a throwback to earlier NIBs and today focus rectangles are possible and unfortunately the default is to have one - which is totally wrong in this case - but don't sweat it.
What's important is how this window (panel) works. It comes out when the user clicks the 'cookies' button on the security pane in preferences.
You've got six columns of data listed but most of it is gobbledegook intelligible only to the remote servers. The 'Done' button is blue so it has 'enter' as a shortcut - all you have to do to dimiss this sheet is hit 'enter'. Cool.
And if you want to remove all cookies you can either click 'Remove All' or even easier for most users hit ⌘A, then ⌫, then 'enter' - and all the cookies are gone and so is the sheet. Swift 1-2-3. Can't be easier.
But someone at Hyatt's old haunts saw the sheet and thought they'd put it in their own Attack of the Clones program. Except as the FOSS was with them they figured they could improve on it by giving it more FEATURES.
So they put in a search field (NSSearchField) between the 'Remove All' and 'Done' buttons. That made it their own all right - meant they weren't just copying from old Dave - but did that ever screw things up.
For the first: searching through the gobbledegook of cookies is on a tangent to pointless anyway. For the second: the search field always grabs the initial focus so you can't just hit ⌘A + ⌫ + 'enter' - now you have to get back to that pointing device again, CLICK INSIDE THE TABLE VIEW TO GIVE IT FOCUS - and then and only then can you proceed as before.
So basically the Camino cookies sheet turned as so much of FOSS design turns out: flawed.
And then something magical happened in Cupertino. Was Hyatt secretly spying on his former colleagues? This at any rate is what he came up with for Safari 3.
It's the same sheet as before - but instead of availing himself of the real estate between 'Remove All' and 'Done' as the Camino people did he put the search field at the top all by its lonesome.
The sheet is otherwise identical - only that it's 26 pixels higher.
And as for functionality? How about it can only search according to the first column ('Website') where you can already see everything neatly sorted?
This is a clear case of someone (hopefully not in the Safari team) who thought it was time to add another doodad - another feature. Which ostensibly is nearly pointless and inarguably more than counterproductive.
Form or Function?
Leopard has any number of glaring examples of where the designers went wild.
- Mail's new 'photo browser' and 'stationery' features. Forget for a minute that only lusers use non-plain text mail: what happened? There are still so many bugs in this program dating back to April 2005 that no one's been interested in fixing. Why is that?
- Preview adds a lot of really fantastic features. But forgets one essential thing from its Tiger incarnation: it can't show cropped sizes until the file's been saved. And suddenly you can drag the cropping rectangle anywhere - not just on the image but beyond. What good does that do?
- launchd and launchctl. Apple's replacement for traditional Unix system startup. Oh it's fantastic, they say - but how about the command 'launchctl singleuser' that circumvents standard security? That without question or prompt just zaps an entire user login session and all unsaved work? How long is it going to take before hackers start having fun with this? How long is it going to take before ordinary punters use it to play practical jokes on their 'friends'?
- The unfixed Finder. When Steve Jobs announced Apple had worked on Finder everyone at Moscone cheered. Even though they'd not heard yet what the changes were. The changes were superficial: more doodads and more features. But how about outstanding issues such as HFS security? How about the 'advanced' button for professionals? How about the gaping 'massive data loss' bug that's been wreaking havoc for years?
- The brand new firewall. That's already been torn to shreds by the media.
- Xcode 3. Oh it's dazzling all right. Then how come its embedded SCM module insists on creating its own directory at user root and crashes the application if it can't succeed?
- The glassy dock. Oh it looks dazzling - where it is. But what happens when you move it to a side of the screen? And the two dimensional non-glassy alternative? How ugly is that?
- Expanding outline view hierarchies. Can be done with either ⌥⌘→ or ⌥→ on Tiger because ⌘ is ignored. Suddenly it's not ignored anymore. Has anyone tried to use this?
- Suble changes to selecting in table views and text views. The latter are perhaps better but they're different - and going to screw a lot of people up. The former are just bloody ridiculous. They. Just. Don't. Work. Period. Has anyone tested any of this crap? There's no way they can have tested it. It. Simply. Doesn't. Work.
That's going to be a long list before it's forgotten. But the lesson still to be learnt is that you don't build it first and then look for the mistakes - you correct the mistakes you have first before building on what you have.
And then you'll have your Rock Solid Foundation™.
All commercial vendors make the same tactical errors. But knowing that doesn't help the poor user. Even venerable IBM sometimes build on workarounds for mistakes rather than correcting the mistakes themselves.
Apple are closing in on the six million mark for reported bugs in OS X. Considering the time the OS has been on the market that's about one million reported bugs per year.
How are they ever going to wade through all that? How can they ever hope to catch up?
Clue: they don't hope to catch up. Not in their wildest dreams. They just try to do the best they can given the model they work with.
Which essentially is 'rush to code' and 'add more doodads and more features' and only after the fact try to clean things up.