DEV Community: Francesco Strazzullo

Remove Legacy Roadblocks with Architectural Clash

Francesco Strazzullo — Mon, 15 Mar 2021 15:21:59 +0000

The modernization of existing software is becoming increasingly important in the development ecosystem. Quoting Forbes: “Now Every Company Is A Software Company”, but a large part of enterprise software is not ready for the swift changes companies need now.

Flowing is currently helping many companies struggle through their path to software modernization. We are usually called to help development teams when they are stuck with a new set of features that seem unfeasible with the current codebase/framework/architecture. Other times, our purpose is to help refactor a codebase in bad shape that is not letting the team bring enough value to their core business.

We developed a dedicated brainstorming format called Architectural Clashfor both of these use cases.

Architectural Clash

Architectural Clash is a two-day workshop to help clients remove the roadblocks with which our clients are struggling. As an example:

“We would like to build a mobile version of our desktop application, but our desktop clients are directly connected to the database.”

“Our codebase is a big ball of mud, and we are struggling to add a new set of features to it. We want to start working with microservices but don’t know where to start.”

“Our front end is based on AngularJS. We want to stop using it and think that the only solution is to rewrite everything from scratch. Are there other options?”

The main advantage of Architectural Clash is that it is an extremely practical format. We don’t waste a lot of time on analysis and hypothesis, but we start working immediately on the existing codebase. Half of the workshop is hWorkshop with our team mixing with the existing client’s team to tackle problems.

An Architectural Clash is divided into three phases: Sense-Making, Clash and Decide.

Sense-Making

The first phase of an Architectural Clash is called Sense-Making, and its focus is to help everybody (our team and the client) better understand the boundaries of the problem. For this phase, the presence of all the interested stakeholders in the product is required.

The main purpose of this phase is to understand how technical problems are related to business problems. Most of the time, refactoring processes fail because they are not directly connected with business goals.

When a developer team complains about working with old technologies or a very confusing (or untested) codebase, we ask, “What is the real problem?”. We do that with the stakeholders to find hidden connections between code and business. As an example, we try to clarify that having an untested codebase would lead to dangerous bugs that could be disastrous or the connection between a big ball of mud and the team's throughput.

We do that by asking the client about the business's goal and then trying to understand the technical roadblocks to reaching that goal. One of the exercises we use in this phase is the Elevator Pitch.

After the definition of the goal of the product, we start to identify the roadblocks and how to tackle them. However, there is a caveat when proposing a solution. All the proposed solutions to roadblocks should be written as an experiment. As an example:

We believe that by using Cypress, we could add an end-to-end test suite to our product in a short time.

Notice that you add an expectation to the task of adding Cypress. This forces you to analyze your results after the experiment, comparing them to your expectations.

So, the outcome of the first phase of the Workshop is a workshop experiment that will be the main ingredient of the next phase: Clash.

Clash

There is another important difference between an experiment and a task, a timebox. During the Clash phase of the workshop,** tWorkshopse of the team is to run the greatest possible number of experiments**.

The eight hours of the second phase are split into eight one-hour slots. For every slot, some experiments run in parallel, dividing your team into several small teams. Every team can work for 45 minutes. At the end of the 45 minutes, all the small teams gather together to share what they learned running the experiment in the remaining 15 minutes of the slot. To help the team track down and share their results, we use a simple document.

Experiment Outcome Template

After the slot ends, a new cycle begins until the time runs out. After every cycle, the teams could be mixed up, and each team could decide to go deeper with another experiment on the same topic or to start with something new.

As Flowing, we don’t just provide a facilitator for this workshop but a team that can work in the clash phase with the client’s team. This is quite important because developers should be biased towards their codebase when dealing with legacy code. Reasoning and writing code with somebody who doesn’t know anything about that codebase and its history can help see things in a new way, finding new and unexpected solutions.

Decide

The last phase of the Architectural Clash is “Decide”. In this phase, we take all the information about the business goals analyzed in the “Sense-Making” phase, with the outcomes of the Clash phase. Trying to define and prioritize a roadmap that will, in time, remove most of the roadblocks that are causing problems to developers and the business of our clients. In this phase, a possible exercise to use is called “Options Board”. In this exercise, all the actions extracted from the outcomes of the Clash phase and put on a cost/value graph.

Lean Change Management Options Board v1.0

From this and other charts, we categorize and prioritize the actionable, creating a roadmap.

If you think that Architectural Clash could be useful for your company, or if you have any questions, feel free to contact me at francesco.strazzullo@claranet.com.

The Usual Path: a decision-making anti-pattern.

Francesco Strazzullo — Sat, 16 Jan 2021 21:56:36 +0000

In the last few years, I started to love boring technologies. It’s most likely connected to my age, and many projects started with bleeding-edge technologies following the hype. Usually, in the initial brainstorming meetings, I’m the grumpy guy that exclaims: “Do we really need GraphQL, a boring REST API is not enough?”.

Obviously, younger teammates are generally mad at me. They see me as a buzzkill.

Nevertheless, I do the same work with my clients and not just with my colleagues. I frequently help them in choosing technology stacks. While I’m quite good at demystifying Hype when choosing technologies for a greenfield product, I usually feel puzzled when a team has the opposite approach: walking the usual path.

This is the typical conversation I have with teams affected by The Usual Path.

2010
Me: What Framework should we use for this new project?
Client: AngularJS!
Me: It’s a bit new, but ok! Let’s try it

2013
Me: What Framework should we use for this new project?
Client: AngularJS!
Me: It’s quite mainstream now, and you have a lot of experienced developers that are quite skilled with it. I think it’s a good idea.

2017
Me: What Framework should we use for this new project?
Client: AngularJS!
Me: You Know, Angular 2 is out now. Perhaps you should consider it?
Client: It’s not the right project to learn new technologies. Next time, perhaps…

2022
Me: What Framework should we use for this new project?
Client: AngularJS!
Me: I think it’s a really bad idea, the LTS is over.
Client: I know, but we don’t have time! We have a very strict deadline! Let’s go build some directives now!

This conversation never happened, but I can assure you that something similar happened to me quite often in these years as a consultant, trying to help developer teams in making mindful decisions.

Some years ago, I collaborated with a company that built all their core products with Visual FoxPro. They were real experts in Visual FoxPro, and over the years, they became better and better. But they fall victim to the Golden Hammer law:

If all you have is a hammer, everything looks like a nail

When Microsoft announced that Visual FoxPro would not be supported anymore, they started to realize their situation. They panicked and started to think about how to survive. One of the proposals that emerged during that time was to give their customers laptops with Windows XP in a bundle with their software to prevent users from upgrading. I really don’t know how they solved it; I just stopped collaborating with them. But that story still haunts me.

At that time, I felt it was entirely a technical problem; people were too lazy to study new stuff and fell behind. But now I know that this is just the tip of the Iceberg. So, whenever I feel that a team is walking the Usual Path, I ask questions. I want to know the root cause of their reluctance.

It’s a “People” problem

Developers are not “lazy”, but they can become “lazy” if they work in an environment that becomes toxic for innovation. I observed two main factors that usually lead to the Usual Path.

The first one is related to the power structure of a company. I observed that when people are afraid of trying something new, the real thing that people are afraid of is the consequences of failure. If you constantly fear that your team will be blamed for missing a deadline, you will choose to remain in your comfort zone. Because it’s easier to defend yourself if you say:

“We tried our best not to miss the deadline, we used a tech stack that we know very well”

*Unfortunately, when the blaming culture takes root, it is very hard to remove. **It takes a lot of effort and the will of every person involved, from developers to C-level. Sadly, most of the time, it’s *easier to go to work in another company.

The other factor that can lead to the Usual Path is giving little importance (or sometimes demonising) to proper training. I personally listened to some C-level states that their companies cannot afford to train developers**. However, seeing the training as a mere cost is usually catastrophic for a software company.

In Flowing, we deeply understand the need for training that a software company needs to survive in the ever-changing tech world. Our solution is to give a yearly budget to every surfer (we use this name to indicate who works with us) to spend on training (conferences, workshops, books, etc etc.) and give proper slack time to study and test new ideas.

Moreover, every month we organize a Flowing Academy workshop. When a surfer is confident enough about a new technology or methodology, they book a monthly slot and invite other interested surfers to a Zoom meeting. The meeting itself is recorded and shared on our Slack workspace.

And yes, we joke a lot during these sessions.

This totally bottom-up approach has allowed new ideas to emerge and become part of our daily lives.

If your company doesn’t give you enough time for training, you may consider working with us! 😉

As a more general approach, when I notice some decision-making anti-patterns in a developers team. I usually dig deeper: the anti-pattern is always a symptom, never the real disease. Company culture is an essential part of any decision-making process.

If you have a bad company culture, you will probably make bad decisions.

Contact Me

I am gathering my experience in helping software development teams make decisions in complex environments in a book that you can buy on Leanpub and published by Avanscoperta.

If you want to contact me and talk about decision-making, contact me on LinkedIn.

Sacrificial Architecture in Web Development

Francesco Strazzullo — Mon, 17 Aug 2020 11:01:51 +0000

What’s the ultimate goal of Agile methodologies? In my opinion, it could be distilled in the phrase: «Embrace Change». While I understand the value of continuously adapting our code in order to develop the best software for our clients, there’s something that always bothers me as web developer. All the software architectures that I encountered during my career have one feature in common: they are very hard to change. Just try to change this!

Graph by Danwe / CC0

So it seems that no kind of software architecture it’s really suited for Agile development.

Introducing Sacrificial Architecture

Martin Fowler in one of his posts introduced the concept of Sacrificial Architecture: a software architecture designed to build code that you can easily throw away. Because the best code that you can write now, probably will not be suitable for your clients in a few years.

I’m a frontend developer and I find that this kind of architecture is perfect for complex web application today. On the frontend, you need to change the UX and the look and feel of your application ASAP, according to your clients needs.

How to apply it?

Sacrificial Architecture is not a pattern or a well-defined architecture. So how can we apply it to modern web applications? Obviously, there’s no right answer to this question, but I have a couple of tips to share with you.

Modularity

Modularity is a must-have for Sacrificial Architecture. You should divide your application in modules. The modules mustn’t know each other, in this way you could throw away a module and the application will continue to work. If modules need to share code, it needs to be put in a “shared” module.

But what happens if you need to share code between Module A and Module B? The first solution could be to put it in the “shared” module but you will find yourself in this kind of situation in no time…

If you start to put the code in the sharing module every-time you need it, the “shared” module will become a very “fat” module and then you will not be able to throw away any of your code. So in order to maintain your modules “disposable”, you need to accept code duplication. After all, as Sandi Metz says:

duplication is far cheaper than the wrong abstraction.

Frameworks

Modern Web Development is a jungle of frameworks. To apply the SA in the process of choosing the framework to develop your new JavaScript project, try to apply this pattern:

Choose your framework as you will need to change it after six months

It may seem a little extreme, but if try to follow this rule you will use your framework better. Please consider the next AngularJS 1.X example:

app.factory(‘getUsers’,\[‘$http’,function($http){  
 return $http.get(‘api/v1/users’);  
});app.controller(‘home’,\[  
 ‘$scope’,  
 ‘getUsers’,  
 function(  
     $scope,  
     getUsers){  
         getUsers().then(function(response){  
             $scope.users = response.data;  
         });  
}\]);

As you can see we created a getUsers service that we use in the home controller. Note that we are bounded to Angular on the View level (the controller) and on the Business Logic level (the service). Let’s try with something different: let’s define our logic in a pure ECMAScript 6 module.

export default function(){  
   return fetch(‘api/v1/users’).then(function (response) {  
       return response.json();  
   });  
};

And use it in the controller:

import getUsers from ‘./getUsers’;app.controller(‘home’,\[  
   ‘$scope’,  
   function(  
       $scope){  
           getUsers().then(function(users){  
               $scope.users = users;  
           });  
}\]);

The code inside the controller is exactly the same, but now our business logic is not depending on any framework. In other words: it’s simpler for us to throw away AngularJS in favour of another framework. So your work is not done after you have chosen a framework, you also need to choose what features of your framework you have to use to keep the framework itself “sacrificial” all the time.

Conclusions

This post is not meant to cover this topic entirely, and as I stated at the beginning of this post there’s no “right” guide to do a good Sacrificial Architecture: you just need to keep an open mind. And remember, quoting Martin Fowler…

Sacrificial Architecture, sometimes it’s the fastest way to learn things

I talked about this same topic at RuhrJS 2016 in July. You can see the video below

The Definition of Framework

Francesco Strazzullo — Wed, 01 Jul 2020 19:38:39 +0000

What is a Framework? This is one of the questions that emerged in one issue of the Frameworkless Manifesto.
As developers, we all know and use some frameworks in our daily job, but finding a definition of "Framework" is not a trivial task.

What is a Framework?

To try to answer this question, let's start with a definition taken from a dictionary

a supporting structure around which something can be built

This is, surprisingly, a good enough explanation. If you think about some famous development framework like Angular or Spring it perfectly matches with this definition. They give to the developer a structure, usually defined as a series of architectural decisions that the team decided to delegate to the Framework. As an example, if your team decided to use Angular it delegated to the Framework some architectural decisions like language (TypeScript) and that your application will be heavily based on the reactive paradigm.

Libraries

Usually, during the lifespan of a project, we don't use just frameworks, but also other packages that can help us with specific problems like manipulating arrays or dates. In a JavaScript application, your stack may contain lodash or date-fns or other packages like that. Are these frameworks too?

The answer is "no", following the previous definition. These packages are in fact called libraries.

So, what is the difference between Frameworks and Libraries? A quote that I use often to describe them is the following:

A framework calls your code. Your code calls a library.

This is an easy way to classify if a package is a framework or a library. As an example, this is a piece of code of a simple function that use date-fns

import { format } from 'date-fns'

const dates = {
 isMonday: date => format(date, 'i') === 1
}

export default dates

As you can see I just call the library inside my JavaScript object. What I created here is a simple Facade implementation to hide to the rest of my application the existence of date-fns.

What happens if, for whatever reason, I need to change date-fns with another library or to remove date libraries completely? I just need to rewrite my Facade object. So, with very small design efforts, libraries are easy to change during time.

On the other hand, this is a simple Angular service, taken from the tour of heroes.

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root',
})
export class HeroService {

  constructor() { }

}

In this case, trying to remove Angular will result in breaking all of your application. Most of the code written in a framework will lose its value when the framework is removed. Changing a framework in an existing project could be a very long and difficult task. One of the refactoring techniques that you may use is called Strangler Fig Application pattern. In 2018 I gave a talk at a conference about this specific topic for frontend applications.

We can now define a better way to describe the difference between a Framework and a library.

A library should be easy to change, a Framework (most of the times) is not.

The Framework's Way

We have a clear definition of Framework and a simple rule to differentiate them from libraries. Problem solved, right?

After this explanation, it should be easy to answer the question

React is a Framework or a Library?

Alas, is not so simple. The official definition of React, stated in the official website is:

A JavaScript library for building user interfaces

Ok, so it's a library. Following our previous statement about the difference between Frameworks and Libraries, React should be easy to replace. But removing React from a project is not an easy task. The same thing often happens with another (in)famous "library" like jQuery.

Why are some libraries so hard to change? What do React and jQuery have in common?

When a library becomes mainstream, people tend to amplify the library's core concepts to all the part of the applications. The React's mantra "Everything is a component" could lead to writing everything as React Component like Routes, HTTP requests and other parts.

React has a "way" of doing things, and accepting its way means accepting a lot of rules and decisions that you delegated not to the library itself, but to its "Framework's Way".

This is not a bad thing per se, but it's a very important factor to keep in consideration when choosing a technology stack. This leads to my personal and opinionated definition of Framework

When there is a Framework's way, there is a Framework

PS: If you liked this post, you can buy me a virtual coffee ️😊