A handy site to remember if you’re writing PHP is http://php-date.com/. It provides everything you need to know about the date() function in PHP and has an interactive form for testing your formatting until you get your dates/times just the way you want them.

Something I’ve been preaching for years, to any software developer who’ll listen, is: don’t use a tree view control in the user interface if your users are not highly technical and there’s another way of allowing the user to do the thing they actually want to do (which there usually is if you put some thought into it).

So I was delighted to hear Jeff Atwood and Joel Spolsky’s views on the Stack Overflow Podcast #45:

Atwood:   … programmers love hierarchy, to a degree that they don't even understand how different they are than the public in this regard. Like they love putting everything in this little bucket, that goes in this little bucket, which is this sub-bucket of this and this, and normal people hate that. And threading is totally a manifestation of that and it drives me crazy that a lot of programmers can't see that they're like immediately like: "Oh, threading is good. I love threading. What are you talking about?" You know? They can't see it at all.

Spolsky:   Right, right.

Atwood:   It's like myopia.

Spolsky:   Yeh. I mean it's really a function of the size of the group, and one thing I've learned through years and years of usability testing is that anything that smacks of a hierarchy or a tree is not going to be understandable to the average, non-technical user.

Atwood:   Yeh.

Spolsky:   You just have to learn that: if it's a tree, or a hierarchy, like eighty per cent of the regular people are going to get confused and not quite get it.

Hierarchies are great at showing nested relationships, and they make sense to programmers, who are used to them – but most of the time the relationships don’t matter to the user. Usually the user just wants to find something and yet the tree view forces them to “drill down”, clicking down into a hierarchy that becomes increasingly complex as they click.

My request to all programmers placed in the position of having to design a user interface: avoid hierarchies unless you truly believe the end users really need the hierarchical information.

I posted my first question on Stack Overflow today and already it’s had a couple of replies. I can see how Stack Overflow could become a little addictive because it has elements of a game built into it. For starters, you build up reputation points, which you get from other people by providing answers, but you need some reputation points before you can start giving points to others, and you can’t comment on other people’s answers until you’re above a certain rep level.

Have a listen to Hanselminutes Show 134 to hear Jeff Atwood, CEO of Stack Overflow, talking about the concept of the site and what they’ve done to make it an appealing place for software developers to hang out. The bit that really struck a chord with me was when he described Stack Overflow as sort of an antidote to Experts’ Exchange, the latter being a site that really rubs me up the wrong way because of its underhand tactics. There are so many times I’ve searched for something technical on Google and found a hit that looks like it might provide the answer I was looking for but I don’t notice it’s at Experts’ Exchange until I get there and discover the details are obscured because the site is run as a private club, which I refuse to join.

I like Stack Overflow. The only thing I don’t like about it is that I think its search facility is very weak right now. If you want to find stuff it’s best to use Google, like this:

http://www.google.com/search?q=site:stackoverflow.com/questions YOUR QUERY

For example:

http://www.google.com/search?q=site:stackoverflow.com/questions online help

The other aspect of it is that, if you’re not a programmer – or even if you are – it can be an intimidating place for the newcomer. You have to brace yourself and be prepared to be told you’re an idiot and should go away and never darken the doors of Stack Overflow again. But, in some ways, that’s not altogether a bad thing. It’s intended to be a games room for professional programmers – it’s not designed for just anybody to go and find an answer to any old thing. But, unlike Experts’ Exchange, everyone’s allowed to come in and wander around and listen in on the conversations. However, if you try answering a question you’re not qualified to answer, or you start asking questions that should have been asked elsewhere, then you can expect the regulars to give you a hard time.

I was late leaving work this evening and I was rushing to close down my applications so that I could shut down my laptop. I closed a Word document and immediately pulled the cable to my second monitor. The following error message popped up:

This isn’t a Photoshop job, it’s a real error message, presumably tucked away in some remote corner of Microsoft Word.

Update:

Turns out it's nothing to do with Word (more's the pity). It's a "feature" of Notepad++, which is my text editor of choice right now. I must have been closing down Notepad++ at the same time as Word.

I've got to admit I'd always had a jaded opinion of the Agile software development methodology. From what I knew of it - no detailed requirements document, no functional specification, no prototyping, no design thoroughly first then build it - from all of this it seemed to me that Agile was something dreamed up by a software developer, for software developers, but a potential nightmare for testers, technical authors, marketing, sales and support. To me it seemed like Agile was a kind of a "let's just bash on and make it up as we go along" approach that left developers free to do whatever seemed best (or maybe just easiest), without being tied to anyone else's plan, or maybe any plan at all. And, as a technical author, how do you document something that's evolving from day to day according to the whim of developer?

So that was where I was with Agile until the week before last. Not hostile to Agile, but definitely skeptical.

Then, as part of the restructuring exercise that's underway at my work, I spent a week with MarketAcuity CEO and Agile guru Sam Bayer. I'm not entirely sure what Sam's mission was: whether he'd been tasked with introducing Agile product development to the company, or just talking us through the Agile methodology. He has a very laid-back, discursive approach, so it's hard to tell. It never felt like he was trying to teach us particularly, more like he was just talking with us about one way of doing things.

We started with some basics of Agile product development. What's the point? Answer: it's about accelerating value to the customer. The 4 pillars of Agile:

• Customer
  The process is centred around the customer. It's not about producing some new, cool product because it's something we think would be interesting to work on, or because it's this year's big thing. It's about finding out what our customers and potential customers need and value and doing that for them.
• Demonstrations
  Show your customers the real production software (not a prototype or a smoke and mirrors job) on a regular basis and get their feedback.
• Iterative
  Build something, demo it, get feedback, build some more, and so on. Demonstrations could be a week or a month apart, but probably not more than a month apart, and always on a regular schedule. Don't go away and work on something for six months or a year only to find at the end of that time that it's not really what the customer wants, because they found it hard to explain, or you weren't listening, or they changed their minds/personnel, or the market or operational environment changed.
• Collaborative
  This isn't the waterfall approach. There's no leader passing down commands that must be obeyed. Within the company everyone's got a role and a job to do, but these aren't set in stone with high walls. The team have to work together according to their knowledge and abilities to get the job done. And, looking externally, you've got to collaborate with the customer and bring them into the process.

Another concept that, first off, I found puzzling was that, as well as accelerating value to the customer, Agile helps you to accelerate failure. Sounds bizarre, but what it means is that if you're producing the wrong thing, or you've made bad decisions, or misunderstood the market, you get to realise this much earlier. You don't work on a project for a year, then have a launch and suddenly get hit with the truth that potential customers don't really rate what you've done, and the stuff they really want is missing from what you produced. If you're really going nowhere with a project then it's much better to find out soon, cut your losses and get on with doing something profitable.

All of this, and more, makes perfect sense to me. But it really wasn't until day 3 of the week that things really clicked with me. A lightbulb went on and suddenly I saw a way of doing this product management thing successfully.

So now I sort of feel like a convert to Agile. It fits with my way of thinking. Don't overcomplicate things. Don't weigh yourself down with a ton of process and procedure rules. Do one thing at a time, bit by bit. Tell the truth. Don't pretend you always have all the answers. Talk to people. Get their opinions. Keep talking. Keep listening. Be prepared to change your mind.