Nov 27 2019
Agile doesn’t work if your code isn’t

I’ve worked on a few software projects over the years and many of them have been run within an Agile environment.

Agile is a software planning methodology where the work is carried out in small chunks, the requirements are listed in a backlog, which is worked on through these small chunks of development time, called sprints. At the end of a sprint a piece or pieces of work are delivered. This allows software teams to move quickly through the software requirements, be able to deliver software quickly and be able to handle changes in requirements as they go, become agile in the direction they move forward

This is the general theory, unfortunately from what I’ve seen over the years teams that have a Agile project management methodology, but who’s software is still built using a pre-Agile approach struggle to deliver what Agile promises.

The reasons for this are, if your software architecture is still very closely coupled, meaning one layer (the front-end) can not be fully developed in separation from the backend. It is extremely hard for the developers to make quick, fast changes because they run into numerous issues. They may have to wait for the backend team to make a change to an API in order to provide data that the front end needs, if there is no tests in place there isn’t the time for tests to be added or new tests to be written. This can lead to bugs coming into already delivered software and as the team moves forward in their Agile way, the time available to fix bugs and write tests gets less and less, leading to the possibility of the bug list growing and growing.

Implementing an Agile software project management approach is far easier than moving an large enterprise application to being able to be worked on in an Agile way. Arranging two week sprints, setting up a task list board and having a backlog and your ready to go is far easier than getting your software setup to be Agile, but it is possible.

The key to solving these problems is moving the architecture of the project to a more separated approach. Where each layer can be developed on independently, and doesn’t rely on another layer having a new piece of functionality in place before work can start on a new feature.

Dividing the work in a sprint between delivering features and updating the architecture of the application to be more separated allows, over time, the project to become more in line with an Agile approach. The developers can amend the application so the front end can run in separation from the backend. The UI layer can be written in separation from the front-end layer, allowing the UI to be mocked to show users how new features could look so feedback can be given earlier in the process. Leading the feedback being added into the sprints work load before all the other layers have implemented a feature.

Modern web tools can help

Using more modern web frameworks and tools can help. Using something like Angular to build just the front-end Logic, while the UI is built by another developer. This UI can be what is demonstrated to the end user in sprint planning when gathering requirements so the entire team knows what is expected. Using frameworks like NgRx and Nx workspaces allow the Angular developers to move the Angular code add to a consistent pattern that all the Angular developers on the team can follow, leading to a consistent structure allowing any of the Angular developers to work on any part of the application (especially if this is a large enterprise application) without much ramp up time. This can be extremely beneficial for distributed teams or teams with offshore developers.

Tools like NestJS or Node can allow the front-end team write mock endpoints which they can use to build from, while the backend team works on the real production ready APIs.

If the structure of the response is agreed upon, in sprint planning, then the mock APIs (which could return static Json) should be fine to get started building against.

Agile Can Work

Agile can really work as a way of managing the workload of a team, but without an architecture that can support quick code changes bugs will linger and more and more time will need to be spent on fixing issues.

An agile project management approach with a flexible approach to the codes structure will lead to applications that can be delivered quickly.

I like the Agile methodology, but we need to consider the structure of our existing code before going head first to a fully agile approach.

Stephen Adams 0 Comments
Nov 14 2019
IR35 and it’s possible effect

IR35 is looming over all contractors in the uk, it could be in place in April 2020, and there no doubt if it does come into full effect, then it will change how contractors operate.

For those who don’t know about IR35 then it is new legislation where the uk government is trying to stop those contractors who have been working as full time employees but still being paid on a contractor rate.

The idea is that if you have a contract where you are employed to work for a firm in a role where a full time employee could actually do the role, the. You as the contractor needs to prove that your contract is actually outside the IR35 guidelines. If it falls within. The IR35 rules then you will have to pay the same level as tax that a permanent employee pays.

This is a high level overview of IR35 it is worth really looking into the official government websites in order to find out more about IR35.

How IR35 could change how I work

For me if the IR35 rules do become law then it will change how I currently work. I would have to only take on contracts where it is clearly set out what the project is be working on and when it is expected to finish, to show that I am only employed to work on that project. Another way to show that the contract is outside IR35 I’d need to show that I’m not needed to work onsite, instead I’ve been employed to work as a consultant on a single project, and it’s up to me on how and where I work on this project. So if I want I could say that I work only from my home office or a specific work space. I’ll also need to show that I’m using my own equipment to work on this project, though I could see this being an issue for some large organisations where for security reasons they want people working on their projects to use equipment the company provides.

These changes, aren’t to much of a change for how I currently work, I think it makes me work in more of a freelance working model than a contractors who just works as a extra resource for a company who comes into the office day to day and just works on the same project.

How will this be effecting recruitment agencies

If IR35 does come in it could have some serious changes to how recruitment agencies work. They will have to now find developers who can work on a project instead of getting in an extra resource for a company. It will be interesting to see how they will be changing or will they leave the contractor market altogether and just concentrate on sourcing full time employees?

The contracting market is going to be interesting in the coming months, does this mean I’m looking to go permanent? Well, no. I enjoy working for myself and if the IR35 rules are changing to me needed to work more as a project specialist then that suits me.

I enjoy working on Angular and Angular based project, so if you are looking for an Angular specialist to work on your next web application project, feel free to contact me.

Stephen Adams 0 Comments
Nov 11 2019
Using Angular Elements for a micro-frontend
Photo by Ricardo Gomez Angel on Unsplash
Photo by Ricardo Gomez Angel on Unsplash

For my latest client, I was asked to look into how we could structure an Angular application so it could be developed in different sectors.

The application is made up of 12 major sections, each section performs a certain task within a workflow. So while each section is linked, they each have their own set of APIs which they use.

We also wanted to have each section be set up so it could be developed by different developers within a distributed team.

So we have one large parent application that manages the login and main navigation. Then within each section, we have a complete sub-application.

Possible Approaches

There were a couple of approaches we could take, one was to load each sub-application within an iframe, but this means that each sub-application cannot have data past into in via @Input() properties and, well frames are an old approach.

We could have created a monorepo, which are extremely popular now in Angular, but the client has already built some of these sub-sections within their own repos. They didn’t want to start changing their approach to their repo structure. Sometimes as a consultant, while you know there is a great new way of tackling a problem you need to hold back and follow how the client wants to work.

Enter Angular Elements

So with these constraints, we decided that a better approach would be to use Angular Elements. With Elements, we could create each sub-section application as a stand-alone app, but still, be able to ‘package’ it as an Angular Element. Then each of these elements can be loaded in the main parent application as a web component.

Another great benefit of Elements is that when we want to make an update to a sub-section, we can simply generate a new main.js file for that element. Then we just replace the new main.js file for that element in the main parent application. Then when the user reloads the parent application the new updates to the sub-section are available. This was a great benefit as it means that when making updates the parent application can still keep running. As this application is being constantly used being able to keep it available and make new releases was a real problem for the client and being able to solve this problem through using Angular Elements was win for the client.

How I implemented this solution

To start with I created two smaller applications, one for each sub-section. Then using the ngx-build-plus library from Manfred Steyer, I managed to build a single file, the main.js file.

Then I created the parent application, for this app I used NgRx because as the functionality of the parent application grows I want to use NgRx to make the app more Reactive.

In this parent app, I built out the login functionality of the app, when a user has successfully logged in we store some needed details in session storage. This data can be accessed by the Angular Elements when they are loaded.

So the parent app has two main routes, one for each sub-section, then in each route, we have the main component that acts as a homepage for the section. This ‘homepage’ component is where each Angular Element is loaded.

Through using Angular Elements we can take these large scale applications and break them down into smaller micro applications. That are easier to develop across a team.

Next Steps

Moving forward, we’re planning on building out each micro application, so they are full-featured apps that can be loaded as Elements.

If you have a large scale application, that either needs to be upgraded from AngularJS to Angular or needs to have sections of the app rebuilt as part of a refactoring project. Then using Angular Elements as a way to make smaller changes over time instead of one large re-write is a great way to go.

Stephen Adams 0 Comments