Reality = True

What Are you talking about?

It occured to me that I've been too harsh when it comes to people and the way they work.

People communicate for so many different reasons. Often when people are at work, they don't care about their job. Despite this, they'll go about their work, go to meetings, argue and look exactly like they care. Bastards.

Until now, I just assumed that if you're talking about stuff, it's because you care about it. But life has pressures that don't always mean that's the case. You can have a huge fight with your spouse, and then come to work and you're just expected to get on with work-life like everythings fine. The thing is, it's not fine, it's crap, and so when somebody suggests something you blow up and yell at them, simply becuase you can.

The point is that things aren't always what they seem, and this makes it really hard to tell when you're getting objective analysis and committment from people.

Some of the behaviours I've seen that get in the way of getting things done include:

I'm smart too
People will disagree with what you say simply because they are threatened by the suggestion. Perhaps they think that this is the kind of thing they shoud've thought of - the "turf" war begins. They can't fault your argument, but they'll dig in and disagree with stuff anyway. They may misinterpret your suggestion as a personal affront to their intelligence - and suddenly the real point of the conversation is not the issue at hand - it's all about proving how knowledgable you are.

Justifying My existence
Often people will be so intent on proving their worth that they'll take a point from the issue at hand and discuss it at great and unnecessary length, simply to allow others to see they are valuable. While these are often good conversations for people who might not understand the issues, they also slow everything down. If you understand and support an issue, you don't have to say anything.

Check me out
Sometimes people get so caught up in trying to impress people, that the issue becomes irrelevant. Angling for a pay rise, or trying to get a root.

Dominance for Self satisfaction
"The blues isn't about making yourself feel better - It's about making everyone else feel worse!"
Some people are difficult and horrible because bringing other people down makes them feel better. The issue is almost always irrelevant - it's more about the communication. There are times when I guess anybody under pressure will be dismissive or rude in the light of a perfectly valid idea.

So what do you do? Perhaps we all need a big sticker on our heads that lets our colleagues know when we're likely to impede the process of getting things done...

Maybe you just need to learn exactly when there is no point pushing the issue. If you suspect that the conversation shifts to anything other than the point, then you should just drop it.

More like a bridge too short…

Software Engineering is a discipline entirely unlike every other form of engineering. It’s more like sorcery. Any other engineer works constrained by the physical world; Their worlds contain concrete dependencies and tangible defined constraints – innate truths. Things that you simply know have to be completed in a particular order – for instance, a civil engineer wouldn’t set out to build a car park by suspending 10 parking floors in mid-air – My 3 year old son knows that you can’t do that. It just doesn’t work that way.

Software engineering is different. In Software land – anything you can imagine as a solution to the problem can be done. You can suspend floors in mid air – in fact you never need to build any columns at all. You can also modify the car parks to take up optimal levels of space. You could build specific car parks for specific models of car. All of a sudden, the rules go out the window in Software Engineering.

This is the cause of, and solution to all of the world’s software problems.

What if your software project was a bridge? What would it look like?. If I apply a critical, misty, metaphoric eye to Software projects I’ve worked on, I come up with some pretty interesting bridges:

BloatWare Bridge

This bridge has two huge suspension towers that support an industrial grade concrete platform that hosts a 10 lane, perfectly flat highway. Unfortunately nobody uses that. Most of the traffic on the bridge uses the maintenance tunnel, which was built very early in the construction process. The maintenance tunnel is pretty dark and narrow, but the engineering team are constantly widening it by digging sideways. There is of course a danger that this may cause the bridge to collapse into the tunnel, but so far, so good – it works, right? In order to further assist commuters there’s a matter transporter which dematerialises traffic and rebuilds it on the other end of the bank. Not many people use that either, because it uses too much power. There’s always the punt though – it cruises reliably back and forth across the water…

Several commuters insist on crossing by swinging from the suspension wires in a highly dangerous maneuver – something the bridge was never designed to support, so the engineering team have designed several floating air bags to catch them and restore them to the bridge.

Overkill Crossing.

This bridge is a striking impressive structure- that spans one side to the other like an enormous scaffolding of ultra-complex support framework designed to look foreboding. Underneath it all is a goat track that joins the two banks. Traffic generally slows to a crawl.

Asynchronous Weir

This is less of a bridge, and more of a bank-to-bank processing solution. Commuters arrive in cars and are attached to a flying fox which propels them via a small jet engine to the other bank. Their cars are then re-assembled using a specification that is kept in the glove box. If the car doesn’t have the specification, it gets ignored. Multiple passengers are supported, and if one member of the car fails to get to the other side, all passengers are returned to a holding lot and a flag gets hoisted to indicate a problem...

The point of all this silliness is that there are a million ways to solve a problem, and given all this power, there's a nearly overwhelming tendency for developers to just dive right in and start nailing girders together. Add to that the “wouldn’t it be cool if we had a…” factor, and you’re well on the way to a gnarly bizarre hard to test hard to fix piece of software.

So how do we get around this? Well the answer is disappointingly simple. We go back to our friends the physical engineers.
Put on your hard-hat, analyse the problem and find the dependencies in the solution. Write a comprehensive specification. Revise the design until your’re happy that you have the most efficient solution for the problem at hand, and everyone on the team knows exactly what your doing.

Until you’ve got a good set of blueprints, don’t build that first column.