One feature I value in an editor is allowing different languages to have different settings. Like the way the Javascript community has settled on using two spaces for indenting, whereas Python uses four. This feature is built-in to Sublime Text. The lack of the feature is one reason I gave up on the Atom editor.

While less convoluted than the read and write behaviour in a cluster, the behaviour of indexing in a clustered CouchDB or Cloudant environment merits a discussion. Understanding how indexing and querying works in a cluster will help avoid confusing situations where queries to a view index on Cloudant will produce different results because the indexes contain different data.

tl;dr: Writing indexing functions (map/reduce in views, index for search indexes and so on) which can return different values for the same input document will cause the indexes on shard replicas to differ, meaning they could return different values for the same query even when data doesn’t change. It’s the developer’s responsibility to write their indexing functions such that they always emit the same values for indexing for the same JSON input.

I should have made the point in my Technical Debt post that making compromises in order to hit business needs is emphatically something that needs to happen. And not just occasionally, but with regularity.

Indeed, I’d be surprised to work on any non-trivial project without making compromises. This very website is full of compromises to meet the business needs of (a) my becoming quickly bored with writing frontend code and (b) of knowing that tweaking code no-one will ever see is less fraught with worry – and therefore easier – than actually writing this stuff that you are reading. The need is for writing, the site is small: many shortcuts can be taken. If I ever have a million hits, the site will most assuredly collapse.

But I still don’t like the phrase. So what would I replace technical debt with, as a concept? I’d instead invite stakeholders to consider a restaurant that is just starting out.

I wrote a small Sublime Text plugin, QuickNewFile. It tries to mimic the Atom editor’s method of creating new files: show an input box for the filename, create the file. This flips Sublime’s method of creating a blank buffer and later saving it. I found Atom’s worked better for me, and it was about the only thing I missed from Atom when I switched back to Sublime.

The basic features:

• Can be used to open existing or create new files.
• Initial directory used is the directory of current active file, falling back to project root then home directory.
• Tab-based auto-complete for directory. Hit tab multiple times to cycle results.
• Will create missing directory in the folder tree as needed.

It’s not on Package Control, but it’s simple to clone the repo to your Packages folder (see the readme).

There is no “technical debt”, there are only badly-implemented features.

Perhaps the situation isn’t that bad. Even so, each time I see the phrase technical debt used in a discussion, I fear something bad is about to happen – or be justified. Somehow, a fairly dicey decision is about to be turned into a solid, objective decision by means of applying terminology.

Compare and contrast:

1. “The team will need to implement this in an unscalable and badly tested fashion in order to meet that deadline.”
2. “The team will need to take on some technical debt to meet that deadline.”

The first correctly identifies that risks are being taken on that may cause problems later. The second papers over this with some jargon which implies an objective evaluation has taken place over a well-understood problem space. Likely, nothing of the sort has happened.