GT!Blog

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 »

The easiest way to understand the current state of encodings is to look at the history of how we got to where we are today. The pre-ASCII days are not particularly relevant, but they are interesting, so I have run through the various encodings that preceded ASCII from a technical perspective here if you are interested. The story of Unicode really starts with ASCII. Note that since Windows and UNIX are the only two types of operating systems of interest to most modern programmers, I’m only going to discuss them. (Linux, iOS, Android, etc. are all UNIX-based). First I’m going to go through all the problems of the various pre-Unicode ASCII based encodings, and then I’ll provide some programming pointers for cross-platform programming. You can skip the pre-Unicode stuff if you’re not interested in the history

Read the rest of this entry »

While various flag and signal based encoding systems have existed since pre-history (signal fires, smoke signals), true digital encodings were not needed until attempts to communicate via electrical signals in the form of the electromagnetic telegraph. The early telegraph systems in the 1830s and 1840s were extremely limited in terms of electric components, with basically only batteries and electromagnets available. In another running theme throughout technology, there was also a desire to make the systems usable without the operators having to learn complex codes, and this placed further constraints on the systems. With these components, three basic systems were invented.

Read the rest of this entry »