mashed cauliflower, a photo by olgucz on flickr

Mashups were all the rage but a few years ago! Every Web developer and her dog were creating a “mashup application” – most often a few layers of points of interest applied onto google’s great map APIs. In that sense, it is true that a lot of the current applications of MAR are a new spawn of the mashup hype.

Fast forward a few years, and the world mashup is hardly ever uttered – or at least, very seldom without a hint of sarcasm. Most of those “mashup” applications have died, and google did a very smart move by not only allowing everyone to layer information over their maps – they actually let everyone integrate the rich maps and data on anyone’s web site.

Mashups are dead, but their progeny inherited a lot of the contemporary web landscape: only because of the mashup hype and the experimentation it prompted do we routinely think of the web not just as a collection of page, but as a large set of linked data that can be packed together into rich, cohesive units of information. Many of the “useful” tricks of the day, be it facebook connect, feed aggregation or the new portals (hah!) owe their existence to the stickiness of the mashup buzzword.

And now, for something completely different: my secret for a great veggie mash is a bit of butter, a dash of olive oils and a sprinkle of australian herb salt. That or a red wine stew sauce, actually…

Fast forward a few years to a new job, a different working context, and I find myself realising that mistakes I see around me are too often due to people’s incapability to say “no”. Being afraid to say no (when it matters) to colleagues, clients, boss, users or subordinates generally leads to one thing: the loss of trust and respect. So here’s a patchwork of situations when saying “no” is actually the right thing to do.

Management is the art of saying “no”

A few years back, I recall becoming fairly upset at my management: I would get myself invited to the directors’ meeting to bring up, again and again, issues which I thought were of the utmost importance. The management would agree with me that the issue was indeed a big problem, and usually proceeded to pat me on the head and encourage me to keep doing my best. Why weren’t they helping me fix a situation they agreed was noxious?

I later learned the mechanics of about any decent manager:

1. Are you coming to me with a problem but no solution? Go away.
2. Are you coming to me with a problem and some vague solution you kind of would like to brainstorm about? I’ll reply “no”.
3. Are you coming to me with a problem, and a set of solutions you’re ready to defend if I challenge you, and ready to improve if I embrace them? Let’s talk

In the words of past W3C colleague Dan Connolly: Management is the art of saying No. The refusal ritual is not just a tool for busy managers to manage their budget, it can actually be a very powerful way to lead and enforce a culture and the organization’s objectives. I recently found one such example in the book Collaboration by Morten Hanser, which devotes a whole chapter to “when not to collaborate”.

Saying no to your boss

Remember saying yes to that one week-end of work, because there was a project to rush out of the door? Remember saying yes to helping that colleague with his or her work, even though it had nothing to do with your own assignments? Remember saying yes to working a little longer that week, because the workload was particularly high?

Either of those taken separately are examples of chivalrous, courageous behaviour, and for some of us, there is absolutely no issue, and we will keep saying yes, yes, yes… until…

Remember ending up in the “hero syndrome” situation, where you burn out because you’ve said yes to too much, because everyone around you started taking you for granted, because you’ve been so good at doing so much that it would be a shame to call for help?

The biggest challenge of my work career – and my whole life, actually – may have been to learn this lesson. To know the freedoms I value, to stand my ground on the compromises I am not ready to make, and to be subtle but clear when I am making an exception. Learning to say no has made me a more respected and liked colleague, not less… and a happier person, too.

Saying no to your users

When you are building a product, the game usually goes like this: you realise that in order to succeed you somehow have to listen to your users/customers. So you listen, and boy do those customers have requests and great ideas. So you start adding all those features, considering any complaint as a life-threatening bug, burning money and time to keep up with the demands. What you usually end up with is an inconsistent, ugly, unusable patchwork of a product (hello, Photoshop!) which customers eventually desert.

The point of course is not to shun everything your customers demand and pretend you know better – it’s about upholding the clear vision you have for the product and, as the 37signals folk would say, Make each feature prove itself and show that it’s a survivor.

I like what Steve Jobs (himself a terrible dragon of a manager, apparently) has to say about innovation: innovation comes from people meeting up in the hallways or calling each other at 10:30 at night with a new idea, or because they realized something that shoots holes in how we’ve been thinking about a problem. It’s ad hoc meetings of six people called by someone who thinks he has figured out the coolest new thing ever and who wants to know what other people think of his idea.
And it comes from saying no to 1,000 things to make sure we don’t get on the wrong track or try to do too much. We’re always thinking about new markets we could enter, but it’s only by saying no that you can concentrate on the things that are really important.

For more on this, I very much recommend going through Stephanie’s slideset on “Defying the Itch to Stitch”, where she explains how a great product is not about outdoing the competition, but about creating an original vision for your product.

Saying no to your clients

Likewise, in an agency or freelance context, most of us are often terrified of saying no to clients, in fear that they might just get someone else to work with them, someone more accommodating.

That may happen if you behave like an asshole, or keep saying “no” without ever making a convincing case for it, or bringing valuable alternatives.

But as my experience shows without a doubt: only juniors and amateurs always say yes; the expert will think things through, sometimes agree, sometimes say no and suggest a better alternative, and earn respect in the process.

What do you think? Has is your experience of saying “no” been a positive one? Share your insight in the comments, but remember the rule: all your comments have to start with “yes, and”…

A few weeks ago, Apple, a leader in sales of mobile devices, apparently started contacting selected developers with one message: stop assuming that you are building applications for 320×480px screens.

Score one for flexible design.

So, how can one create applications that would feel and work great in the current fragmented market of web devices? I’ve had, for a long time now, a hunch that web standard technologies such as HTML and CSS had the answer. HTML and CSS were made to meet this challenge, to build interfaces that scale, to cascade differently according to the media. The new CSS3 Media Queries pushes this capability quite far already, and I have been looking forward to experimenting more with it.

I was surprised, however, by a very interesting new trend: HTML+CSS+JS are being used not as the final UI layer for web applications, but instead as a programming language to be compiled into other languages (such as objectiveC, Java etc.) and the deployed, with native UI look and feel, onto a variety of devices.

This is the strategy currently followed by Nitobi’s PhoneGap and Appcelerator’s Titanium, both of which allow development using the basic Web technologies and JavaScript API, and package the result into “native apps” for iPhone, Android (and blackberry).

This could be a very exciting development for web standards as base layers for everything on the web… including applications that have very little to do with the Web paradigm. And for designers and developers, this could be the solution to the conundrum of flexible design and multi-platform development.

Score two for flexible design.

Re-reading this review after watching Where the Wild Things Are makes me appreciate it even more. WtWTA is a honest and beautiful rendition of the joys and pain of being a child growing up. This is the movie children would make if they had a few million dollars and the talent of a Spike Jonze – instead of being usually limited to horrible crayon drawings.

Whether it is suitable for children is besides the point, the good question is whether adults can deal with it. Whether, as an adult, one is ready to open up to deep, old, primal pleasures and hurts. Wanting to be loved, wanting to be the center of attention, hating the awkward silence after a good joke, realising you are the bad guy in the story…

Life as an adult, too, is “all fun and games until someone gets hurt” – but we too often forget.

To help me avoid the mistake, I keep repeating to myself this simple sentence, inspired by the insightful David Rollert:

In a war, a general will have a goal (e.g. achieve fast victory with minimal losses and no civilian casualty), which combined with an analysis of the situation will result in a strategy (e.g. play the surprise effect, blitzkrieg, etc). The strategy will then be put to effect on the ground through tactics (e.g. attack here, attack there, and reinforce defences there to alleviate the potential impact of a counterattack).

If I’m not too far off, I hope this may help me ban misuse of the dreaded s-word from most of my daily conversations. Wish me luck.

P.S.: nothing wrong with not being a strategists. Any war will need many more able tacticians than strategists.

P.P.S.: make love, not war.

Any good reading you would recommend in this area?

The past months have seen me navigating in many ends of the Web spectrum, from the academic to the commercial, from the purely technical to community or business facets. Each time I have been considered an expert, a senior, a veteran. Which, as far as the Web is concerned, I am. I also happen to be in my early thirties…

Yesterday I realised how humbling it is to meet people with decades of experience in their field. We the websmiths too often forget that being a senior after 3 years and a veteran after 10 years is an anomaly. Let us never forget how young the Web is.

Bixi is the new community bike service here in Montreal. Lots of brewhaha around launchtime, but to me, the really annoying shortcoming of the system so far was not being able to check the status of stations on the go.

According to a message I read on the facebook group for bixi a few weeks ago, there is “no plan to provide an API, iphone app or mobile access to the map of bixi stations”. That’s rather silly, knowing that the users will want to know, in real time and on the go, whether they can get or return a bike nearby.

I’m too lazy to build a real iphone app over the week-end, but I wanted to prove that it doesn’t cost tens of thousands of dollars to provide bixi users mobile access to the status of the stations.

30 minutes and about as many lines of python later, I had a working hack to include a map of all stations in google earth, google maps or the map application on my iphone.

iPhone Instructions

Here’s how to use it on the iphone (or networked iPod Touch):

Disclaimer: I built this using only publicly available data – not a public, official API, though. If the powers-that-be at bixi decide they don’t like it, or change the way they organise their data, or any other silly move, I’ll have to pull the plug on this little hack. In the meantime, I intend to use it and provide it for free. Enjoy.

There does not seem to be a lot of existing resources or information on the Web about this role. “Web developer”, “Project manager” or “Software architect” all have their wikipedia entry. Search for “Web architect” in wikipedia and you will currently be redirected to a page on Web design. Wrong, wrong, wrong… There is indeed a page for Website architecture, but it still needs work.

In the Web industry, the “architect” title has long been hogged by Information Architects, and the Web Architect is generally called “Tech Lead”. That name is problematic, however, because it implies that the lead has evident authority on the development team, when the reality is often one of much responsibility, little authority: the tech lead seldom has authority by virtue of being a manager, but gains authority through the building of trust and effective mentoring.

The good news is that the Info Arch world is reinventing itself as “User Experience”. This is an opportunity for web architects to reclaim a title that makes more sense: architecture is about knowledge of complex systems, design and technology, and nurturing a project from beginning to end.

Still, the fact is there aren’t a lot of good resources yet on the Web explaining the work we do. I decided to collect a list of resources for Web Architects, mostly for my own consumption, but if it benefits others, even better!

Know the Job

In a nutshell, my understanding of the job goes:

• Provide technical vision at every stage of the project, from feasibility to delivery.
• Build specifications and/or prototypes. Do it with a team, not alone.
• Participate in development and own responsibility of architectural consistency, quality, documentation, code reviews, testing.
• Know the methodologies and development processes and frameworks. Get teams to use the right ones for the right projects.
• Develop and maintain expertise in the team through research, exchange
• Communicate, communicate, communicate. Be a bridge between people who don’t speak the same language but need to work together.

One of the fairly good resources giving generic advice on being a Web architect / Tech lead is a tutorial by Daniel Pietraru called 36 steps to success as technical lead.

I don’t fully agree with all of them, but they all carry some wisdom if understood and applied well. Number 27 (Be sure you have authority along with responsibility) is a good summary of the Architect’s odd position, of responsibility but not always authority – the latter is earned, not given.

Number 7, too (Get your hands dirty and code) can be a great way to keep one’s skills sharp, earn some respect from other developers and help deliver projects on time, but they can also drag and confine you in a role that isn’t yours. An architect is not a developer – and there are responsibilities in the architect’s job that require a creative mindset.

There must be quite a few experienced tech leads/architects out there with worthy experience to share. Jeremy Miller has a good article on the Classic Technical Lead Blunder. I’m on the lookout for more.

Learn the Tech

Regardless of how much hands-on the architect role has on a given project, the need to know the stuff can not be underestimated. This doesn’t mean you have to know everything – it’s healthy to not know, even healthier to know when to ask, and know when to do your homework.

1. Spend time on the W3C’s Web site. No, really. Keep an eye on “best practices” on Accessibility, Internationalisation, mobile Web and of course Web Architecture.
2. Can one be an expert in every possible programming language? Probably not, but worth a try. On the Web today, you probably won’t be able to survive without php. Do keep an eye on python (the Python: Visual QuickStart and Beginning Python from APress come highly recommended, and I love Doug Hellmann’s python module of the week), django, Ruby on Rails…

Learn to think like your team mates

One of the most exciting parts of the job is that the architect works with almost everyone involved in a web project. This means we need to speak their language. We need to speak marketing and strategy when assessing the project, we need to speak project management with the PMs, we need to speak design with designers, UX with UX, speak code with developers, speak test with QA. Here are a few books and resources that help become polyglot in no time:

1. Read Boxes and Arrows on a regular basis, and infuse the vocabulary and mindset of User Experience. I also like infosthetics and GUUUI. Read Jakob Nielsen too – if you must.
2. A good architect needs to know about the different frameworks and methodologies for web project management. I found Mike Cohn’s Agile Estimating and Planning to be the best book on agile project management, period. Real Web Project Management is not bad, either, although obviously made for a more novice audience.

Know the process. Know when not to follow the process

One risk, as an architect, is to be dogmatic about architectural or process changes. We all have a favorite way of running a project or building an architecture, but not all projects would be better off as scrum, and not all development benefits from test-driven development. That said, one first has to know the tools, know them well, before knowing when not to use them.

Specifications: joelonsoftware has a piece on “Why bother with Functional Specifications”?

Tech specs, however, I remain conflicted about. Most of the time, the technical specification is a long, painful document that nobody will bother reading. Several agree, calling for the death of the web technical spec, but others still see value in it.

In my first weeks on the new job the most important problem I identified was that the team created specs that nobody could really use. We’re in the process of improving our specs with the help of User Stories. User stories are often seen only as a tool for agile teams to evaluate work, but even in non-agile environments, they provide a clear checklist that can be used by everyone: the client can validate a real list of scenarios, the project manager can keep track of work done and remaining, developers can reuse the User Stories within a test-driven or behavior-driven development method.

Test early, test often. A good way to release software with fewer bugs and a quicker path to fix issues is to apply some level of Test-Driven development (and unit testing), or more recently Behavior-Driven development. For the architect the work of bringing TDD/BDD to a team will be as much technical as human, so you may want to read articles like this one and learn how to sell, and how not to sell, TDD to your team.

Tool-wise, look into rspec for ruby, junit for java and unittest for python. For php I quite liked the SimpleTest library.

Productive Tools

Doing this job well implies being good at managing people, knowledge, code and time. Patience and soft skills are the tool of choice for managing people. For the rest, a quick selection would include:

tracking ongoing work and todo lists – Things remains to this day my favourite in this area, though others will swear by iGTD or OmniFocus. If you’re hesitating, know that others have gone through this too, and see which choice they made, and why.

QuickSilver (or other similar launchers if you are not on Mac) can save tons of time on a daily basis. The real time-saver however, is to learn one’s text editor inside and out. I still love TextMate to bits and want to learn more tricks with it… even if my daily routines sees me use spreadsheets and text processors more.

For more suggestions of tools and methods, The Productive Programmer is a very decent read. It did not teach me anything I had no clue about, but it was a good validation of some simple, solid principles every developer, or anyone working closely with developers, should be reminded of on a regular basis.

Keep a sense of humour

Because it won’t be easy every day.

This list of resources will grow over time. If you have any suggestions, or disagreement, the comment box is right here ☟.

One of the things I heard most often in recent talks was “the problem is we stopped caring”. I would almost agree with it it if didn’t remind me so much of the 80-years-old pianist who tried to teach me a couple of decades ago, but mostly managed to bore me with recurrent tales of how “things were better before”.

Have we stopped caring? This question brings back a memory of a work teleconference that happened a few years ago.

With 50-ish people of different cultures and backgrounds on the call, one of my colleagues (let’s call him Charles) made a rather rude, sexually connotated joke – a joke that would have passed quite well in his native France, perhaps, but made a few people, including one US female colleague (let’s call her, em, Julie) rather puzzled and mad. Julie wants to tell Charles off for his crude joke, but diplomatically asks – still on the call with 50 on the line – for a private conversation afterward. Charles replies “I don’t care”, making Julie even more aggravated.

What Charles actually wanted to say was “I don’t mind”, i.e. “OK, I’m not sure why you are upset at the joke but let’s talk as tolerant, intelligent people”. But for a non-native speaker of English, “I don’t mind” was just a slip of the tongue away from “I don’t care”…

Every time I hear one of the genial minds at TED lament “we have stopped caring” I can’t help remembering that incident. Surely, we have stopped minding. The past century, I want to believe, has made us humans much more tolerant: too many wars have flipped most of us away from xenophobia, large middle classes away from class hatred, globalization away from racism. Tolerance, which originally means “the ability to endure pain” has become an unquestioned virtue of our liberal-democratic societies.

We definitely have stopped minding, but have we stopped caring? In societies where not being upset at alien concepts or behavior, in cities where somehow the notion of community has been lost for the the protection of our sanity in a crowded environment, the line between tolerance and indifference is indeed thin. Has our (western, mostly) society made a collective, unconscious slip of the tongue from “I don’t mind” to “I don’t care”? Perhaps, but I’d like some proof that this isn’t just the old grumpy person in us complaining that “good old times” were better.