Tag: Technical Debt

While working at REDACTED, I reported the following issue.

There are so many places where automation can make you save time and mistakes. One, the first I found at REDACTED, was related to how the application architecture was set up.

The application I worked on used a couple of separate modules, also made by us: Core and UI Components.

• Core collected in one place all the app’s services. (in Angular terms, i.e. classes/methods to access all the endpoints of the Back end)
• UI Components collected in one place all the app’s UI elements, like easier to use tables and inputs.

While it made sense to separate UI elements (because they changed slowly, there was a special team dedicated to maintaining them, they could be used by other apps, …), it was a mistake to separate the Back end library. (because it changed very frequently, the same programmer making a page had to change it too, they could only be used by the same app, …)

On a daily basis, after adding a new endpoint or changing a previous one in your custom branch, you had to

1. compile the Core module
2. remove the currently used Core module from the app
3. add the just built Core module to the app
4. compile and run the server of the app

Did I mention you had to do those steps manually? But there was a twist, too. If you wanted to add a new module from the Internet, the standard command $ npm install --save <module> had been hooked into by our team leader to automatically build and install again both the Core and the UI Components modules. Neat, right?

Unfortunately though, his cool thing did build and install the development branch of the Core module, not your custom branch!! In the end, each time the collection of third party modules changed (a change introduced by you or others) you had to run the $ npm install command again to install all the modules of the collection but you also had to remember the twist and manually run the steps above again afterwards. In fact, the command replaced your perfectly good, previously compiled, custom branch of the Core module with its unrequested, freshly compiled, development branch, and you had to undo that.

Why did he program that that way? I guess because that suited his own needs as a team leader. In fact, probably to test if additional internet modules would work fine in the app, he had to be sure to install them into the most up-to-date version of the app, so he needed to install the development branches of the Core and UI Components modules.

There was absolutely no need to keep the steps above manual so, two weeks after being hired and many times after forgetting one of the steps or the twist and wasting time to understand why suddenly the app didn’t work anymore, I wrote a very simple script to run all the right steps for me.

It worked very nicely but it wasn’t cool enough according to the team leader standards. It faced his frontal opposition immediately, and I was forced not to share my improvement with my colleagues.

While working at reported, I reported the following issue.

Javascript is a privileged language because its programmers can immediately see in a browser how a Javascript program works. Thus the interaction with the browser must be as fast as possible for a Front end engineer to be productive.

Instead, in the 15 people Front end team I was assigned to, this interaction was very slow and cumbersome.

• When I joinded the team, each reload of the page they were working on forced them to close the browser’s currently loaded tab, open a new empty tab, go to the login page of the app, identify with their credentials, navigate through many intermediate pages, and eventually load again the page they were working on.
• Some hours after I voiced my surprise that we had to program that way, the team leader came up with an automatic solution, where the running environment would detect a file change and reload that page only. Notice that he decided to make the reload automatic because he knew how to, not because it was needed (zero effort at doing it manually by pressing the F5 key).
• However this cool thing never worked very well, because his implementation of HMR (Hot Module Reload) always left the navigation links broken, making it impossible to load a different page after the current one had been reloaded. Thus, in the end, a reload from login is still used a lot.
  • How much money the company wastes is left as an exercise. Consider 1 minute per reload from login, performed 100 times a day by a team of 15 programmers.

Why is the Front end team forced to program like that? Essentially because of the inferiority complex of many designers of that configuration. Instead of building what their team needed, they built what they needed to show how good they were at making cool things. (like optimizing the JavaScript transpiled from TypeScript before showing the application in the browser, which is only useful in production, not in development)

While working at REDACTED, I reported the following issue.

Provide a working environment where each programmer can share their doubts and their improvements. Seniors’ attitude alone would go a long way here, but I saw they were very territorial.

Provide more programming freedom and use code reviews for correcting problems caused by that freedom, not for forcing programmers to use predefined (and questionable) templates.

At the same time, provide as much standardization as possible at information level and style level. For example,

• Use the full English infinitive, all capitals, for enum-erated actions, like CREATE, DESTROY, … (information)
• Use a switch instruction for enum-erated branches. (style)

Use code reviews as an opportunity of continuous education, to teach colleagues about company stantards, styles, and how to detect certain patterns and apply best practices. For example, often juniors don’t know how specific a name should be with respect to its context / contents.

• A list variable with items elements is not a bad choice for a generic function that applies to any list of items, but it’s questionable when it expects to be filled with some order lines, with a quantity and a price.
• The code review should suggest to change those names to something like orderLines and orderLine respectively, highlighting the fact that the concept of list / item is then conveyed by that of plural / singular.

Instead I saw code reviewers force the code author to add useless comments to their code, like this:

/**
 * Initialization
 * @return void
 */
ngOnInit(): void {

which is doubly useless because

1. No programmers will ever have any doubts that a method with an Init in its name will be called during initialization.
2. Angular programmers won’t ever have any doubts about how a fundamental piece of Angular, like ngOnInit, is used.