How does a person who has lost confidence in there abilities, get it back?

Posted in Uncategorized | 1 Comment

Never jump to conclusions

Never be to fast to jump to conclusions. For example suppose a friend take over a week to reply to your email about expecting a new baby. Maybe it’s not because they don’t care, maybe it’s because they lost all their money at a stag do in Savannah, and then got lost in the projects for 4 hours and then missed their flight home. I have some great friends.

I on the other hand am shit at keeping up with my friends news, and have no cool excuse. I should be better at this thing. I find it very hard to sit down and right a emails to the people I have fallen out of contact with. I think it’s a combination of shame for having been such a crap friend and not keeping in contact, and the fear that they’ll either not reply, or reply with indifference. If believe you have ten friends, then by never contacting them you can’t find out that you actually have no friends.

It doesn’t help that I find it easier to write about esoteric garbage than to write about my life. I think there’s something in the rules of friendship that says you can’t start an email to someone you haven’t spoken to in 9 months with a rant about JQuery, or a missive about what a cock you think P-Diddy is. Shame that.

Posted in Uncategorized | 2 Comments

Design by misuse – Stockholm Scope Creep

A colleague and I identified a specific genus of Scope Creep today. I have labelled it Stockholm Scope Creep*, as you essentially end up helping out someone who is holding you hostage. It is also an example of design by misuse.

Essentially it works like this:

  • You build a system.
  • Someone deliberately or accidentally misuses the system to try to achieve some functionality that the system does not perform.
  • Despite the fact that the system does not do the said functionality, the someone takes their project so far that you are forced to change the system so that it does.

A perfect example would be a client taking out full page newspaper adverts saying that the company website now accepts payment in pine nuts, there by forcing the eCommerce team to add a legume payment method to the credit card screen.

Some classic real world examples I’ve been involved in:

  • People publishing URLs that they aren’t supposed to use (but it’s already printed in the book).
  • Designers redesigning an existing user interface, producing a picture of functionality that isn’t currently supported, and then showing said designs to management (“I know you love the designs sir, but could we just remove the button that says ‘View Products in 3D”).
  • Data authors setting configurations that should never have been allowed (It’s a product, it’s enabled for sale on our eCommerce site, but it doesn’t have a price because it’s not launched til next year… and you only want it to be visible to people with stuffy head colds).

On the plus side often this Scope Creep occurs because a system really should perform the additional functionality, and the user just assumed it would (“I just assumed that if the system lets me add a product to my shopping cart, that I would be able to buy it”).

But often this is just an annoyance. It is the equivalent of my standing naked in the office kitchen, phoning Facilities and demanding that they install a shower (“I don’t care that its not what the office kitchen is for, I’m naked now, I need to be soapy”).

Mild Stockholm involves the misuser sobbing gently down the telephone, not because they have set things so much in stone that you can’t back out, but because they just really want it to be this way… Please. In those cases you do it cause you love them (and because you’re a soft girlie man who can’t say no).

A variation on Stockholm Scope Creep is Paris Hilton Scope Creep. With Stockholm you’re hostage to the circumstance that arises from the users enthusiastic follow through on a functionality that doesn’t exist. In Paris Hilton Scope Creep you just get an idiot shouting at you and telling you to build it cause they want it. The best solution in this case is to wait until they pass out on ludes, or pims, or plum and jack D, and then smear dog food on their faces in the hope that their rank little handbag puppy gets bored of choking on sanitary products and chews off their owners lips. (Ohhhh!!! I went very dark there… sorry. Not a Hilton fan).

*Creep. I toyed with Scope Creep Pride because if this type of creep could chant it would say “We’re Here! We’re extra unplanned work! Get used to it!”.

Posted in Projects | Leave a comment

jQuery Vs Prototype (Shallow dive 01)

I use Prototype, I haven’t used jQuery, but realise that everyone else is. So here’s my first shallow dive into the differences between them:

Prototype: The $(‘someId’|DOM Object) functionality of Prototype returns a DOM element object that has been extended to have a variety of new utility functions. $$(CSS Selector) returns an array of Prototype extended DOM elements.  The ultimate upshot is that the DOM object becomes super powered, and you just call methods on it.

jQuery: The $(CSS Selector|DOM object|null) returns a jQuery Object. The jQuery object has a bunch of useful utility functions. The jQuery object also acts like an array (in the code they use this[0] to attach a 0’th element to the jQuery object, and similar techniques later for longer arrays – making me thing it’s really just using numbered properties, with some prototypes array functionality chucked in), containing all of the DOM objects specified by the passed in CSS Selector/DOM Object etc.

I haven’t gone into all the extended functionality, but I’m sure all the usual suspects are there (DOM manipulation, AJAX, Event binding etc).

The Key thing here to me is that with Prototype I have the object and can run the functions (methods) attached to it. With jQuery I have this object which I can either access to return my DOM Objects, or use the functions it provides. Each of the functions it provides chain themselves (each functions return value is the jQuery object), so as long as you’re chaining jQuery object to jQuery object you’ll be good. Just don’t leave jQuery and do something else.

I’m assuming therefore that the internal jQuery functions act on the complete pseudo array of DOM elements.

Many of the functions seem to take callback functions, most of which would see to be bound in such a way that the “this” property of the callback function point to the individual element. This is implicit in code like this:

    $("p").click(function () {     $(this).slideUp();     });

$(“p”) – Creates jQuery Object with all of the DOM’s Paragraph elements attached to the object in an array like fashion.

.click() – A function (method) of the jQuery object that binds each of the paragraph DOM objects to a click event. In the example it is fed an anonymous function as an argument.

this – The “this” inside the anonymous function points to the element on which the click occurred. It isn’t a jQuery object it’s a DOM object. I’m assuming it’s been bound this way by jQuery, although maybe they do something clever with the returned Events object – same result either way.

$(this) – the returned DOM object has to be converted back into a jQuery object before further chaining can occur.

.slideUp() – A function on the jQuery object that makes the DOM object in question (the individual paragraph we clicked earlier) slide up.


Prototype super powers the individual DOM element with new properties.

jQuery leaves the DOM objects as it, but instead provides an object that holds super properties and an array like collection of DOM object.

The result is that jQuery can act on many DOM nodes all at once. You don’t have to think about the singular node, rather just define the effects you want to happen to all the nodes defined by your selector.

On the downside that does mean that you don’t really want to come outside of jQuery and play with bog standard JavaScript because you loose all of that multiplicity. Prototype does keep you closer to the JavaScript world, just in an augmented way.


Posted in JavaScript | Tagged as: , , | Leave a comment

The Project Process

It seems to be an accepted fact that many technical projects fail, over run and generally fall short. Despite this people still apply the same business processes time and time again.Lets consider the average web project.

You gather a set of requirements in an hard to read document, you pass the document around via various involved groups who poke at it and take it into dark corners for a grumble, maybe add some corporate graffiti in a manner not un-akin to a stoat peeing on a found sandwich to mark his property (I’m assuming a male stoat). At some point someone writes out an LOE (Level of Effort: A set of fictitious number that represent how much a person actually wants to work on a project. The higher the number the more they want to put everyone else off doing the project).

While this lackluster analysis is happening, someone else will be employing a design company to create an interface containing functionality never previously considered by a sane person. The design company happy in the knowledge that they won’t have to build the project will include things like scratch and sniff images, and a “hug me to purchase” cart functionality. They will suggest paths to non existent information, which they will represent with the words “Lorem Ipsum”. They make up all of this fantasy whilst naked from the waist down, wearing hats made out of burning money. They sacrifice many goats and manatees, in return for Satan’s help in creating a very beautiful PSD of a website that cannot be built in the human world.

Now it is build time. The ratified requirements document, and the impossible design are laid on the altar of the chief technical Hoo-Waller. He studies these artifacts and then, with a whoop from his warrior clan of disinterested teenagers and assorted OAPs (Old Age Programmers), he wipes his nose on the documents and proceeds to invent his own system that is both easier to make, and ignorant of the artistic-contenty-fiddle-faddle that limits the foolish mere mottles he is forced to pander to.

Then the stew begins. For a number of months and weeks people hide in their offices and “do the project”. No one group really knows what any other one group is doing. Oh there is reporting, and mile stones, and issues to be resolved, but ultimately everyone is separately involved in making there own individual  project. There own interpretation of the design and the requirements…

…see here’s the thing (and where this whole pointless rant comes from). I don’t think anyone in this process ever really gets to talk about the actual “thing” that is being built. The technical people see a technical thing with properties and behaviours that match the properties and behaviours outlined to them. The Design people see a design thing, the content people see a content thing. The managers see a time schedule and a budget, the marketing people see other attractive marketing people. All of them are involved in creating things that match the loose description of what was promised, but achieving it from the point of view of their world.

No one wants to stray into the other groups domain and really get to grips with what anyone else is creating, because we’re all obsessed with our own little worlds. We all think our bit is most important, and never subordinate to someone else’s views. And here’s the kicker, we’re all making the same thing, aren’t we? A thing is a thing. 1 = 1 doesn’t it. A thing can’t be one thing to him, and another thing to her, and another thing to me. We described it, and we decided what it was before we built it.

I recently described the project requirements as the shadow on the wall. Everyone agrees on what shape the shadow on the wall is meant to be, but the project is to building the thing that casts the shadow, which is a very different thing from the shadow itself. It can be made in so many different ways, and re-imagined by so many schools of thought. So of course projects slip. Of course everyone’s disappointed, it’s the only logical outcome of many people pouring there hearts into something only to discover that everyone else working on it is not interested.

It’s the reason why we all declare that everyone else on the project is an idiot. Can’t they see? What planet are they on?

If  I’m right (maybe I’m not,  maybe this is just a rant), then the solution lies in aligning the minds of those involved. I don’t know how you do that, not least because language is subjective and loose, and common understanding is prerequisite on common experience. You cannot expect to simplistically align all peoples points of view, and not everyone can know everything that everyone else does.

Part of the solution is surely to make sure that all people on a project are involved, and interested, and communicating. Not just in there little groups, but across all the groups involved. There must be empathy, which can be helped with good communication. And good communication shouldn’t demand that those involved make boring effort. Good communication invites interest by being interesting, and by doing much of the work for the reader.

I also don’t think you can buy in interested people. If you discard work to a group of people because you don’t care to involve yourself in its complexity, then you have no empathy, and you can’t expect those parties to try to make you interested, they’re not paid to do that. They will find there own fun in the work you have set them. Most likely they will build what they have to in the easiest way possible and deliver exactly the line items that were demanded of them.

Finally I think you can’t care about something that is too easy. It’s the same principal as the discarding of work to a third party. If you’re involvement in a process is a predefined selection of a button, then you are not involved. If you always just enter the address in the sat-nav and get taken where you want to go, then you will never be interested in the process of map reading, you’ll only ever be angry when it doesn’t work. With understanding of complexity comes empathy, that’s why electricians tend to not thump their TV sets. If you’re involved in a process, not just a slave to it, you’re likely to care about it more. That isn’t just a comment on technical involvement. You need to also appreciate the difficult of sculpting a great piece of content, or the agony of balancing the aesthetics of a web page. Or even the effort involved in articulating a clear set of requirements.

Back to shadow boxing…


Posted in Collaboration, Projects | 2 Comments

It’s very late…

You have a domain name for years, but you do sod all with it, because you spend all day making web sites. Who builds web sites all day and then comes how and thinks “I know, I’ll unwind by building yet another web site”. Actually the depressing answer to that question is probably billions of over enthusiastic web developers. Well not me. I’m too fecking tired.

Posted in Uncategorized | Tagged as: | Leave a comment