8

Communication without Mistranslation

This final chapter before the conclusion will deal with anti-patterns centered around the way you communicate architecture to different audiences. The first part describes an anti-pattern related to information control. Then we look at a few anti-patterns that relate to the clarity of your communication. Third, we look at an anti-pattern specifically concerning the way you create architectural artifacts. As we’ve been doing all along, we will end the chapter by summarizing our key takeaways.

In this chapter, we’re going to cover the following main topics:

• How overcommunication can in some cases be worse than undercommunication, especially when communicating with a generalist audience
• How keeping things ambiguous in order to avoid making a decision can result in serious damage to your project
• How people’s seeming inability to understand what you are saying is often a symptom of underlying issues you need to address
• Why straying from standards when documenting technical specifications is almost always a bad idea

After completing this chapter, you will have a better understanding of how technical communication can go wrong. More importantly, you will have picked up a number of concrete approaches you can apply to help you avoid common technical communication pitfalls.

Communicating too much

This section will explore what happens when you communicate too much in a technical context. To do this, we will start by exploring an anti-pattern taken straight out of cognitive psychology: cognitive overload.

Cognitive overload

Cognitive overload happens when the amount of information presented becomes overwhelming to the recipient to the extent that it impairs action.

Example

LilacCo, the world’s leading producer of scented candles, is having major issues with its integration landscape. It has a relatively recently purchased MuleSoft platform, but it has seen little use, and most integrations still run through legacy middleware or point-to-point.

Martin is a technical architect who has been given the task to come up with a solution to the various issues LilacCo is experiencing. The issues include high latency and slow performance on many integrations, poor logging and monitoring, long and error-prone development cycles, and the inability to create new integrations for several key legacy systems.

Martin has thought long and hard about the issue and has come to the conclusion that moving more systematically to MuleSoft, implementing more event-driven and asynchronous integrations, writing some key adaptor APIs in front of older legacy systems, and providing a clear pattern for error handling and logging to be used by all teams will solve the problem.

It is not an easy fix. Martin has created a slide deck and accompanying report numbering hundreds of pages. The material contains many technical diagrams, and although he has tried to create appropriate summaries, he feels that there is only so far this material can be simplified without losing the essence of what is being said.

Martin pitches his new model to the executive board. Unfortunately, the questions asked reveal that no one has really understood the message he has tried to convey. They get hung up on relatively insignificant details and fail to grasp the overall plan.

He is given feedback that his proposed model is too complex and that he needs to find a simpler approach. Martin is exasperated. He already felt like the plan he had come up with was the simplest possible. The elements all rely on each other, and removing any would compromise the approach.

Martin tries to schedule one-to-one conversations with the people he knows best on the executive board in order to rerun his key points by them. Even in this more intimate context, Martin finds it difficult to bring his points across. The key points simply seem to get lost in translation.

Then, Martin is told that a new integration platform vendor has had a pitch in front of the executive board and that everyone is very excited about the new approach they are bringing. Martin is asked to give feedback, which he does in the form of a detailed and nuanced rebuttal of the vendor pitch. He concludes that while the new platform indeed has some exciting features, it does not solve the fundamental problems LilacCo is facing.

Martin’s feedback, however, accomplishes very little. The vendor proposes to do a free proof of concept (POC) to create more comfort in their software’s capabilities, which the executive board accepts. Martin is not asked to be part of the POC team.

6 weeks later, the POC concludes with roaring success. The team has been able to demonstrate all the capabilities required during this period. Of course, it’s all on a pilot basis and much complexity remains, but the executive board is confident based on the presentation it receives from the team that the new software will deliver what it needs.

Martin asks whether he can look into the details of the POC and what has actually been demonstrated, but his request is silently ignored. Instead, the vendor sends a formal proposal, which is accepted, and a new project to implement the new integration platform is underway.

Problem

Cognitive overload is a general term from psychology for situations where our brains are overloaded with information or options to the point where we are unable to take the required actions that we would normally be able to in the presence of less information. In technical communication, creating cognitive overload by including too much information when presenting architectural options is a very common anti-pattern.

This especially happens when we convey information to non-technical audiences. For technical audiences, we can to a large extent rely on an understanding of diagram formats, standard ways of doing things, good practice, architecture patterns, and similar.

That reduces the cognitive complexity for such an audience, although complex architectures can still be hard to follow even for experienced practitioners. However, when you are trying to convey this information to a general audience, you cannot rely on these supports, and therefore the task of conveying key trade-offs and many moving parts can be extremely difficult.

Proposed solution

Cognitive overload isn’t a solution per se. What leads to cognitive overload is the belief that you, somehow, need to include a certain amount of detail in your presentation in order to be fair to your audience or complete in relation to your subject.

My personal belief is that a large number of talented architects fall into this anti-pattern because of a sense of intellectual honesty. They have considered many options and are aware of many arguments and counterarguments for and against the solution they are proposing.

Therefore, they feel dishonest in simply doubling down on a highly simplified version of the option they have chosen to recommend. In scenarios where business stakeholders are the ultimate decision-makers, which is often the case even for seemingly architectural decisions, that almost inevitably leads to cognitive overload.

Results

The obvious result is a failure of communication. Your main recommendation and supporting points are lost in a quagmire of information that your audience is unable to process.

That means you lose your audience and their attention and, ultimately, your ability to influence them to make the decision you want them to make. Cognitive overload leads to inaction, so the most likely result is that nothing will come out of what you are proposing because it has not been assimilated.

That also leaves the field open for other players to sell a different message, as we saw in our example. It is an unfortunate fact in our industry that it is often the most well-placed messaging that leads to technology adoption rather than the optimal choice from a technical point of view.

Better solutions

Effective communication is not something that can be taught in a few sentences. But your takeaway should be that it is important to simplify a complex message sufficiently for it to be understandable for your audience.

In general, stick to the following:

• Structure the message for the audience and their level of understanding
• Don’t assume the audience know even the basics of what you are proposing unless you know for a fact that they do
• Focus on a single main message; don’t include lots of subsidiary messages alongside the main one
• Don’t include all additional considerations and options you have considered along the way.
• Use images, graphics, tables, and so on to help get information across
• Have backup material ready if anyone wants to dive deeper into an area, but don’t include it upfront

Overall, you should be cautious about making demands on your audience. They have a lot on their plate and limited time to engage with what you have to say. Make sure that time counts.

Being unclear in several ways

In this section, we explore two anti-patterns that in different ways explore intentional and unintentional lack of clarity in technical communication. We start by exploring an anti-pattern that seeks to deploy a lack of clarity for a tactical purpose but ends up causing adverse effects.

Ambiguous solution

Ambiguous solution proposes to hide away a conflicted or uncertain decision behind ambiguous language and representations to postpone the need to make it.

Example

GrillCo, a major online retailer focused on outdoor cooking equipment, is facing major issues in its order management process. There are frequent unanticipated stock-outs, wrong delivery calculations both for duration and costs, and taxes are not consistently applied correctly.

This is not entirely an IT problem, and in fact, many areas of process improvement have been identified. However, as part of the wider order management transformation, GrillCo management has also decided that it needs a new software platform for the order management process.

There are, however, several opinions as to which software to get and how to go about implementing it. Some support putting it in the Salesforce CRM, using the out-of-the-box order management module. Others would prefer dealing with a dedicated vendor with a more retail-focused attitude. Finally, IT would prefer implementing the functionality themselves, using the microservices architecture they have been building up.

Rainer has the technical project management responsibility for the order management implementation. He tries to facilitate the discussion between the different proposals, but the problem is that nobody seems to know who should be making the decision.

In the meantime, there are many other smaller technical tasks to get on with, so Rainer focuses on these, leaving the new order management system as a generic capability on diagrams, presentations, and documentation. He figures that a solution will be arrived at eventually, so there is no need to rock the boat.

However, as the transformation proceeds on other fronts, the question becomes more urgent in the minds of the senior stakeholders. As he has been unable to gain consensus by talking to people, he proposes to do a formal vendor selection with well-defined criteria and let that be the decision-making process.

However, as he starts to prepare the groundwork for the selection process, he makes a startling discovery. Two teams have separately gone ahead with completely different pilot implementations of the order management software based on their own interpretation of requirements:

• The first is within the IT department, where a few developers have started prototyping new software to show how flexible and powerful their microservices platform is. While it has some good functionality, it does not in Rainer’s assessment begin to meet the real needs of the business.
• The second pilot is even further along, already working with mock ordering scenarios based on data taken from the existing e-commerce solution. It is based on a piece of standard software from a small retail-focused software vendor that is investing heavily in making the necessary adaptations to meet GrillCo’s needs. However, Rainer again assesses that there is much to be done before this solution might be fit for purpose.

A dramatic meeting ensues with the CIO and the IT team on one side and the COO and the supply chain team on the other, both championing one of the solutions. The meeting ends as a stalemate, and a decision is made to bring in an independent consultant to assess the two solutions and make a recommendation.

GrillCo brings in a high-profile and well-respected expert in order management solutions who spends a few weeks looking at the pilot software. His assessment is damning.

Neither pilot really has a good way of delivering the level of capability GrillCo needs. He recommends proceeding with neither solution and instead going back to the market to find a better fit. Rainer polishes his presentation on the technology vendor selection process and gets to work.

Problem

Some decisions are hard to make. This can be because of politics—that is to say, not wanting to annoy powerful stakeholders or groups with a decision they won’t like. It can also be due to missing information that will only appear at a later stage in the process and therefore complicates making a decision now.

The art of avoiding a controversial decision by postponing it is the core of the problem addressed by the ambiguous solution anti-pattern. While it can be reasonable to take some time to collect more specific information that will significantly increase decision quality, taking this too far becomes an anti-pattern, no matter if it is done due to politics or a general fear of getting the decision wrong.

Proposed solution

The ambiguous solution anti-pattern proposes to handle difficult decisions by hiding them behind ambiguity. This can easily be done through things such as capability models, by deferring to a separate decision process, or by simply listing multiple alternatives—for instance, in diagrams and documentation.

This can be a highly attractive option in a number of cases; for instance, you may know that certain very senior stakeholders favor a certain approach that you have determined to be unviable. By hiding behind ambiguity, you may hope to postpone making this clear until the project is too far along to change things.

You may also, secretly, be hoping that as the project progresses and more information becomes available, the decision will become easier; either it will be too late to activate some options or the answer will become obvious.

That is to say, you are hoping not to have to handle a situation that has a high degree of uncertainty or conflict attached to it by postponing it indefinitely. This is very human behavior, but, unfortunately, is a bad architectural practice.

Results

Ultimately, of course, you will need to deal with the issue you have been hiding away. If you are lucky, the decision will now be easy as most avenues will be foreclosed. This is not a good thing, however.

It will rarely be the case that the option that can be implemented most swiftly is also the optimal solution. Therefore, your procrastination in dealing with the issue will nearly always result in a worse solution than if you had made the decision sooner.

There is something to be said for keeping options open when the decision isn’t necessary, but if you do it for too long, it will adversely affect your solution. And keeping options open for too long when it comes to key architectural decisions is generally problematic.

If you aren’t lucky, the decision still won’t be obvious; you still must deal with uncertainty and conflict, but now it will be compounded by the additional time pressure you have added by waiting. This is altogether a worse outcome both for you personally and for the project.

Better solutions

First, don’t postpone a decision beyond its last sell-by date. If you don’t have the necessary information, make a plan with a clear deadline for getting it together. Then, plan a decision-making process that will take place at that time whatever else happens.

If the decision is politically unpalatable, try to get your supporters within the organization to stand by you as you make and communicate it. There’s always a risk of the wrong decision being made for political reasons.

However, even the wrong decision is better than no decision after a point. At least you will be making progress and you will be able to start mitigating the consequences of a wrong decision sooner.

When decisions are needed, flag them clearly in documentation and presentations so that stakeholders are aware the decision is coming. Don’t hide behind vagueness, even when it’s easy to do so.

If you can’t decide by consensus, see if you can get stakeholders to agree on a formal decision-making process instead. Often, people find it easier to live with the outcome of a formal process than with something that appears as just some guy’s opinion.

Groundhog day

The groundhog day anti-pattern happens when people endlessly ask the same questions, even after multiple repeated explanations.

Example

Rolf is leading a local Salesforce implementation for MediCo, a medical device manufacturer with a presence in most European markets. The Salesforce implementation has been defined by the HQ staff in Paris and is meant to be rolled out as is to the various subsidiaries in other countries.

Rolf has been given the responsibility to roll out the system to the German subsidiary. The German operation is new to MediCo, having only been acquired the previous year. It, therefore, is not tightly integrated into MediCo’s standard processes or IT infrastructure. The Salesforce implementation is seen as a way to improve upon this state of affairs.

When he delivers the initial presentation on the Salesforce implementation as it exists in France and other countries to the German team, he is met with a barrage of questions. The team wants to drill into very specific process questions that Rolf has no way of answering, as he doesn’t know the details of the German operation.

He takes away a ton of questions, which he tries his best to answer in written format. However, he quickly starts feeling like he is playing a game of whack-a-mole. Every time he seemingly answers a question, another similar but subtly different question pops up from another member of staff.

Rolf starts consolidating all the questions and prepares clear and concise answers to all of them. Given the high degree of confusion, he has not been able to make any real progress with the implementation, so he decides to give it one more go.

He gathers the German team together one more time to give the team members the highlights of the new Salesforce system and as systematically as possible to address all the concerns that have been raised so far. To no avail, he is once again met with more uncomprehending glances and questions that he thought he had already answered more than once.

Frustrated and almost ready to give up, Rolf decides to call one of his old mentors in the company, who he knows is aware of the situation in the German subsidiary. She tells Rolf that the problem is probably not with his communication skills at all.

The staff in the German subsidiary prefer to do things their own way and resent the imposition from HQ. Salesforce is just a pretense for voicing that opposition. The system could be the most perfect thing since sliced bread, but the German team would still oppose it out of principle.

With his new knowledge, Rolf decides on a new plan. He takes the bold decision to put things out in the open. He holds another presentation, where he makes it clear that he is aware of the real reason for the opposition, and rather than trying to address all the concerns, he invites the team into the process to see how it might find a way of making the new system its own.

While the system is what it is and HQ is not about to approve a lot of local changes, how the German operation decides to adopt it and integrate it into its own processes is up for grabs. Rolf opens up the implementation to the German team and welcomes its suggestions for how it might best use the new CRM. Slowly, some people start to engage, and while the timeline has to be moved a couple of times, eventually adoption is successful.

Problem

Sometimes, people just don’t seem to understand what you’re saying. No matter how hard you try to explain a point or how many times you explain it, there doesn’t seem to be any getting your point across.

The groundhog day anti-pattern, named after the movie of the same name, describes this situation where you can’t seemingly communicate something enough times for it to make any difference.

That means you feel like you are banging your head against a wall without making the slightest mark. Often, this is because you aren’t really engaging with the underlying issues that are in play.

Proposed solution

When you engage in the groundhog day anti-pattern, you respond to the situation of having seemingly never-ending queries about the same issues by repeating yourself a lot. You may repeat yourself in different languages or in different modalities, but you are reiterating the same message.

Sometimes, it can make life feel like an endless repetition and like you are making no progress at all. You question both your own sanity and the sanity of the people doing the continuous questioning.

That’s generally because you are not really engaging the underlying reason for why the questions are asked. Generally, when you are asked the same thing more than a couple of times by the same people, some kind of resistance is at play.

Maybe, the people feel like a bad decision has been made over their heads and they are trying to pick it apart. Maybe they are anxious that the direction you are proposing will lead to bad personal consequences for them.

There are many reasons people might have to resist your message that have nothing to do with how you present or communicate that message. In this case, the problem becomes more about change management than about communication, and being aware enough to catch this phenomenon is a key soft skill to acquire if you are a practicing architect.

Results

The results of the groundhog day anti-pattern are substantially negative both on a personal level and for your project:

• First of all, you get nowhere with the message you are trying to communicate, which usually needs to be accepted by the audience to which you are communicating
• That leaves you frustrated as you ponder how to better communicate your message to the audience and continuously fail
• It leaves the people you are communicating with frustrated as they don’t feel you are listening to their real concerns
• The project, in the meanwhile, usually stalls, and progress on key areas can be blocked due to the communication impasse

Overall, this anti-pattern can be a serious strain on your project and on you.

Better solutions

The first step is to recognize that the problem exists and is not about you finding a better way of saying the same thing.

In general, remember the following:

• Once you begin hearing the same questions over and over again in slightly different variations, pause and take a step back
• Engage with stakeholders and allies to figure out what are the real reasons behind the resistance that you are facing
• If you find that there are reasons that lie behind the consistent questioning that go beyond just comprehension, work actively to find an alternative approach without compromising your core goals
• Then, apply good change management practices to help drive the needed transformation

You can’t always give people what they want, but you can find a way of acknowledging their real concerns and being open to their feedback.

Drawing diagrams with excess creativity

This section explores what happens when you try to communicate technical information with too much creativity rather than relying on established practice within your community. We do this by looking at the non-standard documentation anti-pattern.

Non-standard documentation

Non-standard documentation refers to an anti-pattern, where teams produce technical documentation in an idiosyncratic format rather than relying on standard practice.

Example

SafeCo, the leading provider of security solutions for facility management, is in the visioning phase of a new Salesforce implementation. It is trying to come up with a strategy for completely transforming its business using technology and has bought into Salesforce as part of the solution.

Qin, a strategy manager with SafeCo, is leading the visioning exercise and is supported by an external consultancy with particular strength in design thinking. They run a series of highly engaging workshops that result in a vision and key requirements for the new strategic technology platform.

The outputs of the workshop are documented in a fairly large number of rich pictures and ad hoc diagrams, many combining elements of process design, data models, and UX prototypes. The senior managers who have been part of the workshop like the outputs so much that they decide to include them in the Request for Proposals (RFP) material that will be sent to potential vendors.

SafeCo shortlists three vendors that all make explicit reference to the workshop outputs in their RFP responses. After final presentations, SafeCo selects one of the largest global Salesforce partners to carry out its implementation in line with requirements as principally stated by the workshop outputs.

However, once the vendor has mobilized and the project enters a formal discovery phase, it becomes clear that there are problems. Many features and requirements that SafeCo thought were obvious from the provided documents have not been included in the vendor’s estimates.

SafeCo pushes hard on the vendor, pointing to the documentation provided with the RFP. However, the vendor disputes the interpretation of the documentation, and it proves impossible to demonstrate clear intent for many of the points under dispute.

For a moment, SafeCo considers going back to market, but the vendor was selected as the only one that had the necessary mix of competencies available on the timeline it needed. Senior management is not willing to compromise on the project deadline and so redoing the procurement doesn’t seem feasible.

Therefore, the only thing to do is to negotiate an agreement for additional features that the vendor had not included. After some amount of wrangling, a compromise is reached that leaves neither party fully satisfied.

The price of the project goes up but not by as much as the vendor wanted. In addition, the vendor insists on more formal documentation of the requirements to be implemented during the project, taking away some of the flexibility that was part of the initial plan. With the compromise in place, the project can finally commence.

Problem

The problem addressed by the non-standard documentation anti-pattern is how to best communicate complex requirements, architectures, designs, and general expectations of technical systems. This touches on the differences between communicating general concepts to a generalist audience versus communicating technical concepts to a technical audience.

Generally, highly visual and engaging material tends to play well when in a workshop setting, such as defining the vision for a new system or how to use an enterprise software platform such as Salesforce for strategic advantage. In this case, you want to use formats that resonate with your audience and build a common understanding.

However, this approach can lead you into trouble when communication needs to be precise and technically correct.

Proposed solution

Non-standard documentation proposes that the best documentation is the one clearest to the key stakeholders involved in producing it, whatever that might be. This is an extremely seductive position because it is true in many cases.

For instance, it is true in the following cases:

• If you are trying to gain alignment about a vision or project
• If you are trying to foster mutual understanding within an organization about a certain topic
• If you are trying to create general awareness of an issue

In all these cases, the perfect documentation is the one that works well for the audience. However, when it comes to technical specifications, architectures, and designs, this ceases to be the case.

Results

Normal language tolerates a lot of ambiguity. The same is true of most visual representations of concepts. However, ambiguity is the mortal enemy of technical specification.

To reduce the amount of ambiguity when writing technical specifications, whether of requirements, architectures, designs, or in general, we use a number of tools. These include the following:

• Language that is stripped of everyday niceties and strives consistently for clarity
• Referring to technical standards that have a well-defined common understanding
• Referring to patterns that are common within our technical community and likely to be readily understood by the recipients of our communication
• Referring to conventions or common ways of doing things that are common within our technical community and likely to be readily understood by the recipients of our communication
• Using standard formats for documentation that have a structure sure to address the common concerns expected by members of our technical community
• Using standard formats for diagrams that are well understood by members of our technical community

All these elements help to reduce the ambiguity of technical specifications, although even with all of these in play, there is still plenty of scope for misunderstanding, as any experienced architect will tell you.

That is why there are standard ways such as user stories or a traditional requirements specification to convey requirements, and standard diagram types such as system landscapes, process diagrams, and data models to convey technical design.

If you stray from these standards, you add to the total ambiguity, and that will cause communication trouble, which can be expensive as your vendors or staff will not understand precisely what is needed. There is enough trouble with communication even with precisely defined requirements and design—don’t add to it.

Better solutions

Given the description in the previous section, it’s probably not difficult to surmise what you should do instead. Let us list them for good measure:

• Write your technical specifications with a view to reducing ambiguity. Strive for clarity above all else.
• Rely as much as possible on standard diagram types, ways of presenting material, naming, and so on whenever you are creating a technical specification that needs to be shared.
• Follow the patterns and conventions common within your technical community. For Salesforce professionals, this generally means following the approach that Salesforce itself uses.

That way, you can communicate clearly with vendors and new technical people that you hire, avoiding the parts of ambiguity that are avoidable.

Remember—in contrast with most communication where you are trying to make a general point, with technical communication you are trying to make an exact one. That is a very hard thing to do, as it turns out.

For Salesforce, specifically, the Salesforce Architects website, https://architect.salesforce.com/diagrams, will help you get a good overview of resources shared by Salesforce itself now available to all architects to avoid re-inventing the wheel when documenting and presenting Salesforce solutions. For readers interested in preparing for the CTA board, this is a great place to keep in mind.

Now, having covered the patterns for this chapter, let us proceed to discuss the key takeaways.

Knowing the takeaways

In this section, we will abstract a bit from the specific patterns and instead try to pull out the wider learning points you can use in your day-to-day work as a Salesforce architect or in preparing for the CTA Review Board.

When architecting Salesforce solutions, you should be mindful of the following:

• Don’t include too much information when presenting your architecture to business stakeholders.
• Instead, focus on your main message and include only essential supporting information.
• Don’t feel bad about not including all the additional considerations you had in coming up with your solution. If anybody wants more detail, they can ask for it afterward.
• Don’t postpone decisions beyond the latest point it makes sense to take them, even if making a decision is hard.
• If a decision is controversial or politically sensitive, deferring to a formal decision process can provide a way forward.
• If you have a situation where it seems like you can’t get your audience to understand you, you should start suspecting that there are some underlying sources of resistance.
• In that case, you will most likely need to focus on the change management aspects of the situation before you can make real progress.
• When it comes time to prepare documentation for a technical audience, whether an external audience or your internal technical teams, you should be rigorous about sticking to accepted practice within your technical community.
• For Salesforce professionals, that generally means adopting the practices disseminated by Salesforce itself.

In preparing for the CTA Review Board, you should be mindful of the following:

• Be short and crisp when presenting your solutions. The judges are experienced architects, so you can rely on a lot of background knowledge.
• Include a clear justification of your recommendations but do not dwell on alternatives.
• Don’t include additional considerations that are not essential to your main point. If anybody wants to test your thinking, they will do so in the Q&A.
• Ambiguity is nobody’s friend. Don’t present solutions that aren’t clear or fail to make important architectural decisions.
• The judges are highly experienced in ferreting out areas where you are missing clarity, so if you aren’t sure what the right decision is, you should make one anyways.
• If the judges ask the same or nearly the same question multiple times, they are probably hinting at an area of weakness in your solution that you may want to reconsider on the fly.
• Use the standard diagrams and presentation formats that have been successful for previous CTA candidates.
• Do things the same way repeatedly in your mock exams to develop facility and speed.

We have now covered the material for this chapter and are ready to proceed. First, however, we will summarize our learning.

Summary

In this chapter, we have seen how communication can seriously affect the outcomes of our projects. You can have the best architecture in the world and it can still fail to make any headway if you fail to communicate it properly or fail to deal with the resistance it engenders in your target audience.

This can be dispiriting to some architects of a more rationalistic bend. Surely, the facts and substance should be the determining factors. Unfortunately, in most organizations, better communication skills will beat stronger technical architecture skills in terms of getting things done.

The good thing is that communication skills, as with all skills, can be learned. There isn’t anything particularly hard about the ways in which you need to communicate to have greater success as an architect—it is just something that takes some practice.

We have now covered all the subject matter of the book and are ready to proceed to the conclusion, where we will summarize the journey we’ve been on together and look at where to go from here.