GT!Blog

Remember the days before everyone had a mobile phone? Although it’s hard to imagine these days, but back before everyone had a mobile phone, public payphones and public phone booths were a massively important part of public infrastructure as a form of primitive mobile telephony for making phone calls. But what about data? Although the first battery-powered laptops came out in the 1983, digital mobile phones did not appear until 1992. In a lot of countries, there was no data equivalent of the public payphone and so you were stuck without connectivity until you could get back to your office or home. In Japan, however, things were different.

Read the rest of this entry »

One of the things that people love talking about these days is technical debt. This is usually treated as a bad thing, as if it would not occur if only we had been more attentive during our design or programming stages, or spent more time getting better specs from our clients. This is then accompanied by a desire to throw everything out and start from scratch. While technical debt certainly can accumulate in these ways, I feel that these discussions often miss the point. A lot of the things that happen that create technical debt are not only foreseeable, they are virtually inevitable in the lifecycle of any code project of just about any scale or complexity. If our current design and programming practices are so fragile that we need to throw everything out and start again after these kinds of inevitable things happen in our code, then perhaps it is time to look at changing how we construct code instead of falling apart once that code has fallen out of some arbitrary definition of elegance. I wanted to write about a few different ideas in regards to this topic, but in this post I want to simply outline the kinds of inevitable changes that I think should be considered as normal parts of the development process and not as technical debt that somehow needs to be eliminated from a project.

Read the rest of this entry »

One of the foundations of computer code is the humble loop. Going back at least as far as the beginning of C in the early 1970s, the two mainstays of loops in procedural languages have been the while and the for loop. Unfortunately, I think it’s fair to say that they also contribute to the kind of complexity in code that can be a source of technical debt. I’m going to look at one of the problems with these loop constructs.

Read the rest of this entry »

One of the topics that people like to talk about is technical debt. However, when you actually get into what creates this technical debt, you find a lot of simple repeating patterns that reduce code readability. So, I decided to run through a pile of them to see if there are any simple fixed. The first one I want to look at is the use of boolean types. Booleans are an extremely useful construct in programming, but they are also a source of hard to catch errors. Here I just want to look at the problems that bools can create, and also propose a set of guidelines for reducing the perceived technical debt they create.

Read the rest of this entry »