You’re Testing It Wrong…

I really like test driven development. It lets me be lazy. I don’t have to worry about my software quality, or that something I did broke some other thing. And with good dependency injection to make sure every component is working right, “it just works.” Now I code using TDD (writing my tests first, then coding to fulfill them), and I focus our QA efforts on making sure we have great test plans, and great coverage.

Closed System
A closed system wants to be tested.

So, when one of my project teams kept telling me they couldn’t write tests because the database wasn’t ready I got worried. Our team had been immersed in TDD for months — and every single engineer had nodded vigorously when I set expectations. The team leader recited the definition of “dependency injection,” just to drive home how ready they were to embrace it!

But when I asked to see the what was wrong, I knew we had a problem. The team’s tests were not injecting mock objects the right way. The idea behind dependency injection is to replace the smallest component possible in a closed system with another object, a “mock.” That mock can then monitor the system around it, inject different behaviors, and create desired results.

For example, let’s say we have a program that connects to a gizmo — your home thermostat. The thermostat itself is a separate component that lives outside your program. We can expect the thermostat to behave like a thermostat should… reporting the current temperature, and letting the home owner enter a desired room temperature. Pretty straight forward.

So the first step is to write a program that talks to the thermostat. We can wire up a real thermostat, but we’ve got a problem right off the bat. We want to know how our program behaves as the ambient temperature changes — 65 degrees, 32 degrees, or 100 degrees. But a real thermostat is only going to report the actual room temperature, and making the room frigid or boiling just isn’t going to be very comfortable or practical.

Not Mocking
Faking is not mocking.

This is where dependency injection comes in — wouldn’t it be great if we could inject a new gizmo, one that behaves according to our test plan?

It turns out that my team had been taking the wrong approach — but one that is pretty easy to make if you’re new to the idea of mocking and dependency injection. Unfortunately, it meant that they weren’t really testing the application. The were testing something else entirely.

Once we walked through the system, the mistake was clear. During application start up, it created a connection to a database. My team’s approach had been to add a “mocking” variable to the application. In effect, it created a test condition; if the application was in “mocking mode” it would only simulate database calls. If the application was not in “mocking mode” it sent real requests to a real database. Sounds great, right?

But it’s all wrong. Here’s the problem: The application was faking real world behavior. That is, throughout the program there were dozens of little tests, in effect asking, “if we are mocking, then don’t check the database for a user record, instead just return this fake user record.”

This meant that the real program — the actual application logic that would be deployed to the real world — was never tested. Instead, an alternate branch of logic was tested — a fake program, if you will. So two things happened:

  1. We weren’t testing the real program, we were testing something else altogether.
  2. The program itself became terribly complicated because of all the checks to find out “are we mocking?” and the subsequent code to do something else entirely.

And all of that is why my team said they couldn’t really test the system, because the database wasn’t up and running.

So what does real dependency injection look like? It’s simple: You want to change the actual gizmo, but change it in the most subtle way possible — and then you want to put that actual gizmo right back into your program.

Mocking
Real mocking doesn’t affect the original program flow.

Getting back to the thermostat example, an ideal solution would be to modify a real thermostat. You could crack it open, remove the temperature sensor, and add a little dial to it that lets you change the reported temperature. Then you plug the “mock thermostat” into your program, and you change the temperature manually! A potentially better approach would be to change the software that talks to your thermostat, and instrument it so that you can override the actual reported temperature. Your program would still think it’s talking to a real thermostat, and the connecting software could change the actual temperature before handing it off to your program.

In our case, the right solution could be injecting a simple mock component at the just the right point in our program.

For example, lets say our application uses an Authenticator object to log in users. The Authenticator checks the validity of a user in the database, and then returns a properly constructed User object. We can use dependency injection to substitute our own test data by overriding the single function we care about:

object fakeAuthenticator extends Authenticator {
    override def getUser(id: Int): Option[User] = {
        Some(User(id: -1, name: "Fake User"))
    }
}

On line 2, we replace the real Authenticator’s getUser function. The overridden method returns a hard-wired User object (in this case, one that clearly doesn’t represent a valid user account). By overriding the Authenticator in the test package only, the original program is not altered — all that’s left is to inject our altered Authenticator into the program.

The old fashioned way of doing injection is still reliable: Don’t tell, ask. Use a factory object to ask for the Authenticator. Given a factory in the application (let’s call it the AuthenticatorFactory) we can override what the factory actually returns in our test case only:

AuthenticatorFactory.setAuthenticatorInstance(fakeAuthenticator)

A slightly more modern approach is to use a dependency injection framework, but the underlying principle is exactly the same.

Likewise we can take the concept of mock objects further by using frameworks such as Mockito (a framework that works wonderfully with specs2). Mockito makes it easy to instrument real objects with test driven behavior. For example, Mockito will produce a mock object that acts just like a real object, but fulfills expectations (such as testing to make sure that a specific function is called a certain number of times).

Whatever tools and frameworks you use, test driven development has proven itself over the past decade. My own experience is the same: Every TDD project has produced more predictable results, has better velocity, and has been more reliable overall. It’s why I don’t do any coding without following TDD.

Quick! Explain “Microservices”

Recently Martin Fowler (a well-known co-author of the Agile Manifesto) wrote an in-depth and very lucid explanation of Microservices, along with co-author James Lewis. With new technologies, new fads, and new twists on old terminology popping up every month, it can be hard to weed out just another buzzword from something tangible.

Fowler’s definition is, in short, that Microservices are “an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.”

So what does that mean? Isn’t any program, ultimately, a bunch of small services working together? Here’s a quick synopsis for the TL;DR types:

  1. Microservice architectures embody small, independently deployable services (usually business functions). Such functions tend to have a small scope, and can sustain themselves. They don’t need a big, monolithic application framework — they are “small services.”
  2. Such services are independently scalable. In other words, you don’t have to invest a huge amount of resource scaling your entire application — instead, you can focus on making only those “important or difficult” services scalable.
  3. They provide explicit (component) interfaces. This means that each small service provides a clean, usable API. This tends to promote excellent encapsulation and also stability across a suite of services.
  4. This same attribute (explicit interfaces) also promotes segmented development. Since each service is, by definition, independent and each offers a stable API, each can be built and maintained on its own.
  5. Change cycles tend to accelerate, again because each service is independent. Since each service stands on its own, a single service can be changed, tested, and redeployed without a monolithic build/test/fix/deploy cycle.
  6. This architecture also tends to lead to robustness. Since each service is independent, networks of services tend to test for, isolate, and handle failure gracefully. In other words, since there is no single monolithic system, trust is low. Services tend to anticipate and handle failure well.

Microservices tend to be very agile-friendly, too — leading to the question, which was first, the microservice or agile (it was probably agile). The point is, since services can be quickly iterated, we can make small changes more easily. And as Martin Fowler points out, we also benefit from great architectural flexibility:

Splitting the monolith’s components out into services we have a choice when building each of them. You want to use Node.js to standup a simple reports page? Go for it. C++ for a particularly gnarly near-real-time component? Fine. You want to swap in a different flavour of database that better suits the read behaviour of one component? We have the technology to rebuild him.

 

For a more in-depth explanation of Microservices, I’d recommend reading Fowler’s article.

10 Tips For Stress-Free International Travel

Ten Tips For Stress-Free International Travel is now available for free download. This second book in the series is a concise companion for international executives, expats, and frequent travelers. Not only loaded with 10 fantastic tips for making sure your next overseas trip goes smoothly, it also features a bonus chapter on device security courtesy of Dr. Stahl, President of Citadel Information Group. Be sure to travel both safely, and in comfort.

Tip #1: Time “Off”

10_Tips_for_Stress-Free_International_Travel_cover
10 Tips For Stress-Free International Travel (Zacharias Beckman)

Americans work more than just about anyone else in the world. In fact, Americans prioritize work above just about everything else: Family, friends, sometimes even holidays. It’s not unusual to ask employees to accommodate work activities, even if it impinges on a holiday. It’s a stark contrast to many other country cultures. The typical American gets two or three weeks of vacation, compared to six, eight, and sometimes more in other countries. These cultures place family and experiencing life above work in their priorities, and quite often their approach to work reflects this different attitude…

Read the rest of this tip, including which countries and regions it applies to and how to adjust to different business practices by downloading your copy today!

Look For More Tips…

Look for more guides as they go to press! They’ll be posted here, just like this one… Look for:

  • 10 Tips For International Travel
  • 10 Tips For Managing International Teams
  • 10 Tips For Communicating Globally

I’m delighted to offer them to you completely free, and hope you will enjoy reading them as much as I’ve enjoyed creating them.

Download All The Things!

Be sure to visit the downloads page and download all the things…

Inspiring Innovation Across Global Teams

Hi, I’m Zacharias Beckman, president of Hyrax International. There are a lot of misconceptions about innovation, and what we can expect from our global teams when it comes to innovation. Here’s an example.

Jason has a technology company here in the U.S., and they’ve just expanded into Asia. Jason expected that the new team would integrate quickly, and start contributing. By adding another 8 hour shift to the day, he expected his firm to see a dramatic increase in output.

Instead, a few months in, the Asian team seemed to be underperforming. His U.S. managers complained that the new team didn’t produce new ideas. They weren’t even improving on existing ideas. Basically, they were doing what they were told… and if they didn’t have really clear instructions, they kind of did nothing.

What Jason and his management team didn’t realize is that it wasn’t a performance or motivation issue. The problem was with business culture.

Jason’s new Asian employees had been trained for task-based execution. It’s what they knew, all the way from their educational experience, to their most recent employment. The team was not accustomed to critical thinking, and the business culture didn’t support challenging authority. To make matters worse, the Western and Eastern teams weren’t communicating well. With the U.S. team’s low context communication style, they missed a lot of high context cues from their Asian counterparts. The high context communication, to the Western team, was just too subtle — and, it didn’t really come through on a conference, call anyhow.

With all this going on, the new team was set up to fail. They did not expect to be driving innovation. They expected to be told what to execute, and do an excellent job at it.

The unexpected cultural differences demanded a lot of changes in Jason’s strategy. He had to change his immediate goals for both teams, and change what the Asian team was working on. In the longer term, he had to launch a strategy that would get everyone to the same place. That meant a lot of cross cultural training and changes to their very Western, U.S. management style, and taking a much more mature, global approach to the business. Jason learned the hard way how critical it is to understand your partner’s business culture before engaging in business.

Organizing Overseas Teams

Hi, I’m Zacharias Beckman, president of Hyrax International. When it comes to coordinating international projects, one of biggest challenges we hear about is staying on top of the project.

As an international project manager, you have to know how to stay organized, and you need to know what your team is doing. When you have several different teams, all spread around the world, that’s not always easy. You also need to make sure that one of your teams isn’t being held up, waiting on another team.

This is what Tanya ran into, at one of our clients. She had been managing a U.S.-based team. Her company had just bought a smaller firm in India, intending to set up a “follow the sun” strategy. With teams in the U.S. and India, they could move faster because one team would hand off work, at the end of the day, to their overseas counterparts.

But there was a problem. After a few months efficiency was falling, not improving. Tanya found that the teams were poorly coordinated, and more often than not one would end up waiting on the other one. Tanya needed to change her strategy to accommodate a global team. She had to refocus, and figure out how to get these teams collaborating smoothly despite a separation of over 10 hours.

She made two major changes, both of which focused on improving coordination.

She took a critical look at their project management system, and decided that it wasn’t up to the job. It had worked great when everyone was in one office. But now it had to deliver a new level of coordination. She needed something that could better drive the process, improve visibility to her management team, and show dependencies between team members. It was absolutely critical that everyone know, at any time, who was waiting on them. They also needed better requirements management, and better collaboration tools. Her new system gave them the tools, but it couldn’t solve the communication issues on its own.

Tanya also changed the team schedule, setting up short, collective meetings every day. To avoid burdening one team, she set a rotating schedule: meetings where held at 9am in the US twice a week, and 7pm twice a week, with no meeting on Friday. Team members had to join at least two meetings each week, but it was up to them to pick which ones.

Tanya’s changes showed almost immediate results. The teams became more coordinated, and situations where one team was held up waiting for another pretty much vanished.

In a multinational organization, it’s important to remember that remote teams can feel like they are in a vacuum, lacking communication or cut off. To compensate, a good manager has to be extra vigilant and put in good processes, and good tools, and also make sure that no one team becomes the favorite. Tanya spread the meetings out to share the burden of after hours meetings. By doing so, she also sent the message that both teams are equally important.

Don’t Use Basecamp

Hi, I’m Zacharias Beckman, President of Hyrax International. Managing a multinational team can be really challenging. You have to make sure that each team, around the globe, is coordinating their efforts. That means overcoming the communication problems between them, tracking task dependency from one team to the other, and staying on top of projects — so that one team doesn’t get held up waiting for another one. So, the real challenge is figuring out to stay on top of each team and how do you make sure that all of their activities are coordinated well.

Get The Right Toolbox

Part of the answer is making sure that you have the right tools for the job. A good project management tool is going to help coordinate team activities and tasks around the globe. With the wrong tools in place, project teams suffer. They don’t have good communication, they don’t understand what the other team is doing, and task dependencies — the handoff of activities from one team to the other team — is not coordinated well. You end up with project chaos.

And when you’ve got team members that are separated by 8 or 10 or more hours in a day, this can derail the entire project for more than a day at a time.

We have two “go-to” tools that we use all the time very successfully. And we also have one that is a project nemesis. The one that we don’t like is Basecamp. We tell our customers, “Never use Basecamp.” The thing with Basecamp is, it’s super easy to use. You can sign up and start using it, literally, in a few minutes. People who don’t like process love Basecamp, because there is no process. You just put your tasks in. It’s easy, it’s unstructured, you can attach documents, and it all goes into Basecamp — and it kind of vanishes into Basecamp. That’s the problem, Basecamp doesn’t drive the process. We need tools that drive the process.

Driving The Process

A great project management tool is going to remind people of what they need to be working on, it’s going to track the interdependencies between tasks, and it’s going to make sure that someone doesn’t get hung up waiting on somebody else. This is particularly important for multinational teams where communication is already an issue. We need tools that will fill that gap and work hard to coordinate these teams, because they are already distributed, they are already having a hard time coordinating.

For small companies we recommend Teamwork PM. Teamwork PM is a good step towards an enterprise grade project management tool but it doesn’t have a lot of overhead. Your team can be using it in no time at all. It does coordinate tasks really well between team members, and it tracks dependencies, and it notifies team members of what they need to be working on. Which is one of the key ingredients to success.

For mid-sized and large teams, we recommend Atlassian Jira. It’s an enterprise grade solution. It’s completely customizable workflow system means that you can build out really elaborate, powerful processes to support your team and to support your entire organization. Jira can be customized to go all the way from requirements management and development through to customer support and care.

There are lot of great tools out there, Teamwork PM and Jira are two of them. But the most important thing to remember when selecting your project management tool — make sure it drives the process, make sure that the Project Manager is going to be able to easily get the information they need out of the systems so that they can stay on top of the project — before problems start to crop up.

Be sure to check our website. On this blog post we’ve listed a number of other project management tools that we have used in the past in addition to Atlassian Jira and Teamwork PM.

Our Project Manager’s Toolbox

Here are a few of the project management platforms that we feel are worth taking a look at. We couldn’t recommend Atlassian JIRA (for mid- to large-size organizations) and Teamwork PM (for small-size organizations) more highly, but they clearly aren’t the only solutions on the block. We track close to fifty different project management tools — these are the ones that have risen to the top, in our opinion.

  1. Atlassian — JIRA, Confluence, ServiceDesk for a complete enterprise solution
  2. Genius Project — Traditional, full cycle portfolio and project management platform
  3. Herogami — Agile development with Kanban
  4. Jama Software — Full lifecycle project management
  5. Liquid Planner — Traditional team and project planning
  6. Rally Software — Agile project management platform
  7. Teamwork PM — Full featured, easy to deploy task and project management

This Is Horrible Management Advice

I’ve been seeing a lot of management advice lately — hopefully it’s a sign that the U.S. economy is starting to boom again, and projects are taking off. But the problem is, most of the advice I’m seeing is really horrible — at least, if you’re working anywhere outside of America.

Western Management Is… Western

Western management theory works great if you’re managing a Western team. That means a team of people that are completely and entirely Western in terms of their culture and expectations.

For example, in this recent article, Lisa Evans reports that employers are “turning away from the traditional management style of hierarchies.” This is absolutely correct — in the United States. But applying this advice elsewhere in the world could be a huge mistake, especially in the highly organized and role-driven cultures throughout the East. Much of what Ms. Evans writes is sound advice across cultures. She writes that, “Recognizing these basic human needs can create a workforce of employees who are committed to working for their leader because of who they are and how they are treated,” a management principle that is a universal truth. But, as with most Western-oriented management writers, she also adds advice that will fall flat across Asia: “Empowering employees is one of the best ways to get commitment.” Unfortunately, this doesn’t work well in countries and cultures where explicit instruction is expected. In India, for instance, delegating and empowering your team usually backfires. The culture of India, one that produces great technical minds, is still focused on rote training and clear task delegation.

Adapt Your Management To Fit Culture

Don’t be scared of looking for advice online, though. There’s a lot of great advice — but consider the author and their audience. If the article seems to “American,” look for advice from a more International source. One great example is Donna Flynn’s recent article on Managing A Team Across 5 Time Zones. She writes that it’s important to share the burden of communication in a multinational team: “Several months ago we started a rotating meeting schedule.  Every month, each team member now has one evening, one mid-day, and one early morning meeting, and misses one meeting that falls in the middle of their night.  No team member is expected to attend a team meeting between 10 pm and 7 am.”

Ms. Flynn adds, “No tool can replace being together in the same room.  I bring my globally dispersed team together twice a year for workshops,” advice that I heartily agree with. It’s one of the key success strategies that I teach to our clients.

So choose your source. There are even products that focus on overly “Americanized” management techniques. One is The Time Timer. It’s a clock, big, bold, and designed to sit on a conference table and get people to stay focused on the agenda. The product pitch resonates with Americans: “You’re in a meeting, there are only two minutes left, and you’ve been talking around and around without even getting into the most important topic. There was no sense of urgency. And now it’s too late.”

But there’s a problem. This agenda-driven mentality is too Western. It only works in those Western cultures that prize time above all else — such as the U.S., Switzerland, Germany, and a handful of other European countries. But deploy this strategy in South America, and your partners will think you don’t care about getting to know them. Try it in most of Asia, and you’ll be labelled impatient and opportunistic, and they’ll think you don’t want to build a real business relationship. Most cultures around the world do not value time like Americans do. In fact, the most important business cultural preference for them: Relationships. That means taking time to build a relationship, and letting the meeting run long. Long meetings are prized because it’s a sign that everyone is getting to know each other. Short meetings send a different signal: “I don’t value this relationship very highly.”

The most important thing to keep in mind: Be aware of the business culture you are working with. Make sure that the management style you apply is going to be the right style for that culture, and for your team.