The dilemma of code readability

When I began the nextSIS project I wanted to start coding straight away, but instead spent a surprising amount of time on design issues I never really had to consider when writing code for more limited internal use.

The decision to take the open source route was based on the idea that we might attract two or three other developers to help us. This never quite materialized in part because after serious initial interest I was too slow in making a serious start on putting the basic foundation of the project in place, because for the last few months I’ve been juggling the pressing needs of developing our local version of namelessSIS against investing in the future by developing nextSIS. But another factor may be our decision to use the CodeIgniter framework – this should make the finished code far better but which also represents an additional learning curve to the kind of PHP developers which I think are prevalent in the education sector.

I think that code written within CodeIgniter ends up being highly readable due to the nature of the MVC framework and the philosophy which underlies it, but this isn’t to say that there aren’t other dilemmas in what is done within the ecosystem. For example, take the use of ternary operators in PHP – do we write out nextSIS code like this:

// value of unselected title on HTML form is '', so convert to NULL if necessary for the table 
 if ($this->input->post("title_id")==='') {
    $form_data['title_id'] = NULL;
 } else {
    $form_data['title_id'] = $this->input->post("title_id");
 }

or like this:

$form_data['title_id'] = $this->input->post("title_id")==='' ? NULL : $this->input->post("title_id");

It’s five lines of code versus one but it arguably comes at the expense of code readability. Personally, I’m happy enough using the ternary operator above but even I would have to admit that the IF-ELSE statements are immediately easier to spot while skim reading the code, and to my mind this becomes an issue when we’re trying to present a friendly face to new developers who browse through our code.

It also has to be said – and it’s something I think is often neglected in open source projects – that we have to try not to be code elitists. If nextSIS ever becomes widely used IT people and casual coders who are not experts in PHP may find themselves in a position where they want to make amendments but find themselves overwhelmed by the volume of code in front of them. I can’t dumb-down nextSIS to the point that we don’t use an MVC framework even though I know most part-time or hobbyist programmers will be frightened off by it, but what I think we have to try to do is make the code as friendly as possible within the constraints of good design. Our example – ternary operators – are not bad design, and you can make a case for them being better than the IF-ELSE structure, but less readability is bad in terms of what we are doing here on this project.

Within reason, code is being documented (while I also understand the coders who have argued that good code documents itself and is therefore unnecessary), and I’ll do what I can to make nextSIS as open as extensible as possible at the code level.

Tagged with: , ,
Posted in nextSIS

Localizing honorific titles

The code hasn’t been uploaded yet for the very good reason that it hasn’t been fully written, but nextSIS is being designed from the ground-up to support multiple languages. Right now, we can switch between English and Korean by altering a value in a configuration file, but the eventual goal is to (probably) put a language-related flag on the top menu bar and allow the application language to be easily and immediately changed within the application (changing the configuration file only changes the interface as pages are reloaded following actions).

But this idea of being able to change languages ‘in application’ raises an issue related to localization which, to be fair given that we are based in Korea, we always knew we were going to have. The issue – or the downright problem if we’re being honest about it – is that while English (for example) has ‘honorific titles‘ such as Mr. and Ms., there are often no direct equivalents in the Korean language. To an extent we can stretch a point on honorifics such as Mr., Dr. and Miss and Mrs. (the latter two being phonetic approximations in Korean of their English counterparts), but we’re lost on Ms. because that’s not really a supported cultural concept.

What this means in practical terms is that while we can load up our people-related records with lots of titles in English, when we switch to Korean we might be staring at blank lines in pull-down menus in some cases – even if the data itself is being retained (the blank line with an ID of 2 is still different to the blank line with an ID of 3). Of course, actually people aren’t generally likely to be switching their interfaces between languages – rather they will choose one or the other, but it may raise a problem where people are using it in a multicultural environment and choosing different versions within the same organization.

On the general subject of culturally customized interfaces, in launching the first version of nextSIS we would ideally deliver an application that was fully ready for global use, but what is more likely is that we will deliver a system which can be configured as much as possible, but which we have to accept we are likely to have to change as new local culturally-related requests are made (assuming we attract any users!)

Tagged with: ,
Posted in nextSIS

Should gender only be two options in a software application?

Sometimes when you are developing software (yes, we’re back) – especially software which you’re trying to localize for a global audience – you can find yourself challenging your assumptions by asking rather existential questions about elements of the software design process you’ve always largely taken for granted because almost everyone else has spent years operating to the same assumptions.

Today’s existential question concerns gender, and specifically it is should there only be two in a software application such as nextSIS? Do we limit to ‘Male’ and ‘Female’ or allow other options to be added? Now in an ideal world of course everything within our application would be designed to be flexible, but on the other hand pull-down menus aren’t always as visually appealing as a checkbox – so if we’re happy to limit gender to ‘Male’ and ‘Female’ then the checkbox may well be the way to go.

But it seems that the checkbox approach would merely be enforcing the tyranny of Western heteronormativity, and if we are to think globally we have to support the ability to specify a third gender, and quite possibly more. And in fact, this isn’t merely an academic question, as some quick research into the subject reveals that from 2011 Australian passports have apparently allowed a third ‘X’ category for transgender people on their passports. Google – if you’ve ever noticed – allows you to specify your gender as ‘Other’, without getting into the specifics of what ‘other’ means.

So it quickly becomes clear we have to support multiple genders, and as a default perhaps provide ‘Male’, ‘Female’ and ‘Other’ while leaving the system open to the possibility that if someone really does want to define themselves as ‘genderqueer‘ or anything else, their nextSIS database administrator can ultimately support it.

Tagged with: ,
Posted in nextSIS