As of today, I have a brand new blog. The old posts are still here, but the look and feel, and everything under the hood, is different. Everything is still free for me, except the domain name.

This post lists the technologies involved in editing and publishing my blog.

My first attempt at blogging started in 2001, with a web-site entirely hand-made in HTML. It was crude, it had no commenting, and it was very difficult to maintain it, so it was necessarily tiny. Back then, finding a web host that was both free and would allow you to use your own domain name for free was quite difficult, so I had no option but to go with various questionable free hosting places. First it was united.net.kg. (Where kg is the top-level-domain of Kyrgyzstan.) Predictably, it one day just disappeared. Then, it was digitalrice.com. It had the same fate. Starting from 2007 and lasting until yesterday, I had been hosting my blog on blogger.com (formerly blogspot.com) which, luckily, has been stable.

Introduction

The term "technical debt" refers to messy source code, data, or architecture in a software system. It is commonly understood to represent a vague acknowledgement that the mess should probably be fixed by someone, somehow, sometime.

People hearing the term "technical debt" for the first time are likely to guess what it means, in broad terms, and to understand that it is undesirable; however, the real detriment lies in a concept which, although alluded to by the term, is not spelled out, and therefore hidden. As a result, people often fail to grasp the grave implications of technical debt.

This post sheds light at the hidden concept and shows the real problem with technical debt.

Abstract

Two distinctly different widely used meanings of the term code refactoring are identified and named:

• Changing how code works, without changing the requirements that it fulfills (refactoring in the weak sense)
• Changing how code is expressed, without changing how it works (refactoring in the strong sense)

Summary

Building upon the realization that conventional means of software design today amount to nothing more than fancy whiteboards, we examine the pitfalls, disadvantages, and consequences of designing software using such tools.

This post is support material for Towards Authoritative Software Design.

Abstract

In this paper we examine the current state of affairs in Computer-Aided Software Engineering (CASE) tools specifically aimed at software design. We look at individual tools as well as entire categories of tools with respect to applicability and effectiveness, and we notice their abject inadequacy.

This post is support material for Towards Authoritative Software Design.