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.

So the "master" branch is not kosher anymore

The origins of the debate go so far back that they are lost in the mists of time, but a good starting point (which contains references to prior debate) is an Internet Draft from 2018 titled Terminology, Power, and Inclusive Language in Internet-Drafts and RFCs. Some especially woke communities like the Python community had already started applying some of the recommendations in this draft as early as 2019, but things really picked up steam in 2020, with the murder of George Floyd.

On messages and message-passing

Over the decades, numerous software system architectures have emerged which require invocations across subsystems to be done via message-passing instead of programmatic interface method calls. Such architectures are so common that many programmers have come to regard message-passing as an end in and of itself, oblivious of the fact that it is nothing but a (poor) technical mechanism for accomplishing a certain architectural goal.

Intertwine

Abstract

A mechanism is described for automatically converting method invocations of any programmatic interface into a single-method normal form and converting back to invocations of the original interface, so that general-purpose operations can be performed on the normal form without explicit knowledge of the interface being invoked. Implementations are provided for C# and for Java.

Incremental Integration Testing

A new method for Automated Software Testing is presented as an alternative to Unit Testing. The new method retains the benefit of Unit Testing, which is Defect Localization, but eliminates the need for mocking, thus greatly lessening the effort of writing and maintaining tests.

The Deployable Design Document

Abstract

A need is identified and a solution is proposed for a novel set of software tools to facilitate the visual composition of technical software design documents as schematic diagrams consisting of predefined software components, and the automatic deployment of runnable software systems from such design documents.

White-Box vs. Black-Box Testing

I have something blasphemous to tell you.

Unit Testing is wrong.

There, I said it.

I know I just insulted most people's sacred cow.

Sorry, not sorry.

I will explain, bear with me.

What is wrong with Full Stack Development

Inntel Hotel at Amsterdam, Zaandam

Table of Contents

• What is full-stack development

• Why is full-stack development necessary today

• What is wrong with full-stack development

• Conclusion

What is full-stack development

The predominant web application development model today requires splitting application logic in two parts:

• The front-end, running on the browser.
• The back-end, running on the server.

The front-end is typically written in JavaScript, while the back-end is typically written in Java, Scala, C#, or some other programming language. The two ends invariably communicate with each other via REST. The choice of JavaScript and REST is not due to any technical merit inherent in these technologies, (there is none,) but purely due to historical accident; see michael.gr - The Wild, Wild Web.

A web application developer can either focus on one part of the stack, or work on both parts. Due to reasons that will be explained further down, more often than not, web developers are asked to work on both parts simultaneously. When this happens, it is known as full-stack development.

For the purposes of this paper, we will call full-stack development not just this mode of work, but also this architectural style as a whole: full-stack development is when application logic must be written both on the server and on the client.

Full-Stack Development is a paradox, since it suggests a way of work which is contrary to what common sense dictates. Common sense calls for specialists each working on their own area of specialization, so one would expect to see different developers focusing on different layers of the stack, and nobody ever attempting something as preposterous as working on all layers simultaneously. However, there is a technological hurdle which renders this necessary today.

Why is full-stack development necessary today

The Stateful Microservice

I did a quick search for the term and did not find anything concrete, so I thought I might as well publicly document my thoughts.

Photo of two elephants friendly interacting with each other, from The Scientific American: Fact or Fiction?: Elephants Never Forget

On Stateless Microservices

This post discusses the stateless microservice design pattern; it is meant as support material for other posts of mine that discuss microservices, mainly michael.gr - The Stateful Microservice.

Dory, the yellow-blue fish (a Royal Blue Tang) that suffered from amnesia in the 2003 movie Finding Nemo by Pixar.

Is statelessness a requirement for a microservice?

In another post of mine I discuss what a microservice really is, and I come to the conclusion that despite various attempts out there to define microservices using twenty-item-long lists of characteristics, a good working definition could be as simple as this: 

A microservice is a scalable and resilient module.

(See michael.gr - So, what is a Microservice, anyway?) 

Even if you disagree with the terseness of that definition, and you regard microservices as necessarily more than that, I hope you will at least agree that it is precisely scalability and resilience that the stateless microservice design pattern aims to address, so the definition serves its purpose at least in the context of this series of posts.

There are many who will try to convince you that in order to build a scalable and resilient system, you need statelessness; so much so, that microservices have almost come to be regarded as synonymous with statelessness. This post examines whether this is that in fact so, and what is the cost of doing things this way.

So, what is a Microservice, anyway?

This article attempts to shed some light on what a microservice really is; it is meant as support material for other posts of mine that discuss microservices, mainly michael.gr - The Stateful Microservice.

What is a microservice?

If you go looking for information out there, you will find many different descriptions of what a microservice is; these descriptions exhibit considerable difference of opinion, and to the extent that they agree, it is largely the result of copy-paste. One common theme in these descriptions is that in trying to define this elusive concept, they tend to assign fictitious properties to it. Often, the claims have nothing to do with what a microservice technically is, but rather with impertinent concepts such as the allegedly "independent" software development style around microservices, or some alleged organization of microservices "around business capabilities". Even when the claims do manage to stick within the technical realm, they range from the unwarranted to the preposterous. I have seen statements to the effect that a microservice is supposed to live in its very own source code repository, that a microservice must be independently deployable, that microservices must communicate with each other via REST, etc. (My favorite one is that they must necessarily be stateless; more on that in another post of mine; see  michael.gr - On Stateless Microservices.)

Data modelling

This is a draft paper about a lightweight data modelling framework that I am developing as a home project, for use in other home projects of mine.  It is incomplete; I will be amending it as I find time to write more and as my understanding evolves of what this framework is supposed to do.

Introduction

Every single software project in existence deals in one way or another with data. Some projects have small amounts of data, some have large amounts of data, some even have "big" data. The data almost always exhibit a certain well defined structure, known as the Schema, and the loosely defined term Data Model is used to refer either to the data, or to the schema, or non-specifically to both.

In virtually all cases, the data model is highly application-specific, but many characteristics and operations are common or even ubiquitous across data models.

The MVVM architectural design pattern

Here is a brief technical explanation of MVVM, which contains enough detail (borrowed from its WPF implementation) and examples to allow the reader to grasp how it actually works.

Object Lifetime Awareness

The Thinker (French: Le Penseur) by Auguste Rodin (From Wikipedia)

Abstract

Garbage collectors have given us a false sense of security with respect to what happens to an object once we stop thinking about it. The assumption is that it will be magically taken care of, but this does not always go as hoped, resulting in memory leaks and bugs due to failure to perform necessary cleanup. Tools for troubleshooting such problems are scarce, and not particularly helpful, so finding and fixing such problems is notoriously difficult. 

A methodology is presented, which differs from current widespread practices, for maintaining awareness of, and exercising full deterministic control over, the lifetime of certain objects in a garbage-collected environment. We issue hard errors in the event of misuse, and accurate diagnostic messages in the event of omissions, thus improving the robustness of software and lessening the troubleshooting burden.

Coherence: The Assertable Lock

Abstract

A Software Design Pattern for concurrent systems which makes race conditions something that can be asserted against and thus deterministically eliminated rather than stochastically reduced or minimized. (Subject, of course, to the thoroughness of the assertions.)

Image by reginasphotos from pixabay.com

A description of the problem

Every Software Engineer who has dealt with concurrency knows that it is hard. The bane of concurrency is race conditions: when a thread accesses data without taking into account the fact that the data is shared with other concurrently running threads which may alter that data at any unforeseeable moment in time.

Domain Oriented Programming

A Software Design Pattern which brings the principles of Inheritance, Encapsulation and Polymorphism one level up from the Class level to the Subsystem level, and offers a way of realizing relationships between classes so as to achieve dependency inversion by means of propagation instead of injection.

Part 1: Dependency Inversion

The software that we write often invokes other software to get parts of the job done. These are known as Services or Dependencies. If Class A is making use of some Class B, then Class A depends on Class B, so Class B is a dependency of Class A. 

The principle of Dependency Inversion (⬀) says that a class should not contain any direct calls to specific instances of any of its dependencies. Instead, it should receive these instances as parameters during initialization.

That's all very nice, but passing dependencies around can become quite a complicated business, and in large systems it can become a nightmare.

The case for software testing

What to reply to a non-programmer who thinks that testing is unnecessary or secondary

At some point during his or her career, a programmer might come across the following argument, presented by some colleague, partner, or decision maker:

Since we can always test our software by hand, we do not need to implement Automated Software Testing.

Apparently, I reached that point in my career, so now I need to debate this argument. I decided to be a good internet citizen and publish my thoughts. So, in this post I am going to be deconstructing that argument, and demolishing it from every angle that it can be examined. I will be doing so using language that is easy to process by people from outside of our discipline.

In the particular company where that argument was brought forth, there exist mitigating factors which are specific to the product, the customers, and the type of relationship we have with them, all of which make the argument not as unreasonable as it may sound when taken out of context. Even in light of these factors, the argument still deserves to be blown out of the water, but I will not be bothering the reader with the specific situation of this company, so as to ensure that the discussion is applicable to software development in general.

In its more complete form, the argument may go like this:

On Code Craftsmanship

I will try to make a list of items here, but I could probably write a book on this.