InRhythm

Your partners in accelerated digital transformation

Product Development

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.”


The InRhythm Product Design Community

When you come to work at InRhythm, you’re part of a larger community of people—committed to learning and growing—who are as passionate about what they love as you are. InRhythm’s product design community is growing rapidly, and we continue to bring in the most talented and creative individuals who love helping users and building cool stuff. As Director of Product Design, I’ve made it my mission to use my 20+ years of design experience to mentor new employees and chart the course for this division’s success. Over two decades of work, I haven’t had a single day where I hated the career path I’ve chosen, and I want to foster that same energy throughout InRhythm. We’re more than a consulting company that places you on a client site; we’re more than a 9-to-5 job. Learning and growth at InRhythm is a lifestyle.

Fueled for Success

Product designers at InRhythm are some of the most passionate, driven people. We do everything, including UX/UI, design, research copywriting, and even Agile scrums and product ownership. Loving what you do as a designer does more than chart a successful career—it also influences people around you, and we want that same high energy and excitement in our everyday work and the educational pursuits of our personal passions. Not everyone understands the best practices or user psychology central to our practice; this is where you come in as a thought leader. Be the expert onsite, and elevate the quality of work for your teams.

Why is all this important? There’s a lot to be said for knowing your client, understanding their brand, being empathetic to their pain point, and creating embedded experiences that build new opportunities. Some agencies and firms only care about the end experience instead of understanding the process or story of a company; being an advocate for the users and the company is what makes for a premier user experience.

A Community Like No Other

At InRhythm, we don’t just drop you off with a client and go silent for six months—we’re a growing community that stays connected, whether it’s through Slack channels, happy hours, book clubs, and Meetups. We’re all here for the same thing: to grow and learn. Everyone is at your disposal because the best growth happens with the support of your peers, so if you want to learn something new or fill gaps in your existing knowledge, just ask!

Another benefit of working with us is the comfort and freedom to talk about your work and passions. InRhythmers lead and attend “lunch and learn” sessions on client sites, panel discussions, and interactive workshops at InRhythm HQ. You’ll never be alone in your ventures, and our community is here for everything from preparation and coaching to supporting you at your event as enthusiastic audience members.

Work Smarter, not Harder

It’s no secret that Agile and Design Thinking are hot industry buzzwords in our industry. These methodologies are great tools for making work more fun and efficient while inspiring the group collaboration that is at the core of our learning and growth culture. We embody those collective ideals, and design thinking can shape our experiences throughout our lives. When you download a new app, get a new piece of hardware, or even see how text and images are presented in a television show, you’ll find yourself starting that Design Thinking process. How did this feature get included? Why did they do this? Is this design fully effective for their target demographic? Or even something as simple as, “damn, that looks cool!” We research, sketch, iterate, and build experiences ourselves that we know will impact the end user in ways that will make a huge difference without them even realizing what went into it.

When you’re at work representing InRhythm, you’ll always be presented with challenges. Whether it’s interpersonal differences, tight deadlines, or just broken processes, InRhythmers always stay positive, focus on the drive that brought us here, communicate openly, and elevate the game for the people we work with. Regardless of who signs the paychecks, we all have a common goal to build something amazing on our client sites. No company is perfect (if they were, we wouldn’t be there to change things!) but how you show up, identify opportunities for improvement, and forge a path forward is what matters, and what sets InRhythm apart.

Leadership Takes Ownership

In my work at InRhythm, I listen to our clients’ needs, assess what they’re looking for, and our best-in-class recruiting team finds the perfect match to become a new InRhythmer. We want to hear about your process, why you make decisions, and how you ultimately reached those decisions. Anyone can push pixels, but it takes a specific type of person to talk about their work at the level we expect. Whether you’re just starting out or have been designing since the 90s, the type of devotion to your career and the disciplines behind it is what makes or breaks our hiring decision. Our selective process ensures not only your growth as a professional and person but also makes sure our clients thrive through work with some of the most impressive talent. Along the way, I make it my mission to check in with you and make sure your client work is on track to keep you challenged and growing constantly.

We hold biweekly calls that give you the opportunity to chat about everything from client site problems to the latest from your fellow InRhythmers. No one has all the answers, but we can supply you with the tools and stories you need as a group with a common mission. My primary focus is around your learning and growth; when you leave InRhythm, you’ll be better than when you arrived. We shape consummate professionals, teammates, and leaders within our community, and our accountability on all sides is why we’re built to succeed.

This year we plan on adding more UX/UI designers, visual designers, prototypers, UX researchers, scrum masters, dog lovers, thought leaders, cosplayers, crazy people, and—most of all—people who want to stand in front of a room of people and say, “let me tell you why knowing about *your subject* is important!”

Is that you? We’re hiring. Looking forward to meeting you.

 

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!

Overly defensive programming

This post is another one by InRhythm’s own Carl Vitullo. For the full post and additional links, check out the original “Overly Defensive Programming” on his medium channel.

I recently asked a coworker why a certain check was being done, and he answered with a shrug and said, “Just to be safe.” Over my career, I’ve seen a lot of code written just to be safe. I’ve written a lot of that code myself! If I wasn’t sure if I could rely on something, I’d add a safety check to prevent it from throwing an exception.

To give some examples, I mean idioms like providing unnecessary default values.

axios.get(url).then(({ data }) =>
 // If the response doesn't have a document, use an empty object
 this.setState({ document: data.document || {} });
})

Or checking that each key exists in deeply nested data.

render() {
  const { document } = this.state;
  const title = document &&
  document.page &&
  document.page.heading &&
  document.page.heading.title;
  return <h1>{title}</h1>
}

And many other idioms. Idioms like these prevent exceptions from being thrown. Used without care, suppressing an exception is like hanging art over a hole in the wall.

At a glance, there doesn’t appear to be a problem. But you haven’t patched the hole and you haven’t fixed the bug. Instead of an easy-to-trace exception, you have unusable values — bad data — infiltrating your program. What if there’s a bad deployment on the backend and it begins returning an empty response? Your default value gets used, your chain of && checks returns undefined, and the string ‘undefined’ gets put on your page. In React code, it won’t render anything at all.

There’s an adage in computing, “be liberal in what you accept and conservative in what you send.” Some might argue that these are examples of this principle in action, but I say disagree. I think these patterns, when used to excess, show a lack of understanding of what guarantees your libraries and services provide.

Data or arguments from third parties

What your code expects from somebody else’s code is a contract. Often, this contract is only implied, but care should be taken to identify what form the data take and to document it. Without a well understood, clearly documented response format from an API, how can you tell whose code is in error when something breaks? Having a clear definition builds trust.

When you request data from an external HTTP API, you don’t need to inspect the response object to see if it has data. You already know that it exists because of the contract you have with your request library. For a specific example, the axios documentation defines a schema for the format the response comes back with. Further, you should know the shape of the data in the response. Unless the request is stateful or encounters an error, you’ll get the same response every time — this is the contract you have with the backend.

Data passed within the application

The functions you write and the classes you create are also contracts, but it’s up to you as a developer to enforce them. Trust in your data, and your code will be more predictable and your failure cases more obvious. Data errors are simpler to debug if an error is thrown close to the source of the bad data.

Unnecessary safety means that functions will continue to silently pass bad data until it gets to a function that isn’t overly safe. This causes errors to manifest in a strange behavior somewhere in the middle of your application, which can be hard to track with automated tools. Debugging it means tracking the error back to find where the bad data was introduced.

I’ve set up a code sandbox with an example of overly safe and unsafe accesses.

const initialStuff = {
  things: {
    meta: {
      title: "I'm so meta, even this acronym",
      description: "will throw an error if you break the data"
    }
  }
};
// And within each component,
  handleClick = e => {
    if (this.state.stuff) {
      this.setState({ stuff: null });
    } else {
      this.setState({ stuff: initialStuff });
    }
  };

The “safe” component guards against exceptions being thrown.

const { title, description } =
  (stuff && stuff.things && stuff.things.meta) || {};

And the unsafe one gets the values without any checks.

const { title, description } = this.state.stuff.things.meta;

This approximates what could happen if an external API starts returning unusable data. Which of these failure modes would you rather diagnose?

 

Performance and development speed

Beyond that, conditionals aren’t free. Individually, they have little impact on performance, but codebase that makes a widespread habit of doing unnecessary checks will begin to use an observable amount of time. The impact can be significant: React’s production mode removes prop types checks for a significant performance increase. Some benchmarks show production mode in React 15 getting a 2–4x boost over development mode.

Conditional logic adds mental overhead as well, which affects all code that relies on the module. Being overly cautious with external data means that the next person to consume it doesn’t know if it’s trustworthy, either. Without digging into the source to see how trustworthy the data is, the safest choice is to treat it as unsafe. Thus the behavior of this code forces other developers to treat it as an unknown, infecting all new code that’s written.

Fixing the problem

When writing code, take a minute to think through the edge cases:

1.What kinds of errors might happen? What would cause them?

2. Are you handling the errors you can foresee?

3. Could the error occur in production, or should it be caught during development?

4. If you provide a default value, can it be used correctly downstream?

 

Many of the fixes to patterns like this are to handle the errors you can and to throw the errors you can’t. It makes sense to verify that data from an external API comes back in the shape you’re expecting, but if it doesn’t, can your app realistically continue? Lean on your error handling to show an appropriate response to the user, and your error logging to notify you that there’s an issue.

Learning what to expect from your tools is a large part of writing code you can trust. Many times this is documented explicitly, but sometimes it’s only implied. The format of data with a backend API is up to whoever’s writing that backend. If you’re full-stack, great news! You control both ends, and you can trust yourself (right?). If a separate team controls the backend API, then you’ll need to establish what is correct behavior and hold each other to it. A third party API can be harder to trust, but you’ll also have minimal influence over what it returns.

When writing React components, you have an even more powerful tool: PropTypes. Instead of scattering checks like a && a.b && a.b.c && typeof a.b.c === 'function' && a.b.c(), you can add a type definition as a static property.

Thing.propTypes = {
  a: PropTypes.shape({
    b: PropTypes.shape({
      c: PropTypes.func.isRequired
    }).isRequired
  }).isRequired
};

This might look a little ugly, but now the component will log an error during development if your data is wrong. The missing data will likely cause its own error to throw afterward, and which of these messages is more helpful?

Warning: Failed prop type: The prop 'a' is marked as required in 'Thing', but its value is 'undefined'.
// or
Uncaught TypeError: Cannot read property 'b' of undefined

External data that changes

Of course, sometimes you will have data that you’re not sure about. It might have keys a, b, c or x, y, z, or the data key might be null. These are good times to add checks, but consider defining them as functions that communicate their intent.

const hasDataLoaded = data => typeof data !== "undefined";
hasDataLoaded(data) && data.map(/* … */);

Well named functions will tell your coworkers down the road why these checks are present. Particularly good names will enable them to make the checks more accurate in the future.

Excessively safe idioms — and even well-considered checks — amount to stopgaps to guard against type errors. PropTypes are easy to add to an existing React codebase but aren’t the only option available. TypeScript and Flow are much more advanced tools to verify your data types. PropTypes will save you at runtime, but either TypeScript or Flow will allow you to verify that your code works at build time. Types give you an ironclad contract in your code: if you’re not using your data correctly, it won’t even build!

Types aren’t everyone’s jam, but they’ve grown on me for widely shared, highly complex, or difficult-to-change parts of the code. For the rest of the code, in React at least, PropTypes will help you catch errors more quickly and have more confidence in your codebase.

When a developer does something “just to be safe,” it’s a hint that there’s an unrecognized unknown. Ignoring these hints can cause small problems to accumulate into large problems. Know what errors you want when you’re making changes, how to guard against those you don’t, and learn to trust your code.