Communication is key

I did an interview with Alex Hall, a web developer. The interview is featured in the October issue of Singularity. Here’s a question I asked: What is the one skill that has been invaluable to you as a web developer?

Communication. You get nowhere without communication. That goes for all aspects of web development. You first need to get a grasp of the next project you are going to be doing, and you need to make sure you understand it as fully as possible before even starting. That is communicating with the client, which can also prove to be the hardest part of a project. I heard a story the other day where a client wanted their web site ‘re-vamped’ and all they gave the designer was a 1997 template they liked and 1 line of text! You can’t do anything with that!

Read the rest of his answer, and the other interview questions in the October issue. Download it for free. Alex writes at DeVSeO and you can also follow him on Twitter @devseo.

I’ve also recently signed up for Scribd. Hopefully, that increases the reach of the magazine, which gives me more leverage, which means you get better articles to read. Ad infinitum.
Singularity October 2010

And I actually had a different magazine cover originally. Here’s what it looks like:

Singularity October 2010 alternate cover

Satellite and maritime data calls

Let’s talk maritime communication data. That’s what my users work hip-deep in.

“Wait! Didn’t you say you’re in the satellite business the last time?”

Oh yeah… so, to me (and my users), they’re effectively the same thing. You see, out at sea (ooh, alliteration), captains and sailors still need to talk with their loved ones back on terra firma. And surf the Internet (for you know, uh stuff…). And send (short message service) SMSs to their friends (and sweet phone messages to lovers). And report back to headquarters of course.

[actually they probably don’t frivolously send love notes. Because their company is paying for it, and paying close attention to their usage. See below…]

They do that by using a device, which sends data up to space to one of the supporting satellites (not our moon, one of those man-made ones), which then sends it back to Earth to be received by a satellite dish, which then relays that data out the normal way. Here’s a simple diagram to show how it works:

Basic land-sea data transfer via satellite

I totally suck at drawing diagrams…

The ships are equipped with a terminal (no it’s not installed at the fore of the ship like in the diagram. It’s probably in the command centre or communication centre or… you know, I have no idea where they install it…), which contains one (possibly more) subscriber identity module card or SIM card. These SIM cards aren’t the kind we use in our mobile phones though.

And each SIM card has one, possibly more, mobile numbers. And each mobile number is tied to a specific service, such as voice call, or SMS, or fax. These mobile numbers are used to track usage. What do I mean by that?

For the purposes of our discussion, the word “call” refers to any initiated communication. So an SMS is a call. Browsing to a particular website is a call. Faxing a piece of paper is a call.

And each call comes with associated data, and the entire thing is referred to as a call detail record, or CDR (or call record in short). There’s a lot of data in one call, so I’m going to tell you about the ones my users and customers care most about (because they track usage religiously. I know, because I wrote the web application for it.) You may encounter other similar terms.

  • Calling number – the mobile number making the call
  • Called number – the name’s a bit misleading. It can actually be an IP address or URL, other than a receiver’s mobile number or fax number. It’s also known as destination number.
  • Unit type – “messages” for SMS, bits/bytes/KB/MB (and other variants) for IP data, sec/min for voice data
  • Call duration – a value corresponding to the related unit type, such as 2.13 MB or 27 seconds
  • Call start date/time – when the call was made

The calling number is the unique identifier. The main thing it identifies is the company to whom the billed is sent (very important, this billing thing). The calling (mobile) number is tied to a billing account in the billing system.

The call duration is especially important, because the customer is billed accordingly. This is why I’m adamant about the use of fixed point database types such as numeric(12,4). The floating point errors will scale out of hand otherwise (millions of these call records are created every month). Which will cause the total billed amount to the customers to be out of hand. Money is a very serious topic… Do not underestimate the power of 2 numbers not tallying by a difference of 2 cents in the billing report…

That’s the basics of satellite data. Oh right, the terminals…

There’s this service called Broadband Global Area Network, or BGAN for short (pronounced bee-gan), and I even presented at a product launch hosted by my employer. The BGAN service is provided by Inmarsat, a satellite telecommunications company, and they provide me with most of the data I work with. And they (and their data servers) are based in London. Which is why I obsess over timezones and formatting dates and times.

So (customer) companies buy these BGAN terminals and install them on their ships. And the captains and crew members get to communicate with people on land, and even with other ships. All made possible by routing data through the satellites.

And my users sell these terminals, associated paraphernalia (such as the SIM cards), and data usage (where price plans come in). Inmarsat deals with telecommunications companies (like my employer), and the telecommunications companies take care of the customers.

There are other types of terminals of course. Which means different services, and different types of data. Which gives my team many headaches. Because my users will be telling the customers “We support this!”, and turn to my team to actually support the new data, new price plans, new billing calculations, new entries in bills, new everything. There are now more than 10 sources of call records which we handle every day…

I believe that’s enough information for now. Any questions?

Why you need linguistic skills – part 3

Language in dictionary by Christian Grass @ iStockphoto

This is the last part of the series. You might want to read up on part 1 and part 2, because they were about programming related ideas. In this article, we’ll look at the non-programming areas where you need good linguistic skills.

Below, above and around you

When I was young, my idea of a programmer was the typical hacker type of look, either ingenious, obscenely obese, pizza-eating-grubby-fingers-typing, or skinny, pallid and anti-social (or any combination of them). Programmers were depicted as reclusive because of their obsession with computers, sometimes to the exclusion of communicating with other people.

In this current world, programmers need to talk to many types of people. Programmers talk to new staff, testers, managers, customers, sales people, marketing people and their peers. They talk to people of all levels, below them, above them and around them.

If you only know how to talk in code, the only people reasonably expected to understand you are your peers.

Chicken and Duck speak

There’s a Chinese saying “Ji Tong Ya Jiang”, which translates to “chicken talking with duck”. Both are of the fowl family, yet neither can understand each other. It’s used in situations where person A is talking to person B using words that person B understands, yet person B cannot understand the whole sentence when all the words are put together. Comprende?

For example, I know a friend who’s a programmer and work at the same floor as me. One day, I passed by his desk, and saw an SQL reference book in Chinese on the table. I picked it up and leafed through it. Individually, I could read the Chinese words. It’s when they’re strung together that I don’t know what they mean. It was terrible. Only when I looked at the SQL code did some of the sentences begin to make sense.

Ever had someone ask you why something failed due to “select access to such-n-such-table not granted”? Do you tell her the problem’s fixed and access granted? Or do you go into detail about how the database table was recreated and select access was not granted, causing the error? She might know what a database table is, but frankly she doesn’t really care.

Ever had someone ask you why an application is so slow? Do you tell her it’s a database problem and let it go at that? Or do you launch into an explanation on why a particular database table had a missing index, even going so far as to name the database table, and that you recreated the index, and that should speed up the retrieval SQL query, which in turn speeds up the application?

Use the appropriate words for the appropriate types of people you talk to. A manager can understand a slow server response answer. A technically knowledgeable tester can understand a slow database server response answer. A programmer can understand a slow database server response caused by an inefficient algorithm in an SQL stored procedure answer.

The only way you’re going to use the appropriate words is if you already know the appropriate words. Of all the people involved in a software project, you as a programmer are the most intelligent of the lot (I’m biased of course *smile*). Since you’re the most intelligent, it’s up to you to have a wider range of vocabulary so you can talk to anyone, and even translate for others.

Which brings us to writing documents understandable by everyone…

Put it in writing please

It doesn’t matter what you call them. They’re specification documents, including general business information, business logic, technical information and anything concerning the software project.

When you write a technical specification document for programmers, you translate business logic into near-pseudo code. You detail the database tables involved, perhaps a modification of existing table columns, perhaps a new database table. You might include a mockup screen shot, with some details on what that button should do, and what this datagrid should display. You note down validation checks based on what is reasonably expected from the business logic.

When you write user guides for users, you write in a different manner. Lots of pictures involved. Text in snappy sentences, preferably free of technical jargon. Validation checks explained in “between 1 and 10 inclusive” instead of “1 <= i && i <= 10".

Do you write for the right people?

In closing

The importance of your linguistic skills must be emphasised. Today's world creates situations where you need to talk to non-programmers, and non-programmers talking to you. A phone call from a user. A face-to-face conversation with a tester. An email to a customer.

I find it difficult to understand how someone who can tell the difference between int and short, cannot tell the difference between "lose" and "loose". You're an intelligent person. You should be above simple spelling and grammatical errors.

Non-programmers don't communicate with you through your code. They communicate with you through your language. Be a better programmer. Have better linguistic skills.