WTFord

Being a software person I like to be precise with language.

Language, while not necessarily unique to homo-sapiens, is one of humanity’s defining characteristics and greatest achievements. Languages are magical, evolving, rich things which not only define how we communicate but influence how we think.

In his 1966 novel, Babel 17, Samuel R Delaney posited a human language, so precise and so compact that swathes of information could be communicated far faster than normally possible. However this language was sabotaged, by the omission of personal pronouns those speaking or listening to it could have no sense of self and thus were used as weapons, manipulated by their own minds into committing atrocities.

Modern computing languages are also weaponised in that a native speaker of Python or C can wield enormous power over the world in which their software is used. They are encoding the data structures and workflows by which we increasingly live our lives. A developer’s execution of a given problem can modify and define our behaviour often for years to come - and that execution is in turn only as good as said developer’s conception of the problem space, the instructions they have been given and the overall conditions in which they are working.

When software is good we don’t notice it. This is as it should be. When it is bad or becomes worse over time we suck it up and live with it, often not questioning the situation or looking for alternatives.

Look at Word and how it gone from something to write with (I used the original version on a Mac SE - and I tell you it was great) - to being the bane of writers everywhere. The formatting is buggered and the page numbers mysteriously start at xxi and don’t even go there with the indexing or table-of-contents features. We spend time wrestling with the foibles of the tool and our writing suffers. We normalise our behaviour around the tool and cease to imagine that it could be done any other way.

But why does software become shit? I think it comes back to linguistic determinism and very specifically, use of the word “just” when software teams and stakeholders are determining what they are doing.

“We will just do it this way.”
“Could you just make it do that?”
“Just make it this shade of blue.”

By saying just, you say you’ve not thought about it. By saying just you loose the why. If you don’t think about why, you are probably making something that makes people behave stupidly.

I conform to my own dress policy which I define as “the clean and reasonably respectable items in my wardrobe”. That does include shorts. Shorts are definitely allowed. Count yourself lucky that I’m not dressed like Sean here…

The story goes that a certain ginger lady of some notoriety saw me wearing a pair of shorts at work. A pointed email was sent out reminding us all of the dress policy, specifically that shorts are not allowed. And obviously she had no idea what was going on at the grass-roots of her own company on a day-to-day basis… Yeah right.

Most of my work comes through either recruitment agencies or word of mouth. That’s just how the contracting game works. Recruiters phone me up and email me and add me on linkedIn on a regular basis which is great and every now and then they have exciting things and I’m actually available and I say YES. Quite often though I say “no, I’m busy until suchandsuchatime”.

Experience has taught me to apply the following simple rules:

The rate I say is the rate I expect. If client X won’t pay it, someone else will. Do better. Don’t even try to beat me down on rates, it’s not happening.

Recruiters MUST tell me what cut they are taking. In plain simple numbers. This is a good policy for everyone - me, them and the client. Being up-front about it means nobody thinks the wool is being pulled over their eyes or that they are being ripped-off. It means we can’t end up in a situation later on where somebody sees the wrong paperwork and gets uppity. It means everyone comes back for more.

Meanwhile go forth o demons of the night and fetch me juicy corpses to feast upon!

For the majority of my software contracting life I have had clients who pay me by the day. So if I work, I get paid. If for some reason I only work for half a day I only bill you for half. If I don’t bother to get out of bed, I don’t charge you. That is all fine and (especially when I’m working on site) blatantly obvious.

If I’m working remotely and not expecting to have to get out of bed then it can become a bit more fudgey and may involve a few internal trade-offs of say a Wednesday evening coding on the sofa in return for a Tuesday hangover. It all evens out, especially as I can prove pretty much when I was and wasn’t working on things and Git commits are timestamped up to the hilt. I can’t prove when I was or wasn’t thinking about a project but am working on a robust system to do so :)

Sometimes my clients get it into their heads that the job is “fixed price”. I’d like to make it very clear to everyone that I do not do fixed price jobs. Ever.

The closest I come to a fixed price job is when I will say something like, “Ok so you’ve got enough budget to hire me for three weeks, we’ll reduce the scope of the project so it’s achievable within that timeframe and budget plus a bit of slack in it too hopefully.” This happened recently, only for my client to turn round and describe the project as “under specced” and expect to not have to pay me for significant extra work. That was stupid and I’m very cross that I let them get away with it.

While we are at it, piddly little changes add up. They take time. They are annoying. Piddly little changes are not necessarily quick and simple to implement depending on how everything was structured and the assumptions made in the first place. Piddly little changes may in themselves not be a good idea and are often a great way to delay the release of a project. They are far better stacked up and done in a solid run/sprint than tinkered about with in down-time while I’m supposed to be doing something else and don’t have my full mind on the job. They are also billable, hereon at double my standard rate pro-rata’d out unless turned into a standard planned day’s work.

If a client then turns round and asks for more (be that for any reason whatsoever) they should expect to pay me for my time.

Many of the projects I have found myself involved with in the last few years can be categorised as rescue missions. I define these as follows:

• You have an existing but incomplete codebase (with or without the original coders) 
• You have an existing design, project plan etc, which may or may not be sensible and may or may not have been adhered to.
• You have a looming (or already passed) deadline and are not confident in hitting it.

(see also Death March on that there wikipedia)

In short your project is fucked. Call me.

If you hire me on a rescue mission you have two options:

Plan A: Hire me to dig you out of your hole.
Plan B: Just hire me to do what I’m told.

Remember, there is no Plan B… but if there was you’d be hiring a slave:

• I’ll work for 7 hours a day (no I will not work until 3am) and do the things on the list. 
• I’ll shut up and not complain about whatever stupid ideas I’m expected to implement.
• I’ll do those things to the best of my ability but it’s up to you to manage my workload and understand that if the project is not in a good state already things could take a long time.

Unfortunately I have a problem which is that I care too much about doing a good job.

In the case of Plan A you will get an unstoppable machine:

• I’ll carefully evaluate what you’ve got, how it has been conceived-of and how the process of building it has gone to date. This may take a week. I’ll probably not look like I’m doing a lot for the first few days of this, but as Naomi Mitchison said, I’m “among you, taking notes.”
• I will re-plan the project and the expected deliverables in line with what is really achievable. It will all be totally agile.
• I’ll partially or completely re-design and re-engineer the project.
• I will restructure your working environment both physically and mentally.
• I will train your staff in better software engineering, design and working practices.
• I might subcontract elements of this process to other lovely experts or make you hire people.
• I’ll expect to learn from you too, I’d bet you’ve got under-used talent in the room.
• I’ll move mountains and swim oceans.
• We will ALL go home by 6 and on Friday afternoons we will all go to the pub, knowing that it is part of the plan and that the plan will not fail. We will not come back from the pub until Monday morning.

You will also accept the following terms:

• You will relinquish control over the project as otherwise you simply aren’t going to be able to let me do what you’ve hired me to do and there’s little point.
• You’ll understand that may not be a comfortable process for you. I’ll pull no punches and tell you when things are shit and need changing. Remember that there is less shame in presiding over a success than there is in presiding over a turd.
• I will interact with your end clients or internal stakeholders and I will tell them what they can and can’t have and why and (importantly) when.
• I’ll expect to talk with people in your organisation at every level from cleaners and catering right up to the managing director. I’ll certainly want your IT staff on side.

Rescue missions can be fun! Let’s get out there and twat it.

The project has been carefully considered, thought out, decisions made on the back of many years of experience in the given field that the product is supposed to fit into. Mutually agreed, signed off, pretty much ready to roll. And then someone comes along. Someone very important. The man or woman with the purse strings who ultimately is IN CHARGE. And what does that person say?

“Let’s make it shitter!”

Let’s take some fine detailed bit of user interface. Say it’s a website. There’s already a nice consistent navigation bar of some kind. You know what we need? We need another navigation bar somewhere else with the same things in it. Even better we should totally call the things in this other navigation bar something other than what they are called in the first one because people will click on them then! Yeah!

Oh and you know this blue colour that the designer has chosen for the buttons which tones in nicely with everything. Could we just make it a bit of a darker blue. And the text on top of it? Yeah that should be black.

Oh and can we have it send me everything that every user does. And their names and dates of birth. By email. So I know that they are using it. That’s going to be much easier to do than whatever this apey-eye thing you techie boys are on about and email’s free isn’t it.

Oh and I’ve seen this other thing somewhere else which it completely different from what I’ve asked you to do only I like this bit of it and think we need that too. That can’t be terribly hard can it!

What do you mean the system was never designed to work like that and that it will confuse the hell out of end users. I’m paying for it. And no of course I’m not paying any more, you should have done all this stuff in the first place, we agreed that!

Now kids… it is perfectly reasonable to listen to clients… sometimes they have valuable input and important things to say… but not when they are being dicks. 

Some clients get this, others don’t. It’s very straightforward:

1. A standard working day is 7 working hours. That’s 9-to-5 with a whole hour for lunch. Or 10-6 or whatever.
2. Anything more than this is entirely at the pleasure of the contractors and they are not under any circumstances (even if there is some enormous looming meeting with the corporate gods on Monday at 10:30) be expected to work extra. That kind of thing is a political/project-management problem, not a problem with the software.
3. Lunch is NOT at a fixed time. Neither are fag breaks. Stepping away from the desk is often the best way to figure out how to solve a difficult problem.
4. Clients will understand that coding is a BRAIN-INTENSIVE-JOB and we need to be relaxed and happy to be at our best. That means taking a steady solid pace, not burning ourselves out.

I should probably say something about hangovers, latenesses and so forth here… There’s systemic predictable ones and there are exceptions.

Systemic is fine if effectiveness is under control eg someone turns up at 11 every day, works till 7 and has a can of special brew at her desk from 5:30 like clockwork. But gets the work done and makes it to the Monday planning meeting without hiccough.

Personally I tend to be a smidge late in the mornings. I should go to bed earlier but I don’t and I cut my mornings fine. DO NOT tell me that I don’t have to be in until half-past 9 because then I’ll not arrive until 10. Tell me I should be in for 9. Please make sure I know who to text or email if I’m really going to be late or absent.

Exceptions are fine as long as they aren’t happening all the time. Good = staggering in at 2pm on a thursday afternoon reeking of booze, wearing a tutu and looking very sheepish. Bad = turning up wasted every morning and doing nothing all day every day. If it’s a case of bad then there is probably something else up.

On one occasion external factors made me realise I was becoming unreliable. I asked to be released from the contract before I became a liability and walked away relatively cleanly.

A certain client once prevented me from reaching a polling station because of some bullshit looming deadline and intractable, untraceable bug that was mostly down to deep architectural flaws. Another (more recently) had me work a weekend when I was already coming down with flu - I pushed through, collapsed and I spent the next week in bed - and less got done.