InRhythm

Your partners in accelerated digital transformation

Software Engineering

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

Unleashing The Potential Of Your Offsite Team

Thriving vs Surviving

Are You Unleashing Your Team’s Potential? Or, are you an engineering Practice Lead or Manager who’s unconsciously capping your team’s potential? While there may be the odd diabolical leader who intents on deliberately holding his or her team back, I like to think that doing so is not the norm. Leaders of agile craftsmen want their teams to flourish and fly through each sprint. Doing so will require creating an environment and work culture that fosters improvement and unleashes a team’s potential.

With a new year and decade here upon us, the idea of making resolutions to catalyze changes isn’t new. It’s a centuries-old tradition that has begun to fall out of favor. Given that < 8%  of us make it through the year, performance and motivation coaches suggest that we set goals for the year instead of resolutions. By setting a goal, we know which direction we’re headed for and it allows us to “slip back” or go off-course occasionally yet still track towards the goal unlike resolutions, which do not offer the same latitude. 

Here at InRhythm, we’re looking forward to achieving continued success in 2020. With increased efforts to build and empower our 10x teams and to better enable our clients, we have set several key goals for the year ahead.

2020 Goals

  1. Continue to put our customers first and make every effort towards 100% customer satisfaction
  2. Foster a culture that truly embodies the Agile Manifesto
  3. Grow our footprint in new markets and industries 

As the Practice Lead , I’m conscious of how well my team is performing and how the toll of being onsite at clients’ workspaces affects them. I’m also aware that I need to give the team space to work together on a sprint and to figure things out on their own. When they hit an obstacle or begin struggling with forward progress, that’s the time to jump in. Until then, leaders must encourage their teams to experiment and err, support them, and back them when the choices they’ve made may not be the ones anticipated by their employer but they’re exactly the right ones needed for the client.

In addition to giving your team some latitude and space so that they can creatively solve problems without you helicoptering over them, you also need to think about giving them recognition. Of course, nobody wants to celebrate repeated failure, but, if a software developer made an informed decision to try to do something in a new way and everyone could extract lessons learned from that effort, then s/he/they should be celebrated for making a bold move and trying to do something different. It should go without saying that the successes also need to be celebrated. Recognition motivates teams to try harder.

Efforts in the opposite direction will have – no surprise – the opposite effect. For example, a lack of recognition for doing well or finger-pointing when there is an error will demotivate teams and start to put restraints on their ability (and desire) to flourish. Powering up 10x teams requires motivation and support so that members can dig deep and unlock their potential. Motivation should be a weekly or monthly focus and not reserved for the one day each year when companies formally recognize their employees, clients or management team. 

Here at InRhythm, we’re encouraging more dialogue between members and practice leaders and added the role of a liaison designed to facilitate open and honest discussion. We’re creating a culture where it’s safe to respectfully voice an opinion and to try new things that could make a difference for our clients. It’s also about accountability. If a team member come forward and voices a concern or a need that does not get addressed with an effort towards closed-loop communication, that member’s potential becomes thwarted. 

Have you made 2020 all about your team’s potential? Are you subconsciously thwarting it or actively boosting it? Be the practice leader that helps teams thrive – not just survive.

The Importance of Placing Individuals Above Processes and Tools

Empathy should be regarded as a super-power. Not enough people have it and the workplace – indeed, the entire world – would be a better place if more people did have it. When you have project deadlines or you’re in the midst of an intense all-hands scrum, it’s easy to forget about the people factor. That is, there are people working with you and for you who are missing celebrations, concerts or the opportunity to just chill out at home because their effort is critical to your product development effort.

But you’re on a tight timeline. You have key deliverables. Your client has worked backwards from the launch and expects that you will deliver a bug-free software solution by the date circled on the calendar. As the Practice Lead, you may be luckier than most in your role if you have a dedicated team cranked up on caffeine and working late into the evening – every evening, in fact. This is great for deadlines but it can have far-reaching negative consequences if this pace is expected to  be sustained.

The Agile Value #1 requires that we value individuals and interactions over processes and tools. Yet you’re conflicted. Project deadlines and deliverables are what they are and you’ve explained them to your team. Missing a due date and delaying a launch is not going to happen on your watch. Processes for coding, testing, documenting must happen as prescribed, regardless of the yeoman’s effort required to get it done. Your team understands this, right? Surely you told each team member that they were doing great work when you met last year for their performance review?

Maybe they do. Or maybe they don’t. Agile product development places enormous demands on the people doing the work. Both the team members and their practice leads have to grapple with the relentless pressure and the temptation to skip part of the process to move things along faster. 

When you’re building high velocity teams, you need to make daily investments in your people, processes and infrastructure. Take any and every opportunity to express empathy, understanding and gratitude for the work that your team, and each individual on your team, is doing. Expressing appreciation once per year during a performance review will likely end up becoming a one-and-done experience because that employee likely won’t be around this time next year.

There are simple ways to bolster your team’s productivity and motivate them to stay on track with respect to processes. The easiest way is to say, “Thank you.” If you want a high velocity team who is loyal, dedicated to the needs of your customers and proud of the work they do, then say what you mean and mean what you say. Be sincere. 

To help ensure that your agile engineers remain “your” agile engineers, go one step further and acknowledge the efforts of individuals in front of others. People are human and their efforts, sacrifices and basic needs must be openly acknowledged. As software engineers in a hot market, we have the flexibility to go wherever we like towards the goal of being part of a community that values our membership. Agile leaders must reinforce appreciation of these “extra efforts” through grace, gratitude and occasionally, through special dispensation. Catering dinner (that’s not pizza) for the team every once in a while is a good expression of gratitude. This is how to build trust and long-term relationships, as well as high velocity, agile teams. 

Staying strong on execution and adhering to process is critical for success. Acknowledging the personal efforts that it took to enable that success must be acknowledged. Remember, as per agile Value #1 –  if you put people first, ahead of processes and tools, you will have created a space that fosters a high performing team’s success.

Iterate Your Way to Success

“A learning experience is one of those things that says, ‘You know that thing you just did? Don’t do that.’” — Douglas Adams, The Salmon of Doubt

Here’s a thinking tool: when you’re having difficulty finding a solution, guess. Then you have something to work with.

In other words, when you don’t know what to do next, oversimplify and self-monitor. Iterative development strategies like The Agile Method are just versions of this idea. It’s also fundamental to many machine learning (or AI) strategies.

Daniel Dennett once gave a nice breakdown of how evolution works:

How To Create a Chicken:

1. Take a dinosaur
2. Let it replicate
3. Select for flightworthiness
4. Repeat steps 1-2-3
5. Repeat step 4
6. …until you get a chicken

The thing about evolution is that nobody really knows what will be selected for, or how future conditions will impact individual survival, or just how all of that will produce chickens or ocelots or the particular way an owl turns its head. There is no intelligence to it — it’s a thoughtless process. The lesson is to keep moving, to keep iterating. Progress is always better than stagnation.

The great news is that you are an intelligent designer. You can observe and change reality at will; you need not wait on randomness to discover working designs—but don’t be afraid to guess. The mistake is in assuming that you’re designing the perfect final state of a solution (complex) instead of the first working state (simple).

Try to promote continuous improvement through ongoing positive change, keeping on an open mind about unconventional solutions. Foster a culture of accountability, have a clear purpose, and keep checking if you’re any closer to your goal. Trust that useful properties will emerge out of creative interactions, in unpredictable ways. Be open to surprises:

1. Intelligently analyze complex systems to find weaknesses and inefficiencies.
2. Create a range of solutions and intelligently determine both the right solution and the right success criteria.
3. Model and test the solution in collaboration with all stakeholders to validate the solution
4. Analyze the results, measure against success criteria, and restart the process on failure.
5. Standardize success into repeatable guidelines and share that knowledge with all stakeholders
6. Repeat 1-5, continuously.
7. …until you get a chicken (Okay, maybe not a chicken. But you get the point.)

At InRhythm, we work tirelessly to ensure that our engineers are prepared to succeed in any engineering culture. Our training program, InRhythm University (IRU), is designed to ensure that every graduating engineer has mastered the technologies and techniques that we know work at the highest levels of the industry through continuous repetition of the above process. As we continue to train and teach new engineers through IRU, we will also continue to pass along what we learn. Keep learning and keep growing.

 

WebAssembly Will Change the Way You Code

WebAssembly (WASM) is a new type of code that runs in browsers. Previously, developers of browser-based web applications had only one choice of programming language and/or environment: JavaScript. This was good and much gold did the people earn; nevertheless, some weren’t happy that they had only one choice. WASM is here to change that. WASM, according to Mozilla, “is not primarily intended to be written by hand, rather it is designed to be an effective compilation target for low-level source languages like C, C++, Rust, etc.” This is the key point. You can now write “web scripts” using the language of your choice. That’s huge.

Is WASM trying to kill JavaScript? No, says the inventor of JavaScript, Brendan Eich. The goal of WASM is to enable a more linguistically-diverse development ecosystem delivering extremely fast (native or near-native speed) code through efficient compilation and parallelization (the ability for web software to take advantage of multiple processors). More huge.

This last point is maybe the most important. InRhythm engineer Will Bratches pointed out in a recent lightning talk that increases in speed are no longer achieved at the chip level—Moore’s Law is no more. What we do now is spread work across cores, leveraging parallelization and managing concurrency. Client-side JavaScript is not designed for that world. New languages like Go and Rust are. WASM unifies the two. 

Here comes the “hello world!” moment. Head over to WebAssembly Explorer—it’s sort of a CodePen for WASM. On the left panel, paste this code:

int plusOne(int num) {
return num + 1;
}

Next, click “compile”. You’ll see something like this:

WASM WebAssembly Screenshot

Yes, that’s assembly code on the right (I know!). A more human, readable version is in the center column, the WAT view, which you can read more about here.  Just scan through it—you’ll see our function name plusOne represented as $_27plusOnei. You’ll also see that we’re establishing 32-bit integer parameters, setting their scope to “local” and so forth.  You can, for example, see how the assembly code  (add)s one to the (ex)tended (a)ccumulator register for 32-bit numbers:

add eax, 1

…is represented in the WAT:

(i32.const 1)

You can now hit the “download” button, which will deliver a .wasm file.  That’s really it—you have the WASM binary to use. There’s a tiny bit of work you have to do to compile the WASM so it works in your browser. The easiest thing to do is clone this simple example and load the index.html in your browser. Check the console. Now read through the code.

There’s a lot more to this subject, so start exploring. You’ll be creating first-person shooters in your browser in no time!