InRhythm

Your partners in accelerated digital transformation

Product Development

Why you should migrate away from Angular JS

Hello readers! A big fan of the Angular Javascript framework here. Today I wanted to go through a few of the reasons why you should look to migrate your existing AngularJS projects (any Angular release version under 2) to a more modern and actively supported framework (or library).

You might be thinking “well, this guy is internally conflicted”, but give me the opportunity to explain myself. Even though AngularJS is a fantastic piece of technology that surely was top of its class when it came out (October 2010) and despite the fact that I enjoy working with its successor Angular.io (also known as Angular 2+), AngularJS has become outdated (EOL December 2021), and a risk to your company in many different ways.

Dilbert strip - Larry tries to tell PHB what the legacy systems did. PHB says no, he doesn't care about legacy systems. Dilbert asks, "I though we replaced all of our legacy systems." Larry says, "Keep your thoughts to yourself."
@2017, Scott Adams, Inc.

The framework has reached end of support (Version Support Status). This means that it has become read-only mode, it will not be updated further. The framework has not been developed for over a year now (Release 1.8.2 happened in October 2020), and even though extended support was supposed to end mid-2021, it was extended to December 2021 due to the global pandemic. Here’s a blog post by the Angular team regarding discontinued long term support.

To add some support to the point I’m trying to make, I’ll share that Angular was created and mainly maintained by Google. Google recognized the shortcomings of AngularJS, and completely rewrote it to release Angular.io. AngularJS only made it to version 1.8.3, however Angular.io has already made it to major version 13 (current at time of writing), with many more versions to come.

What could be making you hold onto your existing AngularJS apps

Trust me, I’ve been there. You have a perfectly functioning application which needs little maintenance, and you have engineers who know it in and out already. Why invest a part of your budget in fixing something that’s not broken? Why bring in new people that don’t know the product? Why push your engineers to do something new/different to what they’ve been doing?

Dilbert strip - PHB announces to Dilbert that the legacy system maintainer quit. Tells Dilbert to fix it. Dilbert standing in front of odd large mechanical device with a screen, pipes, and pipes with the thought bubble, "Frack."
@2016, Scott Adams, Inc.

The reasons

Technology: As I stated earlier, AngularJS is outdated. This means that in its feature-set, performance, and just keeping up with latest developments in Javascript and the web browsers, AngularJS has clearly lagged behind, mainly due to the fact that it has been in maintenance mode and not actively developed on for years. If you stay on this framework, you won’t take advantage of the rapidly evolving web world, and the evolving smart devices and their new features.

Support: As the framework is no longer maintained, any new issues or limitations you encounter will not only lack an answer/help from the AngularJS team (again, not supported anymore), you most probably also won’t have a huge community online to help you with it, like you would have with any modern framework. This could mean a longer time to fix issues that come up in your application, and a rough experience for your engineers and users.

Security: Perhaps the biggest reason why you should move away from AngularJS. Like any unsupported package out there, you won’t be protected when any new security exploits are identified, be it within the framework itself, or any of its thousands of dependencies and indirect dependencies (yes, your app can be exploited by vulnerabilities in the dependencies of the dependencies of AngularJS which is your app’s dependency… you get the point). Usually when something like this happens in an actively supported package, a fix will be published quite swiftly in response to it, or any dependency that includes the vulnerability will be updated with a newer version.

Talent: Not only do you want to provide the best possible experience for your users, but also for your app engineers. When you are trying to retain or expand your software team, AngularJS will weigh on any engineer’s decision. Engineers will want to work with quality, cutting edge technology. It is hard for engineers to get or even stay excited about working on a framework that has reached end of life. It will be much easier for you to retain and hire engineers if your apps run on modern technologies and following best practices and industry trends. I cannot stress how much easier will it be to fill open positions when your tech stack is attractive for the engineers. You can also think about what will happen once you actually find someone willing to do the job on your legacy system, they will play hard to get and you’ll end up paying more for an engineer that is probably not up to date on industry standards.

Business: For current technologies, the help you will get from the online community is massive, which speeds up the time it takes to fix and implement new features, and to resolve critical situations that may arise. Not only your engineers will be happier and more engaged in what they are doing, it also impacts your branding. Are you a company that invests in and works with the latest and greatest? Or a company that settles with whatever is there?

Dilbert strip - Patty asks Larry how long it will take to add a feature to the legacy system. Larry asks when the new system will replace the old system. Patty responds, six months. Larry then says the new feature will take seven months.
@2017, Scott Adams, Inc.

I know that was a lot of talking, but I can tell you with confidence that we have seen the impact that migrating legacy applications has for many of our customers, and it is massive. Not only do applications come alive and look and feel more modern, but engineers come to work in a better mood and eager to get things done, and a true engineering culture is fostered. Even though keeping legacy systems might seem like the easy or cost-efficient way, there are several hidden (or not obvious) costs that come with it.

If you need any help assessing or migrating your systems, do not hesitate to reach out to us at any of the following:

get@inrhythm.com

InRhythm Website – Contact Us

+1 (800) 683-7813

Written by Juan Porley, Director of Engineering, Web Practice @ InRhythm

How Customized Usability Testing Benefits You and Your User

Software development is all about accurately capturing what the user wants. More accuracy is always better, of course. But what if you could have more accuracy while also saving costs? Why wouldn’t you want that?

Traditional software development was to actually write the software, get your users to test it, have their inevitable change requests come in, change your software, test again, etc. It’s more labor intensive that way (thus more costly), but more importantly it’s less accurate, though that might seem counterintuitive. When you deliver something the user does not want, you did not accurately give them their desired solution. By accurately capturing what the user wants earlier in the process, developers can more accurately engineer the solution later.

For example, let’s say you are mocking up new screens in wireframes on Figma. It’s much easier to change a wireframe than to change code, and for the user it’s basically the same thing. They see the UI changes, get to make their change requests, and you get to implement those change requests in Figma, not in code. 

But usability testing takes this a step further. By using mood boards you can get on the same page as your user early in the dev process.  Using rapid prototyping lets you quickly iterate through various ideas in the early, cheaper stages of the project. And then wireframing, whether you are using Figma, Sketch or XD files, lets your users see how the app will appear. All of this can be done during the early, cheaper stages, and why wouldn’t you take advantage of that with the great tools we now have? Usability testing gives you more accuracy at a lower cost. Can’t beat that!

Creating Robust Test Automation for Microservices

Any and all projects that a software engineer joins will come in one of two forms: greenfield or legacy codebases. In the majority of cases, projects will fall into the realm of the legacy repositories. As a software engineer, it is our responsibility to be able to strategically navigate our way through either type of project by looking objectively at the opportunities to improve the code base, lower the cognitive load for software engineering and make a determination to advise on better design strategies. But, chances are, there is a problem. Before architecture or design refactors can be taken its best to take a pulse on the health of your platform End to End (E2E). The reason being, lurking in a new or existing platform is likely a common ailment of a modern microservices approach – the inability to test the platform E2E across microservices that are, by design, commonly engineered by different teams over time.

I recently worked on a greenfield platform and nearly 6 months into the project, one of the most critical parts of the project had fallen several months behind from a quality assurance perspective. It was no longer possible for QA to catch up, nor was it possible for QA to engineer and execute E2E testing to complete common user journeys throughout the enterprise system. To solve this conundrum, E2E data generation tools needed to be created so that the QA team could keep upbuilding and testing every scenario and edge case. As I see it, there are three main requirements for an E2E account and data generation tool. The tool should:

1) Create test accounts with mock data for each microservice

2) Link those accounts between up and downs stream microservices

3) Provide easy to access APIs that are self-documenting 

Using a tool like Swagger, QA can use the API description for REST API, i.e. OpenAPI Specification (formerly Swagger Specification) to view the available endpoints and operations to create accounts, generate test data, authenticate, authorize and “connect the microservices”.

By creating tools for E2E testing, our QA team was able to eliminate the hassle of trying to figure out which upstream and downstream microservices needed to be called to ensure that the required accounts and data were available and set up properly to ensure a successful test of all scenarios i.e. based upon the variety of different data types, user permissions, user information and also covering the negative test cases. The QA team was able to catch up and write their entire suite of test scenarios generating the matching accounts and data to satisfy those requirements. The net result of having built an E2E test generation tool was automated tests could be produced exponentially quicker and the tests themselves are more resilient to failure. 

Even though the microservices pattern continues to gain traction, developing E2E testing tools that generate accounts and test data across an enterprise platform will likely still remain a pain point. That having been said, the purpose of this article is to raise awareness. Software Engineering Leadership has an opportunity to step up and ensure that the enterprise system that they look after is healthy E2E. I can’t think of a better way to maintain a healthy system than to ensure accounts and data in the lower environments actually work and unblock testing end-to-end. 

James Woods, Web Engineering Practice Lead

Change? What Change? Everything Always Goes to Plan

As software engineers, we are conditioned to brace for change. The very nature of our work requires that we be ready for it. Yet, at our cores, we don’t want there to be any changes. We don’t surrender to the inevitable changes that are going to be required after we submit content for a code review. Instead, we steel ourselves against it, and gear up for battle with a mindset of resistance. We don’t want our QA teams to find any bugs because we’ll then have to make changes to the code we’ve already written. 

The experience, however, is like the Grinch who does everything that he can to stop Christmas from coming. Of course, the holiday arrives anyway. Similarly, despite our best efforts to plan and design an agile effort which builds change in, we’re still not entirely prepared to embrace those changes when they do come. And they will. They always do.

Agile Value #4: responding to change over following a plan” speaks to this behavioral response. It’s all about our attitude. Are we prepared for change and willing to accept that there will be change (as there is for every software engineering project)? Or are we preparing for a fight that we are inevitably going to lose? 

Agile craftsmanship requires that we be nimble in our designs and in our approach. The code we write must stand up to meet the quality demands of the project and not interfere with other parts of the project, but it has to be nimble, too. Anyone at any time in the future may need to rework that code or replace it altogether. If it’s rigid and inflexible, the effort to update it (or replace it) will be that much more intense. Working sprint after sprint is already intense enough – we don’t need to add more stress to our day. In contrast, we need to take measured steps to reduce it.

One of the best ways to manage this stress and to reduce our anxiety is to prepare for change. Embracing a mindset of flexibility prepares us for the change that is coming. If our response is calm and collected, the changes requested will be received just like any new project instead of what may feel like a personal attack on our abilities.

Approaching any project with the expectation that it will likely end differently than it began requires proactively building a roadmap that is designed to be nimble and responsive by anticipating potential changes. Getting ahead of industry trends and predicted needs requires that we are constantly in the mode of collecting feedback from clients, tracking the market and soliciting input from other agile experts. Scenario planning is another way to help with preparedness. This is the only way that we can evolve as a trusted colleague and partner to the clients we collaborate with.

Christopher Okhravi, an authority on agile software development, offers an insightful perspective on the application of Agile Value #4. He reminds us that, “We should never forget that they [the clients] are the ones asking for the system. And they are the ones who will ultimately use it.” Another factor that we need to remember is that rigid planning and process are the antithesis of the freedom derived from an agile approach. As each project unfolds, we learn more about the needs of that project and gain new insights on how to best deliver the code needed to execute the project. However, as we do so, we tend to drift further from the original plan which no longer reflects our reality and this creates tension for everyone involved. 

So, what is the best way forward? Embrace Agile Value #4. We must plan for the worst but hope for the best because change is inevitable. We must be nimble – and stay that way. Change is a necessary element of what we do. We can design our product roadmaps to be responsive and proactive or we can choose to be reactive and struggle to keep up. Getting ahead of industry needs and trends helps us prepare for the changes that will come. Being open to continuous feedback from our clients, our managers, our peers and our colleagues helps us evolve into a trusted co-worker and business partner. 

“Change always comes bearing gifts.”  ~Price Pritchett

Robert Morrell

Practice Lead, Java Cloud

What We’re Reading Around the Web

Agile Manifesto 4/4 – Responding To Change Over Following A Plan by Christopher Okhravi
YouTube
“We should never forget that they [the clients] are the ones asking for the system. And they are the ones who will ultimately use it.”

Manage Stress
Healthfinder
“To be agile, you need to be able to ask, ‘Is this agile?’”

Applying Agile Management Value 4: Responding to Change Over Following a Plan
Dummies
“Unfortunately, traditional project management approaches attempt to wrestle the change monster to the ground and pin it down so it goes out for the count.”

Getting Started With Agile: Responding to Change Over Following a Plan
Pivotal Tracker
“As project execution unfolds, the team learns more about what needs that resulting product will fill as well as how that product can best be built. As this new reality emerges, the team struggles to keep their project aligned to the original plan, which likely no longer reflects the team’s new reality.”


Change Is The Only Constant

A true Agile Craftsman Mindset understand that change is the only Constant

As product developers, we take pride in the “big picture” of the function of the software that we are designing and implementing. Delivering a solution for our clients, and their customers, takes diligence, long hours and impeccable planning. However, even the best-made plans can go awry. How we deal with those plans differentiates the inflexible resistors from the agile craftsmen.

“Agile Value #4: responding to change over following a plan” speaks to this behavioral response. Optimists hope for the best but plan for the worst. Pessimists expect the worst but plan for the best. And flexible realists exhibit behaviors that are the best of both understanding that being nimble and prepared for change is the right mindset. Framing everything that you do with the strong possibility that things will likely change and be different that you planned for cues up your brain to be prepared for change. Hence, you enable yourself to successfully adapt to whatever the new situation is.


Beyond one’s mindset, a critical aspect of practicing Agile Value #4 relates to planning and design. Approaching any project with the expectation that it will likely end differently than it began requires proactively building a roadmap that is designed to be nimble and responsive by anticipating potential changes. Getting ahead of industry trends and predicted needs requires that we are constantly in the mode of collecting feedback from clients, tracking the market and soliciting input from other agile experts. Scenario planning is another way to help with preparedness. This is the only way that we can evolve as a trusted partner. As agile craftsmen, our clients expect us to be inherently nimble, ready for change, willing to adapt and to plan for adjustments so that we can still track to a set schedule and deliver the quality product we are contracted to produce.


Understanding that change is a natural aspect of a project is one thing. Being prepared for it with a thoughtful plan and design that anticipates where and when those changes are most likely to happen is quite another thing altogether. Here, experience can make all the difference. The client relationship is another factor, one that we’ve discussed in a previous newsletter, ”Customers are Much, Much More Than Signed Contracts”. When a client and vendor embark on a path towards partnership, versus a client-vendor relationship, both sides enter the agreement and project understanding that it’s best to expect the unexpected and be prepared to flex. Sometimes, the client may need to be flexible. Other times, the contracted agile partner may need to adjust as the situation changes for the client.
If change is the only constant, and Agile Value #4 requires that we plan for and accept change versus resist it, we need to each ask ourselves if we are agile and flexible. Or, are we rigid and linear?

Thanks and Keep Growing,

Gunjan Doshi

CEO, InRhythm

What We’re Reading Around the Web

Agile Manifesto 4/4 – Responding To Change Over Following A Plan by Christopher Okhravi
YouTube
“We should never forget that they [the clients] are the ones asking for the system. And they are the ones who will ultimately use it.”

Manage Stress
Healthfinder
“To be agile, you need to be able to ask, ‘Is this agile?’”

Applying Agile Management Value 4: Responding to Change Over Following a Plan
Dummies
“Unfortunately, traditional project management approaches attempt to wrestle the change monster to the ground and pin it down so it goes out for the count.”

Getting Started With Agile: Responding to Change Over Following a Plan
Pivotal Tracker
“As project execution unfolds, the team learns more about what needs that resulting product will fill as well as how that product can best be built. As this new reality emerges, the team struggles to keep their project aligned to the original plan, which likely no longer reflects the team’s new reality.”