A while back, I commented on Kyle Neath‘s piece regarding screen resolution. Of course both of our posts went a bit beyond that, but it appears that we now have an answer from none less than Jakob Nielsen. In his latest Alertbox, Screen Resolution and Page Layout, Jakob tells us we are free to bump it up to 1024×768. So there you go – don’t say you never learned anything here!
Joel put out a flurry of posts in the last few days including this interesting look at a recent Travelers Insurance ad that depicts geeks in a rather stereotypical light. I’m guessing a lot of folks will agree with Joel’s assessment that the add is offensive – what do you think? All I know is it sounds like he’s shopping for a new policy:
You probably forgot that most of the people that read Inc. are geeks. And we buy insurance. Lots of insurance. Like me. And in fact I used to buy it from you. But not any more.
Now, I have no idea just how many geeks are covered by Travelers, but I do know that a lot of them read Joel’s blog…wonder how many will join him in his boycott? Smacks a bit of Microsoft’s recent evolve campaign and we know how popular that has been!
Michael Mahemoff picked up on my recent ramblings about functional specs and adds his own 5 cents (in my mind, his thoughts are worth more than just a couple of pennies). I agree with Michael with regards to the dichotomy – like most things in life, docu needs exist on a continuum. If I’m just writing a simple little app for my own use, I probably won’t write much of anything beyond the code but if I’m reworking the software that keeps planes in the air, well, chances are I’ll need to jot a few things down!
While needs vary, as Michael says, it’s quite difficult to nail down software requirements down with any degree of accuracy.
The problem here, of course, is that Definitive-style docs require an almost impossible task of pinning down requirements, and furthermore, fixing requirements runs counter to the modern organisationâ€™s goal of being agile.
I’m not sure why companies continue to try and use waterfall like methodologies when agile appears to be the only approach that really works. The idea that process can somehow replace people is as old as the Model T. But then when was the last time you drove one of those to the office?
The real solution doesn’t lie with more process or templates – it rests with better people. I went to a small liberal arts school in central Minnesota. Beyond my studies in 0s and 1s, I took quite a few courses from the outside the sciences, considerably more than I was “required” to take to fulfill my core credits. That was fine with me, my interests were diverse but it always struck me as odd that science folk were required to take far more humanities stuff than the non-science types were required to take in our disciplines. My point?
Thereâ€™s obviously no one solution, but one essential ingredient comes from multi-talented people.
By now, it should be obvious that there are quite a few books out there on Ajax…and it seems like new one’s are published every day! In case you were curious, Michael Mahemoff (author of Ajax Design Patterns and proprietor of AjaxPatterns.org) has added a list of books to his popular site. Enjoy!
Depending on who you believe, functional specs are either an absolute must or something to be avoided like the plague. While I vacillate on the necessity of written docu, if pressed I trend towards the 37signals approach – the code never lies (misleads, sure) and iterating code tends to provide better answers anyway. That said, there have been occasions where I *really* would have liked something more concrete than “it has to be like the old system…only better” or “the requirements are whatever I say they are”. While I’ll concede the need to write something down, I’ve seen many examples that go a bit, ah, overboard when it comes to specs. Seriously, if it needs a table of contents and an index, it’s time to pare it down a bit.
The struggle comes down to purpose: why do we write functional specs? Some companies believe they should be the complete conveyance between customers and developers – when you get there, you’re in trouble. By the time you’ve finished writing down every possibility (and sat through many, many mind numbing meetings), chances are the business has changed three or four times obviating all of your hard work.
So the question is, what should a requirements document provide? Agile mentor Venkat Subramaniam nails this issue right on the head – instead of trying to map every fork, provide enough depth to help the developer explore the issues.
Rather than providing answer to all my questions, I would like for it to help me ask the right questions when I am ready to delve into the implementation.
A great requirements document helps me not with right answers, but with right questions.
Keep this in mind next time you sit down to write a spec – it should aide communication, not supplant it. Help your devs ask the right questions, don’t try and answer every single one.
I’ve posted about geek music before (and in case you missed it, my cubicle is dead on) so when I ran into Tim Bray‘s The DOM Song, I just had to put up a link to it! As someone that has done his fair share of hand to hand combat with the DOM, I found this quite amusing
On Saturday, I had the distinct pleasure of presenting Foundations of Ajax and Pragmatic Usability at the Central Iowa Software Symposium. As regular readers know, I’ve attended NFJS events in the past (take a look at my thoughts on this year’s MN show: day 1, day 2, day 3 and of course quotes) but this was my first go at actually presenting. If you’ve ever attended a NF event, you know how outstanding the speakers are so I was really honored when Jay Zimmerman gave me the green light! Based on the feedback I received, I think I held my own which is saying quite a bit when you’re sandwiched by the likes of David Hussman, Venkat Subramaniam, Glenn Vanderburg and a host of outstanding technical minds.
I want to thank everyone that came to my talks – especially those that came up during the breaks to chat! Unfortunately I wasn’t able to stick around for very long (though I thoroughly enjoyed Scott Davis‘ talk on Easing into Agile – oh, and thanks to Scott, his mom, and Matt for making me feel right at home). My apologies for the handouts, I will get that corrected (though I know that is of little help to the good folk in Iowa). For your viewing pleasure, I’ve uploaded the slides (FoA, Pragmatic Usability) and as usual these are released under a Creative Commons license.
If you’re interested in hearing me present either of these talks, I’ll be at the Southern Ohio Software Symposium in two weeks – hope to see you there!
If you’re interested in learning a bit more about Ajax, you might want to give Sang Shin‘s 10 week free Ajax course a try. The class starts on August 4th – to register, send an email to the Yahoo group he has created. The schedule looks pretty darn complete though alas, no mention of Prototype or script.aculo.us… Of course if Ajax isn’t your thing, take a look at the other courses he teaches.
Despite the stormy weather last night, Ryan and I had a (nearly) packed house for our talk about Ajax and Java at the Twin Cities Java User Group. We had a great time – thanks to everyone that came, we really appreciate the support! Jeff Jensen was awseome as always (sorry for giving you a bit of heartburn there my man!) and we got some great questions. Congrats to everyone that won a book or a shirt, enjoy!
For posterity, here are the slides (you can also get them from the TC JUG site). I added a slide on Yahoo’s library and there’s a special surprise buried in there… Please note, this presentation is licensed under Creative Commons License: Ajax and Java Slides.