Testana: A better way of running tests

Abstract:

A software testing tool is presented, which uses dependency analysis to greatly optimize the process of running tests.

Continuous Code Quality Improvement

While working on code in the context of a certain task, a programmer often discovers some preexisting quality issue. When this happens, there is a choice to be made:

• Fix the quality issue on the spot, and commit the fix in the context of the task at hand; or:
• Only make changes that are strictly necessary for the task at hand, and introduce a separate task for fixing the quality issue.

How to organize a Visual Studio Solution

Visual Studio is a capricious product, and its "Solution" subsystem is especially capricious. When you look at what options are available you might think you have a great degree of freedom to structure things the way you want, but as you will inevitably (and painfully) find out later, many things have to be done in precisely one, entirely undocumented way, or else there will be pain of the worst kind: Visual Studio will malfunction either without any error message, or with error messages that are completely unhelpful for locating and fixing the problem.

Here is a list of things I have (painfully) found out over the years.

Incident Impact Calculation Formula

The Mike Nakis formula for calculating the impact of an incident:

I = S × G × T

Where:

• I is the impact of the incident.
• S is the severity of the incident.
• G is the geographic pervasiveness of the incident.
• T is the temporal pervasiveness of the incident.
  

Thus:

Simplification of triple-choice prompts to dual-choice

I have a lot to say about the modern trend in graphical user interface design which aims to achieve an impossibly clean look at the expense of usability, but this is going to be the subject of another blog post. In this post, I want to talk about simplifying the user interface when the simplification is clearly a win, both from a usability point of view and, incidentally, from an aesthetics point of view. Specifically, I want to show how a yes/no/cancel prompt can be reduced to just a yes/cancel prompt.

Audit Testing

Abstract:

An automated software testing technique is presented which spares us from having to stipulate our expectations in test code, and from having to go fixing test code each time our expectations change.

Artificial Code Coverage

Abstract:

In this paper I put forth the proposition that contrary to popular belief, 100% code coverage can be a very advantageous thing to have, and I discuss a technique for achieving it without excessive effort.

The most important quality of software

What is the most important quality of software?

Correctness, they say.

And what is the second most important quality of software?

Readability, they say.

That is right, but only in theory.

Types of dependencies

The term "dependency" is used very often in software engineering, but depending on context, it may mean slightly different things. To avoid confusion, here are the different meanings of the term, and their explanations.

Call Graph Acyclicity

Abstract

In technical design of software systems as conventionally practiced, call graphs often contain cycles. We show that cyclic call graphs are highly problematic for a number of reasons, the most important being that they require careful handling on a case-by-case basis by custom-written code, thus preventing the standardization, and therefore the automation, of system assembly. We discuss refactoring strategies for systematically eliminating call cycles, including a universally applicable technique for trivially eliminating a certain common type of call cycle. We conclude that since call cycles can be avoided or eliminated, they can be comprehensively disallowed, thus paving the way for the standardization and automation of system assembly.

Towards Authoritative Technical Software Design

Abstract

In this paper we examine the long-standing need within the Software Engineering Discipline for technical design documents that are authoritative. A design document is authoritative if there exist technical means of materializing it as a running software system, thus guaranteeing that the end result is indeed precisely as described by the design. We notice the scarcity and inadequacy of existing solutions, we look into the difficulties involved in the creation of such documents, and we conclude with some realizations on what it would take to come up with a solution that works.

Converting MSBuild project files from legacy-style to SDK-style

I recently did this at work, and I decided to document the process here in the form of a how-to guide. Please note that I am not an expert, I am learning as I go along, so there may be mistakes.

Sdk-style project files have existed since net5, but when they were introduced they were made compatible with earlier versions of dotnet, such as dotnet framework 4.7.2. The kind of project files we were using before can now be called legacy-style project files.

• Legacy-style project files begin with <Project ToolsVersion="...
• Sdk-style project files begin with <Project Sdk="Microsoft.NET.Sdk">.

Sdk-style project files are necessary if you want to:

• Start using the `dotnet` command-line utility and all the functionality that it provides.
• Eventually migrate to a modern version of dotnet.

On the "Dotfuscator" tool by PreEmptive Solutions

I am giving this tool a try at work, and I am encountering a great many problems with it. I decided to publicly document my findings.

Migrating a project from DotNet Framework 4.7.2 to DotNet 7

I recently did this at work, and I decided to document the process here in the form of a how-to guide. Please note that I am not an expert, I am learning as I go along, so there may be mistakes.

[SOLVED] Maven deploy fails with status 422 unprocessable entity

It has been more than a year since I created this question on GitHub Community; a couple of days after that I found the solution by myself, so I answered my own question, and to this date comments keep being added by people who were helped by my post.  

When I look at it today, I notice that my answer has this particular style, this grumpy indignation which has become so characteristic of me, after a lifetime of battling with lame software, and even worse, with lame error messages. 

I thought I should share this on my blog for posterity.

Here is the link:

The Trouble with XAML Hot Reload in WPF

The XAML Hot Reload feature of WPF is extremely useful because GUI work often involves tweaking visual aspects of an application, so being able to modify XAML, save it, and immediately see the changes on the screen saves a huge amount of time as opposed to having to terminate the application, modify the code, re-compile, re-run, and go clickety-clickety-click to navigate to the same page and finally see your changes.

Unfortunately, as a WPF project grows, the XAML Hot Reload feature inevitably one day stops working: You modify your XAML, you save the XAML file, and yet nothing changes on the screen. The message "No changes were found" appears in the Hot Reload tab of the Visual Studio Output Window, but it is a damned lie, because you just made changes. This can really be a problem.

When you find yourself in this extremely unpleasant situation, here is a list of things to try:

Program Code is Uncountable

There are some words in English that are uncountable. For example: cheese, furniture, music, evidence, research, knowledge, information, etc. When we speak of those things in plural, we still use the singular form: "I would like to order a four-cheese pizza", "Let me give you some of my furniture", "We need to consider all the evidence", etc.

Hyrum's Law

With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.

Hyrum's Law

(From https://www.hyrumslaw.com/)

A few good reads from Simplethread

I found them at a place called Simplethread while randomly browsing. 

I thought I'd post links here for posterity.

Taming Names in Software Development by Joseph Glass (2022)
https://www.simplethread.com/taming-names-in-software-development

Agile at 20: The Failed Rebellion by Al Tenhundfeld (2021)
https://www.simplethread.com/agile-at-20-the-failed-rebellion

20 Things I’ve Learned in my 20 Years as a Software Engineer by Justin Etheredge (2021)
https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer

Debating with other Software Engineers

Stackoverflow and the whole Stackexchange network is good for asking very narrowly-scoped questions that can receive objective and preferably authoritative answers that cite documentation or definitions. Any kind of question which is subject of opinion, or liable to elicit debate, is off-topic there. This means that stackoverflow is only good for asking strictly technical questions, and there is an upper limit on how valuable this can be. Sure it can be very helpful when you are trying to solve a specific technical problem, but in the grand scheme of things, it is irrelevant; from a philosophical point of view, it is trivial.

I have been looking for ways to discuss with other software engineers (preferably experts) issues that are related to software engineering but are in fact very much subject of opinion. These are the interesting questions. I do of course already have my own opinions, which tend to either deviate or be diametrically opposite from the prevailing industry trends, so it would be very useful to me to debate these issues with others to see what they have to say. Clearly, either I am wrong, or the entire industry is wrong; wouldn't it be nice if we could debate this and have it settled?

To this effect, I decided to give a few forums a try, to see if it is possible to have debates in any of them. As it turns out, there seem to be very few options available, and things are rather quiet in each one of them; most people seem to be doing nothing but consuming content generated by influencers instead of participating in discussions. In this post I am listing my findings so far. I will be amending it as I gather more information.