Programmer

A new idea.

We’ve all had that moment when the light bulb has gone ping above our head. That idea might have been a change to the company website, the next killer app, a critical component that links disparate business systems, or maybe a management report that helps to drive efficiency. The trick of course is translating that idea into a software reality and that, inevitably, involves engaging with someone technical. This might even be, horror of horrors, a software developer.

 

Talking to the specialist.

The first thing to remember about most developers is that they are specialists. Hopefully you are also a specialist: This might be a specialist in your business or a specialist in the problem that you want to solve. Either way you are both specialists and one of the problems when specialists talk is that they have specialist mindsets and specialist vocabularies. A computer science lecturer many years ago once told me that we have a limited, working, vocabulary available in English and yet it is used in highly specialised ways across different knowledge areas. This is one the greatest challenges that we face in the industry. As an example of this, one of the core products that I am responsible for developing has a concept of ‘references’. Now if you’re a scientist a reference might be a journal or article you want to cite. If you are writing academic papers it might also be a book or a magazine. If you’re a developer a reference might be a library of code that you use to perform specific functionality. If you’re applying for a job a reference might be someone who will vouch for your character. While the list could go on, this hopefully demonstrates my point: We need to make sure that the specialists understand each other.

It ain't necessarily so.

A lot of customers, be those people inside or outside of your business, make the same simple mistake. They assume that a short sentence, email or document is enough to describe what they mean. Remember this if nothing else: The written word is rarely unambiguous. Over my years as a software developer I shudder to think of the amount of times that I’ve heard, ‘but that isn’t what I wanted it to do.’ In one particularly knuckle biting moment I heard an internal customer say to a developer I was working with, 'oh, I typed "should" instead of "should not" in my email, but it still shouldn't do that'. Another story for another day. Obviously good developers, or good software houses, will try to help you to overcome these challenges but, again, remember that not all software suppliers are created equal and often even those with the best intentions can get caught out.

Of course there’s a myriad of articles that I could, and indeed may, write about the best ways to help technical and non-technical stakeholders communicate, and indeed how to formally document this. For now though I’m going to start at a more basic level. I’m going to briefly introduce you to the development mind set and try to show you how really understanding the problem that you’re asking them to solve will help you to get what you want.

 

Making the tea.

Being British I’m obviously going to attempt to do this through the medium of tea. Before reading any further I’d like you to spend a few seconds pondering the following question and the tasks involved: ‘Can you make me a cup of tea, please?’ I’ve asked this question many times to people in an effort to help them to understand my world. I’m still lacking in tea, sadly.

The average response I receive, and I’m not second guessing yours here, is something along these lines: Fill the kettle, put a teabag into a mug, pour the water in, wait a bit, take the teabag out, add some milk, stir, drink with a sense of dark foreboding. Unambiguous enough, surely?

Cup of tea

Down the rabbit hole we go.

Now, let’s start to think through this problem with the developer mind set. There’s one basic step that I need to make before I do anything else, but I’m going to ignore that for now, primarily to illustrate why it’s so important.

So my initial thoughts are around how we heat the water: Do we have a boiling water tap, a catering hot water boiler, a kettle, a microwave oven or an open fire? If the option we have uses a billable power source then does the cost matter? Have any bills to the suppliers been paid? Are the power stations running? Did the people turn up to work at the power station and do we need to notify someone if they haven’t? If we decide to try electricity first and find that there is none available, maybe because of a power cut, then can we fall back on gas or fire? Does anyone mind if we pop the electric kettle on a gas ring? Talking of gas rings - do we need to ask for authorization before we use it, are there specific times when it’s available, is there legislation involved? How important is cost? If it’s an overriding factor then would anyone object if I send a junior developer out to gather fire wood and build a fire in the middle of the office, for the cost of a match?

 

Making the technical tea.

Now before we go any further let’s go back to the first step that I intentionally missed out. We need to make some basic assumptions about our problem so that we know the boundaries (or problem domain) that we are working in. I’m going to assume that, given the nature of the article, this is a cup of tea being made in an office. Armed with that assumption I can now get back to the power supply question. I am going to assume that my power source is going to be electricity and that the bill will have been paid. While this makes life a little simpler it still isn’t straight forward. We still don’t know if we are using a kettle, a boiler or a hot water tap, but for the sake of brevity I’m going to take a ‘generalist’ approach and assume a kettle. Great. Is it plugged in? Is the fuse good? If I hit the switch to turn it on is it actually working? Does someone in maintenance need to know if I start to boil the kettle and it doesn’t work? Is anyone else waiting for water for a different purpose and should I add more for them or can I take an isolationist approach? Talking of which, do I need to tour the office and ask if anybody else wants a cup of tea and would this actually be more efficient overall – either from a productivity point of view or from the economy of power from boiling the water? Part of this is going to be cost related, of course; would it actually cost more for me to walk around the office, make several cups of tea and deliver them to their thirsty recipients than to simply get them to make their own? Bearing in mind that an average salary of £25,000 means that three minutes of time costs you about £15 in wages this could be a very real question.

Have you noticed that we still haven’t got to water yet? Or water bills? Or water levels in the kettle? Or the temperature of the water, which will vary by the type of tea? Or, indeed, what type of tea you would like to drink and if you prefer it in a cup or a mug?

 

I haven't even started on iced tea...

…and, you will be glad to know, that I’m not going to. I could go on for the length of the average novel and not even start on the milk.

The lesson to learn here then is that developers absolutely have to understand these sorts of things because we have to make the tea, or to skip back to reality for a moment, tell the computer what to do. Substitute the question, ‘Can you make me a cup of tea, please?’ for ‘Can you get this HR system to import employee name and address data into this scheduling system, please?’ or ‘Can you write me a report, please?’ and you’ll start to see what I’m driving at. Remember that developers live in a world where ‘this’ is different to ‘This’ and that in order to deliver your killer solution we need to know ‘which’ is ‘Which’.

Now all of this is absolutely not a call for your problem specialists to become technical specialists. It is simply to get you to think about how you define your ‘problem’. Don’t try and impose technical solutions on your technical teams; such as, I think you should write in php because one of my mates told me it’s the best, but do try and talk about the problem as much as you can. Discuss how you want things to function and about what the constraints are. Do not assume that your development team can read your mind, do not assume that they will remember to add functionality into your system to email the maintenance team because the fuse has gone in the kettle.

 

We speak programmer.

There’s an old developer saying that goes, ‘give the customer what they need not what they want’ and largely that's what they will try to do. However, it follows that the more good information you can give them about what you want, the better they can give you what you need.

And all of this, of course, is where Little Blue Cats comes in. We can help with this stuff, it’s what we do (and we make good tea).