A strong Business Analyst (BA) develops business solutions by eliciting and analyzing a client’s processes and requirements. They are often at the “top” of the requirements funnel and are highly proactive, detail-oriented, inquisitive, and resourceful.    

They are the ones that know why a product is needed, what should be developed, and when it should be delivered. and when it should be developed by your team.   

Great BAs can also voice their own ideas and bring additional value through competitive analysis, thus reducing costs in a variety of ways or identifying easier pathways to the project’s end goal.  

What skills does a strong BA usually possess?  

Precise communication.  

One of a BA’s most valuable skills is the ability to shift tone as needed and identify the pain points of stakeholders and the project management team, acting as a liaison when necessary. A BA’s communications flexibility can be a crucial part of smoothing out the wrinkles so that everyone’s clear on what’s being done and bureaucracy doesn’t get in the way of the work.   

Facilitation and solicitation skills.   

Great BAs know how to assuage or persuade depending on the situation. Identifying which battles are worth fighting and which to leave by the wayside will ensure the core focus of the project is accomplished while stepping on as few toes as possible.    

Strong design, data modeling, and documentation capabilities.   

BAs should be able to crunch the numbers, making sure everything’s on track and secure the most efficient path toward the finish line (or if things happen to go awry, devise an alternative solution). Of note here is being able to come to their own conclusion: what the stakeholders or project team thinks is obviously very important to consider, but it shouldn’t color the BA’s independent analysis too strongly.   

Objective thinker with attention to detail and a systematic approach to problem-solving.  

BAs have a lot of people and tasks clamoring for their attention at any given moment. You’ll want a cool-headed thinker that can navigate that multi-tasking and keep an even keel when the stress of the project might cloud other peoples’ judgment.    

Technical toolset for issue identification, isolation, and solution-crafting.   

Having the know-how to hop in on revisions, zero in on problem areas, and offer useful insights to project members is a big part of the job—BAs shouldn’t be shy about getting their hands dirty if they need to. In essence, it’s important that BAs have an arsenal of investigative and analysis tools at the ready and develops the savvy to know which is likely to be most useful and successful. 

Interpret and document business processes through document analysis and stakeholder conversations.   

This is a fancy way of saying top-notch BAs can deftly separate the signal from the noise. They’ll know how to parse jargon and be able to reduce overly complex processes to their essential components. This simplification operates on two fronts: making sure the project team isn’t expending extra effort but also sidestepping attempts to blur the reality of the situation in the case that things start going off the rails. Should issues arise, good BAs can determine who or what is causing hold-ups and resolve the situation amicably.      

How is a Business Analyst different from a Project Manager?  

• A Business Analyst is not a Project Manager (PM).key differences in roles are: A Project Manager is assigned to manage project cost, timeline, and task completion while resolving issues and managing resources of a particular project. 
• A Business Analyst needs to ensure the delivered product meets the stakeholders’ requirements.   

Can a Project Manager also be a BA?  

With the proper skillset, a Senior Project Manager can function as BA for their team or project if it is small in scope. Larger, more complex projects warrant a separation of PM and BA duties and responsibilities.  

Can a BA also be a Project Manager?  

With the proper skillset and experience, it’s definitely possible for a BA to act as PM. If you try this approach, though, we’d recommend having a Senior PM or similar act as a mentor for them on the project if it’s the BA’s first time in a PM role.   

Why You Should Have a BA on Your Next Project.  

While the resource cost of a senior-level BA isn’t insignificant, the value benefits usually far outweigh the investment. Here are the top reasons you might consider bringing a BA on your next project.  

How does a BA create value over the course of a project?  

A BA can add value to a project by reducing project costs by building the right things the first time, for example.  

The biggest waste on a project is often the development of incorrect or unnecessary features. As a direct conduit to the client stakeholders, the BA can continuously help to prioritize the right features and keep the scope laser-focused throughout the duration of the project. This often manifests itself as developing clear acceptance criteria so all are on the same page when a task or feature is complete and meeting requirements successfully. 

A BA can help find more cost-effective solutions.  

For prioritized features, a BA might find more cost-effective solutions by repurposing tools already available, as well as the integrating of current client processes. Often, a slight rework of an existing business resource can be a much more cost-effective solution than brand new development from the ground up.  

A BA can add more accuracy to, or even reduce, cost estimates.

As features are developed, a BA can continue to trace the development back to requirements and provide clear test cases, data, and results verification. By benchmarking system KPIs simultaneously as requirements definition, a BA can evaluate the impacts a new feature could have on an existing system. Having clear benchmarks is also a great way to show tangible project success in areas like system performance or user satisfaction.   

A BA can discover new business benefits and propose value improvements  

By getting to the root of the business need, BAs can provide new ideas on how to improve the user experience while driving new monetization channels, all of which can result in ROI increase.  

A BA can assist with change management.  

Change management is the project management process dedicated to assessing how proposed changes to a project will impact everything else. BAs can chip in to figure out how changes will affect current functionality, project scope, timeline, and budget, then make a judgment call on a case-by-case basis.    

How do I know when I need a BA?   

All projects are unique and not necessarily deserving of a dedicated BA. In general, if you or your team have concerns about project size, scope creep, or the PM’s experience, considering a BA would make sense.   

Evaluate the size of the project.  

The more moving parts, team members, and expectations there are, the more opportunities there are for miscommunication and wasted effort. Consider the size of both the team and the scope of deliverables. The larger the project size, the more complex the interfaces and interactions with other client teams will be—and the more valuable a BA will become.   

Examine the scope and detail level of project deliverables.   

Project goals must be clearly defined at the outset of the project and thoroughly pruned and maintained over the duration lest they become inflated through scope creep. A combination of the original scope being hazy and/or poor requirements management during the project leads to scope creep, which can bloat the cost and schedule of a project over time. One of a BA’s core skills is to optimize requirements management and keep the score narrow, so if that’s a big concern on your mind, talk to a BA and see if they’re right for your project.   

Check the experience level of the Project Manager/Product Owner on the project.   

The less experienced the PM, the greater benefit a BA can bring to the team. For a freshly promoted PM, having a BA support them and offer an experienced viewpoint they can reference in real-time can be reassuring and help build confidence for future projects. That’s not to say that experienced PMs can’t benefit from a BA, of course, but in those cases, the BA will likely operate as an equal or in a more supplementary capacity as opposed to a mentor-esque role they’d have with a newer PM.   

Regardless of your PM’s capability level, if you’re tackling a project of a size or scope that’s new for them, check-in and see how they feel about a BA. Even if the BA isn’t on board for the full duration of a project, having a BA’s help for, say, initial requirements definition or stakeholder meetings could be a very welcome addition.   

Need a BA? We can help.  

In the right scenarios, Business Analysts can be a fantastic asset to keep everything nice and orderly across a project’s lifecycle. The key is knowing when and how to leverage a BA’s skillset to maximum effect. To that end, we’ve covered what a BA is and does, differentiated between PM and BA skillsets, how BAs can offer value across the project lifecycle, and how to determine whether a BA is right for a given project. Now that you understand when and how to leverage a BA, you’ll know how to tackle your next project right from the start—and whether a BA will be in the room with you. Good luck!  

Have a project that you think needs outside eyes? We’re experts in building digital experiences. Come talk with us about turning your idea into a reality or getting your project over the finish line.  

The post It’s Not Personal, It’s Business (Analysts): What Exactly Is a BA and Why Do You Need One? appeared first on Big Nerd Ranch.

But what if we thought about it as an opportunity to amplify and empower humans as opposed to simply eliminating their work from the system? What if these shifts presented an opportunity to create a great environment for our people, one where they actually want to show up and work where they can be more efficient and effective?

What we’ve seen over the past few months of The Great Resignation has shown just how reliant businesses are on human work. Whether it’s truck drivers or programmers, teachers or retail operators, bankers or line cooks, a lack of human staff is preventing businesses from taking full advantage of market demands. 

Automation is here to stay

Now, we know that automation and increased efficiency are key to any digital solution, otherwise, organizations could not justify the start-up and maintenance costs. But what if we looked at automation through a slightly different lens? Automation may mean the elimination of some tasks that were done by humans. But maybe that’s not the ultimate goal, but rather a byproduct of creating a more efficient system. So, the project becomes more about maximizing and amplifying the work of the humans in the system than simply replacing them in it.

At Big Nerd Ranch, we have always seen our purpose as human enablement. We started out as a training company whose goal was to teach students how to write applications for the Mac ecosystem, and we have grown our services to include consulting and building applications for our clients. In both cases, our goal has been to enable humans through digital solutions and training.

Over our history, we have seen incredible examples of how digital solutions can empower humans and unlock their potential.

Human-centered and digital-first

We have worked with one of the giants of the foodservice industry. What makes this giant unique among its competitors (aside from its delicious end product) is that it places humans and the human experience at the center of everything it does. All it takes to see this in action is to visit one of their drive-thrus. 

I don’t know how many times I have pulled up to a massive drive-thru line and thought “this is going to take forever.” But somehow, I am always in, out, and on my way with a smile on my face. This is because team members are able to use digital tools to quickly and accurately take my order, make sure it’s right, and seamlessly pass that information on to the kitchen and prep staff. My food is delivered quickly and accurately, and I feel like I have been treated with kindness and respect throughout the process. 

Other chains, including McDonald’s and Wendy’s, are taking the approach of looking to eliminate the human element from their drive-thru altogether. This may save on operating costs in the short term, but is it going to create a better experience for guests? Will it allow their employees to provide better and more efficient service? Will it increase customer loyalty? I don’t know the answer to all of those questions, but I would prefer to bet on humans + machines as opposed to the machines alone.

Digital enablement of the human effort

We also had the opportunity to see firsthand how human enablement can empower pilots serving in some of the highest pressure jobs out there. Being a Navy pilot is an incredibly demanding job and one that is directly tied to national defense, so you might think that Navy pilots are always equipped with the latest and greatest technologies. You would be wrong.

One of the most critical pieces of gear for a pilot is their flight bag. This contains all of the mission details, objectives, and things they need to watch out for as they are completing the mission. But instead of this information being available digitally, it consists of a spiral-bound notebook and a pencil. 

We had the opportunity to partner with SoarTech and the US Navy to reimagine this experience for pilots, to create an electronic flight bag that would serve up this mission-critical data digitally, decreasing the need for clunky paper and pencil and allowing for a more robust experience.

The Future of Work is empowering humans. 

Machine learning, digital solutions, and automation are a feature of modern life and will continue to be as businesses look for ways to increase productivity and reduce costs. But if we change the lens through which we approach these problems, we have the opportunity to create a business future where humans are at the center of the system and where their work is valued and amplified. That’s the kind of future we’re interested in building here at Big Nerd Ranch.

The post Don’t Eliminate Human Work. Enable It. appeared first on Big Nerd Ranch.

Take Agile and Design Thinking. While these terms might be thrown around fairly casually, there is still real value to what they represent—and how they can be used together. And maybe that comes as a surprise, but thinking about Agile versus Design Thinking is the wrong way to approach things since they aren’t at odds at all. In fact, they work amazingly well. 

Before we get into that dynamic duo, let’s break down what the terms mean and how they are different. 

The Difference Between Design Thinking and Agile

Agile is the How

Agile development is, by its nature, a product development process that is focused on getting a product out the door as quickly as possible, with the idea of improving through incremental improvements after launch. The advantage of the agile method is that the users get a well-built product that they can begin using almost immediately—with the assumption being that there will be iterations down the road. 

Problems occur when the focus is more on those iterations and not on the impact the updates have on the overall customer experience. 

Design Thinking is the Why 

Design Thinking, on the other hand, typically begins before any code is written and the Agile process even enters the picture. It begins by having a diverse team of designers, developers, strategists—really anyone related to the project—sit down and think about the needs of the user first and foremost. 

That’s where the “why” comes into play. The main goal of Design Thinking is to generate as many and varied solutions to the problem at hand and then refine them until the users’ needs are addressed. And, as we mentioned, Design Thinking is for the whole team, not just designers. The whole beauty of the process is that it brings in a wide range of opinions and ideas. 

Think of Agile as the way you fix something and Design Thinking as the tools you use to get the final product. 

Understand not Just the Idea, but Where it Comes From as Well

To get the best from both, it’s probably best to not think of Agile and Design Thinking as sitting on either side of a divide. In fact, they can not just work simultaneously, but they can actually work together. Often to fantastic results. 

Start the Process with Design Thinking

The best digital products are those that find a healthy overlap of meeting business goals and providing the users with the best experience possible. This is where Design Thinking comes into play. 

Design Thinking starts by better understanding users’ challenges and then coming up with the best solutions for those issues. By bringing Design Thinking into the process early on, you’re setting your digital product up for success. And, perhaps more importantly, you’re ensuring that your design and development team is running smoothly—according to IBM, a “design thinking approach can reduce the time for development and testing by as much as 33 percent.” 

That reduction in time is largely due to the fact that Design Thinking brings up and, hopefully, answers the vast majority of questions a project might encounter before any work is actually done. That means a well-built and user-focused product that is delivered quickly. Happy users. Happy client. 

Remain Agile with, well, Agile

When done well, the Agile development process is an innovative solution that allows for teams to move quickly, adjust on the fly, and produce a quality product that can meet customer needs in a timely matter. When considered in the realm of Design Thinking, Agile allows for teams to take all of the information gathered through the Design Thinking process and created a scaled Agile framework that can be applied to the actual development and design of the product. 

The upshot is that while Design Thinking is providing the answers to all the questions, Agile is there to keep the guardrails on the project, ensuring that deadlines are met and clients are happy. 

As Always, Collaboration is Key

The absolute best-case scenario is that both Design Thinking and Agile work beautifully together as a cross-functional team and everyone is happy. And that’s achievable! But, it does require work. 

Throughout the entire development process of a digital product, all parties involved have to have clear communication and the willingness to listen. From the Design Thinking side of things that means clearly stating the user’s problems and possible solutions while being open to any changes that naturally occur during the process. From the Agile perspective, the teams working on the actual product need to meet the expected requirements while also keeping in mind the end user’s experience. It’s not easy, but great things never are. 

That’s where we come in. At the Ranch, we are lucky to have experts in both Design Thinking and Agile Development. Our teams have been working within both processes from the start and relish any and all new opportunities to continue to evolve how we go about things. So, if you’re in need of an amazingly well-built digital product that will surprise and delight your users, get in touch! 

Source:

IBM’s Agile, meet design thinking

The post Design Thinking vs Agile appeared first on Big Nerd Ranch.

As Benjamin Franklin said, “By failing to prepare, you are preparing to fail.” Without a plan in place for how your team will accept new work and prioritize, backlogs will become overrun, sprints will lack focus, and there will be a lot of work in progress without a goal for completing features and releasing them to customers. Thinking about what’s next and acknowledging that your team can’t work on everything at once and still deliver value to your customers is key.

While it’s not uncommon to have many things fighting for attention, it is important to prioritize those items so that the delivery teams can focus on them. Often in sprint ceremonies, we hear that there are five or more priorities that lack focus and timing considerations. By providing clarity, you are smoothing delivery. 

Similar to the way having too much work in progress can impact delivery, continually shifting priorities leads to a lack of focus and slowed delivery. One way to avoid this is to establish goals and communicate them to stakeholders, the team, and potentially even your customers—hence, prioritizing them. Establishing key priorities helps to ensure that the right things get done at the right time, and that other deliverables don’t slip through the cracks. It also helps everyone stay on track by maintaining the prioritization of your backlog. 

Focusing delivery on what matters most, and what will bring the most value to customers

When you’re thinking about what can be accomplished in a sprint, release, or quarter – those goals should be customer-focused. What will bring the most value to your customers? What are they waiting on? What surprises do you have ahead and are there any key deliverables that have due dates (contracts, events, etc.)?

As we walk through the different prioritization methods below, these are the things that you should be thinking about. Remember not to make assumptions around what your customers expect and value. When it comes down to it, the only way to understand your customers is to get out and speak with them. Understanding your product is knowing your customers and what problem your product solves for them. 

So, how do you manage prioritization and what are the best methods to figure out what’s next? Below are two methods that work well. At the end of the day, which will work best for you comes down to how you and your team work. Like iterating on a product to find the best features, iterate and find the best process. 

Stack Ranking

Stack Ranking is the most basic prioritization method. It consists of simply starting at the top of the backlog and prioritizing each item, one at a time. 

To Stack Rank your backlog, start by reviewing the first backlog item, just to get a feel for the “ask.” Then take a look at the second backlog item. Is the second item more important than the first? If so, move it above. If not, leave it where it is and move on to the next item. Proceed this way until you get to the bottom of the backlog. 

When weighting the items things that should be considered include: 

• value to the Customer 
• legal requirements 
• deadlines 
• and dependencies. 

Items that are high-value to your customers should be the priority. Contractual, legal, and security items also take precedence. When considering priority, don’t forget timing. If there are any contract deadlines or events that may be planned these must items take precedence. The final consideration is if one item requires another for completion, the item that it is dependent on is a higher priority.

While Stack Ranking can be done alone, pulling in the team and stakeholders will provide perspective and ensure that prioritization considers the product as a whole and not just one perspective. Of course, the more participants the higher the cost. Before meeting with the team and stakeholders, make a few initial passes, prioritize and group similar work items in the backlog. Grouping will allow for a more efficient Stack Ranking process. If similar items are together, they can also be moved together as you work your way through the backlog.

While this may sound tedious, what is great about this method is that when you reach the bottom of the backlog, you are done (at least for now). The backlog is now in order and by making a conscious effort to keep it that way you’re setting the product up for success. 

MoSCoW method

The MoSCoW method hails from Rapid Application Development. With this method, items are grouped into one of four categories: must haves, should haves, could haves, and won’t haves. 

• Must Have – Items that must be included in the product. These are the items required for Minimum Viable Product (MVP).  Without them the delivery would be considered a failure. 
• Should Have – Items that are not required but are expected. These items are not as important as Must Haves but aren’t far behind them. 
• Could Have – If there is time and budget, these items could be included. They are not as important as Should Have items but would bring value to your customers. 
• Won’t Have – Items that will not be included. This doesn’t necessarily mean that the item will never be complete. But at this point in time, these items are not a priority and will not be included in the upcoming releases.

To begin with, the MoSCoW method, determine how you will flag which group each item belongs to. How you do this will depend on your backlog tool. You will want a way to filter and search for each category. If labels are available and searchable, this is the best method. Another way could be to use a priority or stack rank field by assigning a priority/stack rank to each of the four groups. 

Once you’ve established how to group the items within the constraints of your backlog tool, next work through the backlog labeling each item with either Must Have, Should Have, Could Have, or Won’t Have. When all backlog items have been categorized, group them by their category and move them into the appropriate order with Must Haves first, Should Haves second, and so on. 

Now comes the part that takes discipline, for each category use stack ranking to prioritize the items. Take a look at only the items in each group and decide which is most important. Then what comes next. 

You may be thinking, “If these are all Must Haves, does it matter?” Yes, it matters. The backlog order will be the order in which items are picked up and implemented. For Must Haves in particular, dependencies and complexity should be considered, as well as what is most important. The most important items should always be addressed first. If for some reason you were to run out of time for the next delivery, would you want an unexceptional Should Have released instead of a Should Have that will delight your customers. 

These are the decisions to be made. Similar to Stack Ranking this is an exercise that can be done alone but gains perspective when stakeholders and the team are included. So these meetings are not long and arduous, start with the grouping exercise. Then in a separate meeting stack rank within the groups. This may take time but once complete you’ll have an organized backlog that will be ready for not only the current release but also future release planning. 

Continue Setting Yourself up for Success

Once you know what’s next, it is easier to discuss new work and timing. After completing the prioritization process, don’t just let that hard work fall away. Set yourself up for success by prioritizing new items as they come in. At the end of every sprint, check in to ensure the work planned for the next sprint still aligns with the current priorities. 

Once a release or quarter, check-in with stakeholders and the team to ensure that the backlog priorities are still on track. Frequently touch base with customers to gain feedback and find out if there are any new problems to be solved. This will ensure that you’re working on those items that are most important and will bring the most value to customers. 

The post Why Prioritization is Important and How to Best Prioritize Your Backlog appeared first on Big Nerd Ranch.

Breaking Debt Down by Awareness 

What’s the most crucial step in beginning to solve any problem you may face? Maybe you believe it’s learning from an expert. Better yet, you could argue that it’s necessary to jot down all the relevant information. Or you could simply break the issue down into smaller parts, unveiling the root of the issue. These all seem like pretty reasonable approaches, right? Not so fast. 

The first critical step in handling any problem is to recognize the existence of the problem itself, and that will begin to help you understand and solve for the 4 main types of tech debt. 

• Intentional (or Deliberate) Tech Debt
• Unintentional Tech Debt
• Happened-upon Tech Debt
• Bit Rot

The Good, the Bad, and the Ugly

It’s no different when it comes to solving your tech debt. The first necessary step is identifying your debts, and likewise, the interest to be paid. When it comes to identifying tech debt, we begin with two broad categories: intentional and unintentional. 

Intentional (or Deliberate) Tech Debt 

Up to this point, tech debt has established itself as the problem child within the world of software development. Well it seems tech debt may actually have another trick up its sleeve, because wouldn’t you know, it’s got a good side too. Enter intentional tech debt. 

Often referred to as deliberate debt, intentional debt is incurred based on considered decisions. Typically, this debt is accrued with the understanding that it will allow your app to get to market faster. The important thing to remember is that it’s vital to monitor the debt as it collects and to keep in mind the potential consequences.  

Here are a few important considerations for your team prior to deciding to take on debt.

• What potential impacts on reliability are there going to be by reaching the market faster? Will this hinder the user experience of the product?
• Will development be slowed in the future because of this debt? 
• Will your team have the bandwidth to deal with existing debt in the future?
• Are all stakeholders aware and okay with the decision to accrue debt?
• Do you have a plan in place to deliberately track debt?

 Unintentional Tech Debt

Now if there’s intentional debt, then logically there must also be unintentional debt. This debt is not nearly as friendly and often much less in your control. Unintentional tech debt has a few notable forms. 

 Happened-upon Tech Debt 

Happened-upon tech debt is essentially intentional debt’s evil twin. This debt was created in the past but unveils itself in the present. Happened-upon debt is unknown to the development team and usually exists under the umbrella of a few circumstances. 

Maybe you’ve been hired to improve an app, taken on the code of a developer who has left your team, or you’ve brought in outsourced code from a third party. In any of the cases, happened-upon tech debt can then arise in the form of bugs as you try to create features over the suboptimal codebase you inherited or as runtime errors when you attempt to merge your code into these codebases. This debt is dangerous because you can’t account for it while determining the scope of your project. 

You can limit happened-upon debt by writing or merging with repeatable, simple, and readable code. It’s also good practice to include code audits during your discovery process to reduce the likelihood of happened-upon tech debt. Similarly, keep design thinking at the forefront of your development process.  

 Bit By Bit, Little by Little (Bit Rot)

Bit Rot tech debt refers to the progressive devolution of software into extremely complex and hard to manage systems. Through many small changes and lots of hands working on the same code independently, bit rot tech debt can internally hinder the usability of code altogether. Combat bit rot tech debt with frequent refactoring and a deep level of understanding regarding design by all parties prior to coding.  

A cousin to bit rot is lack of skill. Tying into your dev team’s level of understanding, lack of skill tech debt is a reckless and inadvertent form of debt attributed to poor logic and coding practices. 

Let Your Debt Be a Thing of The Past 

Your team’s next steps are crucial. You know tech debt is there, you know its potential, and maybe you even have a plan for handling it in the future. But maybe not. Maybe now you’re concerned if your team will be able to pay off the interest on your tech debt. At Big Nerd Ranch, we can work with you in whatever stage of development necessary to clear you of all debts, technical and design alike. Whether it’s bringing your idea to life through our immense digital product development process, leveling up your team’s skills through corporate training, or working alongside our embedded experts, we’ll make sure tech debt is out of the picture every step of the way. Make sure to reach out to let the Nerds help steer you towards a debt-free path.

The post Types of Tech Debt appeared first on Big Nerd Ranch.

When designing a web application, a strategy that has often been used when testing is to mock third-party dependencies. There are many benefits to doing this such as producing hard-to-provoke responses on-demand; however getting actual responses seems better than simulating them. Why might a developer want to use Dockertest as an alternative for producing realistic responses?

Testing Strategies

One of the main strategies for testing in Go is to instantiate a test server and mock responses for specific paths related to the requests under test. While this strategy works fine for simulating errors and edge-cases, it would be nice to not worry about creating fake responses for each request. In addition, developers could make mistakes producing these responses which could be problematic for integration tests. Developers write these tests as a final check to verify that applications produce correct results given many scenarios.

Dockertest is a library meant to help accomplish this goal. By creating actual instances of these third party services through Docker containers, realistic responses can be obtained. The example below shows the setup of the container using the Dockertest library and how it is used for testing.

An Example of Using Dockertest

The below example demonstrates how Dockertest is utilized for testing a simple CRUD application. This application, a phonebook, manages phone numbers using Postgres as the external database. The code in this article is part of a larger runnable demo available in BNR-Blog-Dockertest. It relies on:

• Go 1.16.5
• Docker 20.10.7
• Dockertest 3.3.5

Test Setup

The test file will verify the CRUD functionality of this phonebook and ensure the storage code actually manages to store data in an actual Postgres database, that is, properly integrates with Postgres. This is done by running Postgres in a Docker container alongside the test process. Before any test runs, a Docker connection must be established and the Postgres container launched with the configuration expected by the test code:

var testPort string

const testUser = "postgres"
const testPassword = "password"
const testHost = "localhost"
const testDbName = "phone_numbers"

// getAdapter retrieves the Postgres adapter with test credentials
func getAdapter() (*PgAdapter, error) {
    return NewAdapter(testHost, testPort, testUser, testDbName, WithPassword(testPassword))
}

// setup instantiates a Postgres docker container and attempts to connect to it via a new adapter
func setup() *dockertest.Resource {
    pool, err := dockertest.NewPool("")
    if err != nil {
        log.Fatalf("could not connect to docker: %s", err)
    }

    // Pulls an image, creates a container based on it and runs it
    resource, err := pool.Run("postgres", "13", []string{fmt.Sprintf("POSTGRES_PASSWORD=%s", testPassword), fmt.Sprintf("POSTGRES_DB=%s", testDbName)})
    if err != nil {
        log.Fatalf("could not start resource: %s", err)
    }
    testPort = resource.GetPort("5432/tcp") // Set port used to communicate with Postgres

    var adapter *PgAdapter
    // Exponential backoff-retry, because the application in the container might not be ready to accept connections yet
    if err := pool.Retry(func() error {
        adapter, err = getAdapter()
        return err
    }); err != nil {
        log.Fatalf("could not connect to docker: %s", err)
    }

    initTestAdapter(adapter)

    return resource
}

func TestMain(m *testing.M) {
    setup()
    code := m.Run()
    os.Exit(code)
}

TestMain() ensures the setup() function runs before any test runs. Within the setup() function, a pool resource is created to represent a connection to the docker API used for pulling Docker images. The internal pool client pulls the latest Postgres image with specified environment options and then starts the container based on this image. POSTGRES_PASSWORD is set to testPassword which specifies the password for connecting to Postgres. POSTGRES_DB specifies the database name to be created on startup and is set to a constant: phone_numbers. The container port value is the port published for communication with Postgres based on the service port value. Afterward, the postgres instance instantiates and attempts to connect to the new docker container. If there is an error doing this, the test suite exits with an error.

An example of a test that utilizes the Postgres instance is below.

Test

func TestCreatePhoneNumber(t *testing.T) {
    testNumber := "1234566656"
    adapter, err := getAdapter()
    if err != nil {
        t.Fatalf("error creating new test adapter: %v", err)
    }

    cases := []struct {
        error       bool
        description string
    }{
        {
            description: "Should succeed with valid creation of a phone number",
        },
        {
            description: "Should fail if database connection closed",
            error:       true,
        },
    }
    for _, c := range cases {
        t.Run(c.description, func(t *testing.T) {
            if c.error {
                adapter.conn.Close()
            }
            id, err := adapter.CreatePhoneNumber(testNumber)
            if !c.error && err != nil {
                t.Errorf("expecting no error but received: %v", err)
            } else if !c.error { // Remove test number from db so not captured by following tests
                err = adapter.RemovePhoneNumber(id)
                if err != nil {
                    t.Fatalf("error removing test number from database")
                }
            }
        })
    }
}

The table-driven test case above is defined to verify the create method of the postgres storage adapter. The first case assumes that a test phone number successfully inserts into the docker Postgres instance. The second case forces the database connection to close and then assumes that the create method fails on the Postgres instance.

Conclusion

In summary, mocking is a fine way to test third-party dependencies but using a library such as Dockertest can allow for a more realistic and robust integration testing environment. With the capability to launch any Docker container, an entire portion of a web application can be tested with real results in a controlled test environment. Such a library can be useful within a unit test or integration test environment. Dockertest can also be set up in CI environments, as with GitHub Actions’ service containers. For more examples, see the Dockertest repository.

The post Using Dockertest With Golang appeared first on Big Nerd Ranch.

If your legacy application is the older house on the block then application modernization is a much-needed remodeling. 

In the same way that you wouldn’t completely demolish a house that has good bones, you shouldn’t completely get rid of your existing applications, especially one that you’ve probably already invested in both financially and structurally.

What is Application Modernization 

Application modernization is the best way for companies to revamp their legacy applications for modern times without having to start completely over. Application modernization takes a legacy application and revamps it by updating its software for newer computing approaches. These approaches include modern languages, updated frameworks, and infrastructure platforms.

Why You Need It 

Two words: money and time. You’ve already spent both building out your existing application and it’d be a shame to have to completely start over. With application modernization, you don’t ever have to.

With application modernization, your company is able to keep the most critical application up-to-date by implementing new structures and frameworks, without having to build an all-new app. It’s also a great opportunity to implement any accessibility features that you might have left out of the original version. 

Beyond the purely technical side of things, taking a renewed look at your app allows you to reconsider any design elements that might be outdated. Not only will your app look great, but it will be much more user-friendly. 

How to actually use application modernization

There are many reasons why you might want to use application modernization and luckily, there are also many ways to use application modernization depending on your goals. The three main ways to use application modernization are lift and shift, refactoring, and re-platforming. Let’s dig deeper into each of these.

Lift and Shift

Lift and shift, otherwise known as rehosting is the process of taking an existing application and moving it to a newer infrastructure, such as a public cloud platform. The application itself doesn’t change, only its platform.

This can be a good option for you and your company for a number of reasons. Moving your existing application to a new platform, such as a cloud platform can help keep your business agile and in with the times. It can also help keep your business focused since there is no need to worry about system administration and ultimately it can help cut costs.

Refactoring 

The second option is refactoring or rewriting the application. This process involves taking the legacy application and rewriting a large portion of the underlying code to help the application run in a new environment such as cloud infrastructure.

Refactoring is a great choice for those with a single application that wish to break into smaller pieces, also known as microservices. It’s also a great way (or, the only way) of digging yourself out of tech debt—something that often and unfortunately comes along with legacy apps. 

Replatforming

The last option for application modernization is one that sits in between lift and shift and refactoring. This third option is known as re-platforming. Replatforming is the process of utilizing complementary updates that enables the legacy application to take advantage of a modern cloud platform.

You Have the Idea, We Have the Way. 

Now that you have a good understanding of application modernization, you’re probably wondering how to get started. We’ve got you covered. Whether you want to learn how to navigate an unknown bit of software or a different design perspective, we’ve got a team of Embedded Experts ready to help. Ready to get started? Get in touch and let’s chat! 

The post What Is Application Modernization? appeared first on Big Nerd Ranch.

Some of the greatest inventions have occurred by accident, but when it comes to creating amazing web services, intentionality is the name of the game. And there’s not much more intentional than API-First Design. 

See, web services built without intention often suffer in regards to quality, such as slow delivery and rife with errors. And once put into place, low-quality web services are expensive to update.

But what is API-First Design?

From a high level, API-First Design is a purposeful approach to building high-quality web services in a way that avoids the pitfalls of an ad-hoc build. This approach can be broken down into five steps:

• treat the API of your web service as the standout principle
• appoint product ownership for the API development to ensure a core focus on quality
• design the API contract before coding the web service
• build the frontend and backend alongside one another based on the API contract.

The Five Steps of the API Process

1. Treat the API of your web service as a first-class citizen.

API-First Design is like a lot of great things—it takes time, effort, and money to do correctly. That means learning a new process, having dedicated folks on the project, and realizing that it’s an ongoing process. 

But, if you’ve looked at all options and API-First Design is the way to go, then it’s time to put all you have behind it. In practice, that will require committing to the process by getting buy-in from your entire organization. You’ll also need to clear some space in both your organization and budget to ensure you get the most out of your work. 

2. Appoint product ownership for the API to keep the focus on high quality.

Quality products always begin with having a product owner, and it’s essential that your API receives the same star treatment. See, building out an API without leadership means that changes will occur in a more haphazard way, leading to poor quality. But, with a product owner, you’ll keep the focus on what’s best for the build and best for the web service overall. 

And since this person is going to need to get stakeholders involved from both a technical and non-technical perspective, the role doesn’t have to be a developer or architect. In fact, their most important role is to advocate for your particular process to ensure that the goals are prioritized and met. 

3. Design the API contract before building the web service in code.

The next important step is to design the API before writing code. You’re going to want to create something that both your team and stakeholders can understand. It doesn’t have to be super fancy—think sticky notes or a good old-fashioned whiteboard session. Remember, this isn’t coded, and it’s vital that everyone on your team, regardless of their role, is able to understand what is being created and is able to add suggestions.

As your API first design solidifies, translate the API contract to a machine-readable format, such as OpenAPI or GraphQL Schema. This format will have major payoffs in the next step.

4. Automatically generate documentation, client/server stubs, and mocked backends from the API contract.

A lot of time spent designing and creating documentation doesn’t feel very productive, as the documents are stored somewhere and never referenced again. That’s why it’s important to store your API contract in a machine-readable format like OpenAPI or GraphQL Schema. These formats automatically generate a number of extremely useful artifacts that will help your development process go faster.

5. Build the frontend and backend in parallel based on the API contract

Usually, frontend and backend development occurring at the same time can be a slippery slope that leads to a poor quality product. But this is where the API contract comes into play. This API contract prevents frontend and backend developers from interpreting a loose specification differently because the specifications are so well designed from the start. 

The API contract is basically your North Star. Changes will still occur, but the API contract will keep you on the right track.

If done correctly, your web service will be consistent, reusable, well-documented, and easy for developers to use. 

Don’t Settle for Anything but the Best

Your web service is a valuable resource for your organization, both from a logistical and financial standpoint. If you’re curious to learn more about API-First Design, check out our ebook, API-First Design: How some of the most important work is done before the first line of code is even written, or reach out and chat with a Nerd. We’ll be happy to help!

The post The Five Steps of API-First Design appeared first on Big Nerd Ranch.

But there can be a downside to incorporating new product design ideas or features as you’re working on a software development project: design debt.  

Wait, what’s Design Debt? 

Design Debt is when new design elements are added to an application without considering how all these individual elements will eventually fit together. The end result is an app that has some great features and might look nice but lacks a design pattern or clear path of usability for the user. That usually means that important items might be hidden behind too many tabs or that the overall UX is just clunky.

You’ve probably heard of technical debt—the idea that choosing the easiest (rather than best) software development solution now causes headaches down the road as new code is added in.

Design Debt is similar, but while technical debt is a pain for other developers working to untangle cobbled together code, Design Debt has some pretty serious and negative implications for the end-user. Bottom line—your app will need some help. 

Why is Design Debt so dangerous? 

The worst part about design debt is that it’s not something that happens all at once. It creeps up on you, building and building until it’s big enough for you to notice. By that time, it’s a massive headache and a big mess to clean up. 

We recently partnered with a client whose work fits this design pattern perfectly. Prior to working with us, they had worked to further refine their app and to make it as useful as possible. And they were going about that in the right way. They were asking the right questions of their users and understood the problems their customers faced when using the app. 

The design issue was that they never fully mapped out how to best integrate the new features and functions in a holistic way. So, instead, they added a feature here and a functionality there. The end result was that the app contained all that the users wanted and needed, but was visually confusing. No one really knew where to look for the things they needed. The design debt had mounted up, and their users were paying the price.  

How can I avoid Design Debt? 

Plan time in your product lifecycle for designers to take a step back and look at all the individual feature components and see where they might be regrouped or reorganized. Don’t neglect to also plan for the time needed to refactor and move things around. Streamlining or removing feature components can help pay off Design Debt early before too much interest has built up and you’re looking at a rewrite. It’s cheaper to fix it in smaller increments rather than 3 years down the road and it’s a major rewrite for a development team. 

One great way to head off design debt is to take your app through a design audit, something that is a part of our Customer Experience offering. If you’re curious about what other benefits Customer Experience offers, get in touch.

Now, this is great if you’re just starting on your app and have the time to build all these processes into your design. What if you’ve found that you’re already in debt with your current app? Stay tuned for Part 2 – How to best manage design debt. 

The post Design Debt: What They Don’t Tell You About Design Thinking appeared first on Big Nerd Ranch.

• How and where will someone use this tool?
• What problem are they trying to solve with it?
• How do they currently solve this problem?
• Will the tool reduce the number of steps involved?

From there, you begin to ideate on the best way to structure a helpful experience for them through technology. (For a more detailed exploration of the phases of Design Thinking, click here.)

Of course, when laid out in this order, Design Thinking seems like the obvious choice. Certainly, it’s the one we recommend – and always use to develop digital products. But when faced with intense time-to-market constraints, the technology-focused approach often wins out. After all, an unfinished product with a thoughtful development process does nothing to advance your company’s bottom line. 

Yes, your app needs to function before anything else can happen. But what if you don’t have to choose between a carefully designed user experience and hitting aggressive business targets? 

Upon further examination, Design Thinking offers you the fastest route to a successful digital product – one that can help you meet your business goals through, rather than at the expense of, superior useability and creativity. We would even go so far as to argue that you simply can’t build a successful digital product without Design Thinking. 

Let’s examine why:

In today’s competitive environment, user experience IS the product.

The fact of the matter is, the market for digital products is a crowded one. Gone are the days that users will settle for an okay experience when they could be having a great one. And the constant introduction of new technologies compounds the pressure: 73% of customers reported that one extraordinary experience with a company raises their expectations for others, according to Salesforce.

Beyond individual budgets, a bad experience with a digital product can do even greater intangible damage to your brand. Sixty-seven percent of customers believe that the way a company uses technology is a reflection of how it operates in general. Even seemingly small features updates can undo the hard-won confidence users have in your company’s ability to deliver value.

 In this competitive atmosphere, the user experience is the product. 

The best way to create a good one? Empathize – which just happens to be the first stage of Design Thinking. Often, teams actually interview users to gain these insights. By understanding the user’s specific situation and challenges, you can engineer an experience that’s truly beneficial and easy for them – so they don’t immediately abandon your tool and create an alternative solution.

You can keep technical and design debt to a minimum.

Typically, two types of pressures force development teams away from a user-first mindset and into two versions of debt, both of which deprive an organization of its return. First, the race to release an application often drives technical debt. Technical debt accrues when a programmer opts for a faster solution over building out a more involved one that is less likely to incur bugs down the line. 

Technical debt describes the weight of all these shortcuts as they transform into complicated, expensive messes that take extended time (and budget) to fix. A 2018 report from the Consortium for IT Software Quality indicates that software developers spend 42% of their time fixing bugs, with the task constituting 80% of IT budgets. If you’re in a regulated industry, a web of buggy code can have even larger consequences in the form of HIPAA and PCI violations – which can cost up to $1.5 million apiece. 

Once an app has been released, there’s also the pressure to introduce new features. But when programmers don’t take the time to consider how a new feature might function in relationship to existing ones, they take on design debt. As a result, the feature comes out on schedule (and it looks fantastic) but people can’t easily take advantage of it – or worse, it interrupts the user flow entirely. The time saved on the front end ultimately creates added effort, expense, and brand damage later. 

Design thinking helps development teams avoid both of these pressures from the start. First, by putting the user’s needs into context, development teams can balance the must-haves from an experience perspective with the business goals of a particular project. Most importantly, as solutions pass through the prototype and development stages, teams have a low-stakes way to quickly determine whether the product or new feature will thrive out in the world (and where bugs threaten success). From there, they can put their focus on exactly what needs adjustment and what’s not serving the user before creating a full-scale version of the product or update. 

You have a set process with flexibility – that yields the strongest solution.

Leaving room to imagine multiple solutions to a problem doesn’t mean you have to abandon all sense of efficiency. Design Thinking, like any other structured approach, introduces a set process with clearly defined phases. Yes, there’s ample room for ideation, but a faithful approach progresses steadily to prototyping, development, and testing – saving you ample time in the long run with a product that performs well at the start.

And thanks to the inherent flexibility of ideation and prototyping, your team still considers multiple solutions and configurations, ensuring your final product has maximum creativity and functionality from day one. 

In conclusion, technical functionality without useability is ultimately a wasted expense. 

Or, to put it more plainly: just because it turns on, doesn’t mean it’s working. Design Thinking is the ideal method for staying on schedule with a digital product that can meet real-world needs under real-time pressures and constraints.

At the Ranch, we’re always looking for new ways to make Design Thinking enhance digital product development. If you’re ready to give Design Thinking a test drive, or apply it to a great new idea, we’re here for support, guidance – or just a friendly chat. Want more information? Check out what our digital product agency can do for you. 

The post Why Design Thinking Is a Must-Have for Digital Product Development appeared first on Big Nerd Ranch.