Tag: development

Standard Bearing

An end-user may not notice or care if you stick a form class on your form element, but you should. You should care about bloating your markup and slowing down the user experience. You should care about readability. And if you’re getting paid to do this stuff, you should care about being the sort of professional who doesn’t write redundant slop.

Tim Baxter in 'Meaningful CSS: Style Like You Mean It'A List Apart

I've had this argument with colleagues a lot over the years. Attention to detail is important. The errors that come from a lack of attention to detail are what used to separate professionals from dilettantes. It doesn't matter that most people won't notice. It should matter that you know the difference between excellence and slop and that you reach for the former and are ashamed of the latter.

It's why having standards is so important.

Ignorance, teamwork and Agile projects

I've done a lot of work with Agile development teams in the past few years. I like the Agile methodology. It makes a lot of sense when building software applications and, especially, when everybody is working on only one product for an extended period of time.

In every Agile team I've been in, though, there's always this talk about how working in Agile is being a sport-like team. The project management methodology is full of sports terms like "sprint" and "scrum".

Great teams move like a single unit, everybody knowing their position and their teammates' strengths and weaknesses. This is never instantaneous. Teams have to work together and train together for weeks, months or years before they develop this mutual understanding and exist as a whole.

But sports teams have something else, as well. They have established rules of the game. Preëxisting constraints exist and are known throughout the training period and worked within, long before the team reaches a competition level.

Rules of a game are like contracts. They exist to protect participants, ensure that everybody is treated fairly and, most importantly, they remove assumptions.

Assumptions are a killer. Assumptions will be the reason any team or project falls down. My job in the User Experience field is about identifying assumptions, exposing them and dealing with them in an open and honest manner. I'm like a lawyer for interaction design. I have to either remove the assumption or make everyone aware of it.

Establishing rules is not as much fun as designing interactions or building code that produces kick-arse animations through parallax scrolling. In a world where most people don't even like to try to use the instructions that come with Ikea furniture, convincing people of the necessity for rules and their adherence is almost impossible.

Through the past few weeks I have spoken around town about ignorance and the role it plays in being a better designer and developer. This is not just a talk about working with clients, though. It's also about how we work with each other.

In a team, players have clearly defined roles. When I put a team together I am constantly looking at the roles that we have covered, if there's any doubling up and, more importantly, if there are any holes.

Not everybody in charge of a team will do that, and that's fine. But we can define assumptions in that case. The assumptions by the person putting the team together might look like this:

  1. We have a job to do with a defined goal.
  2. We have a sufficient team of dedicated and skilled people to achieve that goal.
  3. These dedicated and skilled people will communicate amongst themselves to work out how that goal will be achieved.

Assumptions are often exactly like this: a kind of pyramid in which one builds on the next. Identifying problems often means excavating through assumptions until we recognise the source. Excavation takes a lot more effort than building.

It's much easier to remove assumptions before they become problems. It's much easier to establish the rules of the game up front, before strapping on the special shoes and heading onto the playing area with the required equipment. (Note: It's very difficult to create a sports metaphor while also trying to be code-agnostic.)

Earlier I said that rules of a game are like contracts. There's another way this is true. They need to begin with negotiations. New players bring new skills and different experiences. The team needs time to negotiate through these experiences and ways of working or playing. It takes time to find the common ground.

It's okay for this to happen on the field if the stakes are low. But if there's money, livelihoods, share prices or mutual respect on the line, then there better be a lot of pregame honesty, awareness and practice. There must be a way to recognise, acknowledge and overcome assumptions.

Otherwise your whole team metaphor gets thrown out the window and all you have are a bunch of people who didn't want to write a requirements document.