Level 12 Blog

The Hidden Costs of Offshore Development

2025-07-23T00:00:00Z

If you're considering offshore development because it looks like a great way to get more done for less money, you're not alone. Most companies go down this path thinking they've found the perfect solution to their capacity and budget constraints.

The math seems simple: pay less per developer, hire more of them, ship faster. What could go wrong?

As it turns out, quite a lot. The hidden costs and complications of offshore development often end up making projects more expensive and time-consuming than if you'd just hired fewer, better developers locally. And the partial offshore approach that's supposed to fix these problems? It usually just shifts the burden around without solving the core issues.

The Offshore Development Promise

I can't tell you how many times I've heard from a client, "We had an offshore team working on the project. Nothing works now, and nobody is answering the emails."

Purely offshore development teams can provide competence and expertise, but are often oversold on the type of quality they will, in actuality, deliver.

Cost and capacity are the driving factors that bring companies to leverage offshore talent. Hiring in-country costs a lot more, so an organization can get a lot more capacity for a lot lower price by going overseas.

That makes the stakeholders happy - they can deliver the product at a lower cost on a faster timeline.

Or so they think.

The Hidden Effects of Offshoring

Going offshore presents some offsetting factors that make many of these deals go bad:

Language and context barriers are real. Communicating the business needs may not translate well to a developer's local context, which makes understanding the development requirements themselves a lot more difficult.
Cost projections are based on quick development cycles. Something may be done within the timeframe specified, to be sure. But will it have passed QA? Will it be built according to industry-standard development practices (for example, with solid architecture or a well-developed test suite)? The company buying the capacity will not know until it is too late, the money has been spent, and the product doesn't work. Building a product can devolve into endless cycles of seeing something new, seeing it break, requesting fixes, seeing something new break, requesting more fixes, and rinse and repeat.
When navigating overseas contracts, there is always a risk that the entity providing the capacity will go dark. When they do, there is no realistic recourse on the contract. Then, you need to find a new source of development capacity, rebuild a team's collective context of the code, and recast the product vision.

All of these factors waste cycles, which adds to the cost.

Where the expenditure was to have been less, more is required in terms of time and money from the client organization to manage the development process. Usually, no one in the client organization has managed developers before, much less to a high level of efficiency, and so the entire process slogs on.

Is Partial Offshoring a Good Compromise?

Because of the quality concerns, a recent trend in software development management has been to pursue a hybrid model of partial offshoring. In that scenario, the project management and tech lead are kept onshore, with the assumption that the above factors are mitigated accordingly.

With the partial model, project owners still believe they're getting a bargain on the price, even though they have to pay more for the management pieces. And the intent is to make any onshore developers happier as well, because on paper, they still have quality control over the codebase.

That sounds good, but does it work out?

The Reality of Partial Offshoring

Well, having the onshore project management solves one problem: the project owners don't have to manage the project directly. Aside from that detail, though, the same factors end up playing out in practice.

Work increases for the onshore developers standing in the tech lead role. They want to stand up for quality, but doing so requires they spend more time reviewing and re-reviewing proposed code changes. Each new feature may require several review cycles. Depending on the project, QA may also fall to these resources, consuming more of their time.

Motivation can become an issue for developers in that situation. They see the lack of quality and spotty attention to detail, and they know they are capable of doing better. But if their time is consumed by managing the output of outsourced resources, they can feel trapped in a situation where they are not able to demonstrate their true talents.

Timelines can also miss. The stakeholders in these cases will generally project resource hours the same way they would for a fully onshore team. But the more iterations of the development/review/qa cycle for each feature, the longer delivering those features takes. Efficiency is also lost in the churn for the offshore developer, as they've already moved onto other tasks before the world turns far enough that the managers can review in their timezone.

The pressure of the timeline will also decrease the manager's motivation. They know how crucial best practices in development are, and they know what happens to projects that don't get them enforced. But they also feel the impending deadlines. This presents them with a problem they can't solve with the resources they've been provided.

Of course, the hiring organization could iterate on the offshore resources to find those who will embrace western ethics, adhere to modern development practices, and provide the attention to detail needed. Arguably, though, the process to find such a resource will require a lot of iteration, repetition of corresponding onboarding, and eventually cost nearly what it would to find good onshore capacity in the first place.

The Better Alternative

With all of that in mind, partial offshoring simply moves the goalposts of who manages the development capacity. While the managers may be more practiced in attempting to bring quality out of a team of developers, that's not likely to overcome the inherent problems that will surface.

The principle remains true that every member of the team needs to be a multiplier and contribute to overall quality. Best practices must not be left to a single manager - everyone on the team needs to own it. In particular, vision transfer needs to be seamless, not a process where excessive cycles are spent.

It's better to hire a couple of 3x developers than several 1x (or sub-one) resources. Projects staffed with motivated multipliers will shine.

Conclusion

Here's the thing: offshore development keeps looking attractive because the upfront math is so appealing. But once you factor in all the hidden costs—the endless review cycles, the communication overhead, the quality issues, the management burden—you often end up spending more than you would have with a smaller, higher-quality team.

The partial offshore model doesn't really solve this problem. It just moves the pain around and creates new bottlenecks.

If you want a project that actually ships on time and works when it's done, hire developers who can multiply your efforts rather than drain them. Yes, they cost more per person. But when you don't need three rounds of fixes for every feature, when you don't need to re-review every pull request, when the code actually works—that's where you find your real savings.

TravelTime vs. Google Maps API

2025-07-23T00:00:00Z

The bottom line: If you're building a tool to map jobs within commute range, TravelTime's specialized APIs will save you time, money, and headaches compared to Google Maps—especially for public transit and realistic commute estimates.

When workers need to find manufacturing jobs within a reasonable commute, the mapping tool you choose makes all the difference.

After building commute-mapping features with both Google Maps and TravelTime, one clear winner emerged for this specific use case.

While Google Maps seems like the obvious choice, TravelTime's purpose-built commute analysis tools provide better accuracy, more realistic transit estimates, and simpler implementation for showing workers exactly where they can realistically travel for work.

Understanding Data Needs and Sources

I want to map manufacturing jobs that are available within a 30-minute commute of a given address. What tools do I need, and what do I reach for first?

I'll need two data sources: job data and mapping data. Getting job data is not a hard problem to solve - we just want a structured file with enough data to know an address or coordinate for each job.

The file format doesn't matter very much, as long as we have the needed fields. It would be wonderful if shift times were provided, but job listings are rarely that clear.

The mapping data is more difficult because we'll depend on a source of traffic data. That gets complex:

How am I commuting? Am I driving? Taking the bus? Walking? Some combination (multi-modal commute)?
If I am taking the bus, how much am I willing to walk on either end of the route?
What time of day is it? I can't get as far, as fast, driving during rush hour. Bus routes also only operate at certain times throughout the day.

Google Maps

As a developer, it's easy to reach for the biggest box on the shelf with a familiar name and just run with it. Google Maps is an obvious starting point: it has a lot of available data and a lot of documentation about how to mine it.

Distance Matrices and Cost

We can do a lot with Google Maps. We can pin jobs on the map based on locations and run a distance matrix to determine the commute duration between sets of points.

Given a home address, I can know what jobs are within a certain range. That matrix is flexible depending on the time that I want to leave home or arrive at work.

But Google Maps has drawbacks. Do I run the distance matrix for every address that I need to see? That cost would start to add up.

Isochrones

What if I want to see an isochrone, or a shape representing the complete area within that 30-minute commute, so I can more easily assess why jobs are inside or outside that area? Google Maps doesn't have one easily available.

It is possible, but you have to do a lot of work to get there by computing distances between points down to a particular resolution to set up a usable shape.

For instance, we could break the map down into something granular, like census tracts or census blocks, compute all of the travel durations, and map the shapes. It’s doable, but the more granular we get, the number of requests (which we pay for) goes up exponentially.

Commute Wait Time

If I'm taking the bus from home to work, and I tell Google Maps to give me a commute time for arriving at work for an 8 am shift, it might tell me it's a 30-minute commute. But it won't tell me what time the bus arrives and how long I’ll have to wait to start my shift when I get there.

That 30-minute commute might have me arriving at 6 am based on a certain bus route, and I would be left waiting two hours to start. That waiting time doesn't get counted as part of the commute.

TravelTime

A UK-based company, TravelTime specializes in solving commute duration problems. As we look at Google Maps’ drawbacks, let's see how TravelTime stacks up.

Distance Matrices and Cost

TravelTime has flat monthly or annual billing. At a certain volume of requests, that tips the balance away from Google Maps. The potential drawback here is the rate limits for requests per minute, so the need must be balanced with the budget.

The cost differential can quickly become apparent. If I want to calculate a public transit distance matrix at the census block level, a good-sized city could have 20,000 blocks or more just within range of the transit routes and stops. We'd need to square the number of blocks for the number of elements in the matrix (400 million).

When pricing is in blocks of 1,000 elements, you can see how quickly that adds up. Other options for computing distance matrices exist, but most of them do not have time-aware public transit data available.

Isochrones

TravelTime provides these shapes for us, saving a lot of the distance matrix work (although the matrix is quite useful for other scenarios). These shapes can be calculated for both departure times and arrival times.

Commute Wait Time

Unlike Google Maps, TravelTime includes the wait time in the duration. From my example above, if I'm traveling 30 minutes by bus that arrives 2 hours early, the duration would be 2.5 hours.

Real-World Expectations and Accuracy

An interesting aside: TravelTime's isochrones were almost universally smaller than the Google Maps samples we computed. In other words, particularly for public transit data, Google Maps was more optimistic about how far you could get on a bus within a given duration.

In real-world usage, where we want to give workers realistic estimates of commute times, the odds are against a highly efficient travel experience. It's more likely that things will happen that slow the commute down, so a more conservative route duration makes sense.

Real Application of TravelTime

TravelTime was a much better fit for our original premise and greatly simplified the approach:

Give me an isochrone shape for a commute from a given address.
Then, do some GIS computation to see which points are inside that shape.
If my job records are already in a database with GIS capabilities (e.g., PostGIS), most of my work is done.

Then, on the presentation side, we end up with a high-resolution shape to show the commute area that we can pair with our job points.

We have an isochrone layer on our maps that grades the shapes in shades for 30, 60, or 90-minute patterns. We've also worked on the distance matrix to support searching data within a desired commute range.

Their communication and support have been top-notch throughout the process, and I would recommend their service for commute-mapping needs.

Isochrone comparison, basic shapes - TravelTime on the left, limited approximation from Google Maps on the right

More advanced isochrone shapes with other mapping features

Making the Right Choice for Your Project

For developers building commute-mapping tools, the choice between Google Maps and TravelTime comes down to your specific needs and scale.

Google Maps works fine for simple, low-volume distance calculations, but TravelTime excels when you need realistic commute estimates, especially for public transit users who need accurate commute times.

The ready-made isochrone shapes alone justify TravelTime's use for most commute-mapping projects.

Instead of building complex workarounds to approximate commute areas, you get accurate, time-aware shapes that reflect real transit schedules and wait times.

For manufacturing workers who depend on reliable public transit to get to shift work, that accuracy translates directly into better job matches and more realistic expectations.

If you're building tools to help people find work within their commute range, start with TravelTime. Your users, and your development timeline, will thank you.

Solving TravelTime Coordinate Validation Errors: PBF vs Shapefile Comparison

2025-07-23T00:00:00Z

The solution: When TravelTime API rejects your coordinates for being too far from roads, use OpenStreetMap's PBF files with highway attribute filtering instead of Shapefiles to find the nearest drivable road coordinates.

If you're building mapping applications with TravelTime's catchment area API, you've likely encountered an error where coordinates must be "close to a road."

OpenStreetMap data provides the answer.

By switching from Shapefile format to PBF files and filtering by highway attributes, you can reliably find road-adjacent coordinates that TravelTime accepts, even in remote areas where your original coordinates might be miles from the nearest drivable road.

The Modern Mapping Landscape and TravelTime Coordinates

Geographical mapping is one of those programming domains that used to be hard and required us to reinvent the wheel in a lot of cases. These days, though, so many resources are available.

While using TravelTime to find a catchment area that contains 60-minute commutes from a given location, I found that the service expects origin coordinates to be close to a road.

In other words, we can't drop a pin on the map that's in the middle of a remote area with no road service. Attempting to do so will result in an API error that requests the developer use more suitable coordinates.

But how do we know where the roads are? I'm sure there may be some APIs available in Google Maps or the like, but I opted to solve the problem using OpenStreetMap (OSM) files.

These files are available at many levels from the Geofabrik server: you can download entire countries' worth of road shapes or break the data down to the state level (and sometimes even more granular than that).

The First Attempt: ShapeFile Format

ShapeFile

At first, I used the Shapefile format. This format is easily transformed to GeoJSON, which is easily used in Python.

The trick there is to load the shapes from the file, then use geometry to find the closest point on a road to the target coordinates. That revised point may be very close to the original, or miles away, depending on how the road lies.

For the most part, using the Shapefile source worked. But I ran into a case where the original coordinates were within a national park.

Limitations of ShapeFiles

Hiking trails are among the shapes counted as "roads" of some kind in OSM. I was getting a road point on the hiking trail, but this was not sufficient for using the TravelTime service.

Observation of the Shapefile data showed that it didn’t have any type of qualifier to filter the road selection. Switching to the .osm.pbf files, the other data format available on Geofabrik, yielded better results.

The Solution: PBF Files with Highway Filtering

PBF Files

PBF files are binary files founded on Google protocol buffers. These have more attributes attached to the road shapes than the Shapefiles do, including a "highway" attribute.

While at first glance that piece of data would seem to indicate all of these roads are highways (which in the United States are the primary roads, such as interstates), instead, it is a classifier.

Filtering for Driveable Roads

Using the highway attribute, roads can be filtered to those most likely to be on TravelTime's grid. We can leave off the trails, unpaved roads, and even roads having no classification at all.

For what it's worth, this isn't a 100% solution. While using a better-crafted set of drivable roads helped immensely to cut down the problem cases, not every case was eliminated.

One case I found related to roads on a United States Army reserve, where a sufficiently-classed road was still not good enough. In that case, I had to manually find a close point further away, which resolved the issues for that set of data.

Future Improvements: Automated Validation

In the future, if computing another set of data results in similar issues, we could build a resolving command that makes an API call to TravelTime part of the verification.

Then, if a set of coordinates has proved problematic, drop that road from the filtered set and find the next best match. Rinse and repeat until the API call resolves.

We wouldn't want to do that for every point due to TravelTime rate limits, but the procedure would be much more palatable than manual intervention in each case.

Key Takeaways for Developers

The switch from Shapefiles to PBF files with highway attribute filtering solved most coordinate validation issues with TravelTime's API.

While not 100% perfect, this approach dramatically reduces manual intervention and provides a scalable solution for finding road-adjacent coordinates.

For developers working with location-based APIs that require road proximity, remember that data format choice matters.

The additional metadata in PBF files—particularly the highway classification system—provides the granular control needed to distinguish between actual drivable roads and pedestrian paths or trails that mapping APIs might reject.

Start with PBF files and highway filtering for any project requiring reliable road coordinate mapping. Your future self will thank you when you avoid the debugging rabbit holes that come with insufficient road data classification.

Nonprofit Cloud Outcome Management Objects

2025-05-02T00:00:00Z

One of the greatest advantages of Salesforce’s Nonprofit Cloud compared to Nonprofit Success Pack is outcome management.

Like any organization, outcomes are essential for nonprofits. Your mission is to facilitate change, whether on your street, in your state, or globally. Measuring outcomes helps quantify that change, identify how effective you are at inducing change, and highlight areas that can be improved upon.

If you’re new to outcome management and tracking or to Nonprofit Cloud, this review will be helpful as you consider implementing it in your organization.

What is Outcome Management?

Outcome management for nonprofits focuses on measuring the effect of what they do with the goal of improving their services. This encompasses far more than just tracking inputs and outputs.

Outcome management requires:

Clear, measurable definitions of changes the nonprofit wants to make with defined milestones.
Defining what progress looks like.
Collecting data that evaluates performance and impact.
Analyzing data to understand what is working, what isn’t working, and the areas that need improvement.
Using those insights in strategic decisions, budgets, and improvements.

Nonprofit Cloud Outcome Management Objects

Outcome Management in Nonprofit Cloud is the collection of objects and features that Salesforce offers to streamline reporting and recording outcomes for nonprofits.

Before Nonprofit Cloud, orgs that used NPSP and wanted to track outcomes generally needed custom configuration.

Depending on the measured outcomes and strategy, you could leverage aspects of NPSP’s case and program management to surface some metrics, but you would still need to define and measure outcomes. For example, Terry Cole with Street Youth Ministry reviews how he implemented outcome management in NPSP.

NPC's Outcome Management Data Model

Programs and Benefits

These are the same programs and benefits used in Nonprofit Cloud’s Program Management.
A program is a group of benefits, and benefits are the specific activities in a program that your organization does or offers.

Care Plans and Goal Definitions

Care plans are a comprehensive set of goals over time for a specific individual. Goal Definitions quantify those goals that make up the care plans.

A nonprofit that serves unhoused populations might have various care plans for people who want to find stable housing. A plan could involve goals like applying for short-term housing or identifying community resources.

Outcomes

Outcomes are the changes that your programs and benefits cause. For example, increasing knowledge in a specific area or decreasing the number of children who miss more than two meals per day.

Goals are slightly different than outcomes. Goals relate to achievements, and outcomes are the changes that those achievements create. If a goal for a care plan is to identify community resources, an outcome could be increased knowledge of those resources.

Outcome Activities

This object relates a specific outcome to a specific program, benefit, or goal definition.

Both child and adult wellness programs may have nutrition counseling as a benefit. One outcome of that benefit is increasing knowledge about healthy food.

Two outcome activities would be required, one for the child program (eg, increasing knowledge about healthy food in children) and the other for the adult (increasing knowledge about healthy food in adults).

Defining an outcome activity for nutrition counseling for each program is important to accurately represent all outcomes as they relate to each program or benefit.

Indicator Definitions

Indicator definitions are how you measure whether an outcome has been achieved, such as surveys, assessments, how many donations have been given, or other metrics.

You may have program participants attend a certain number of sessions.

Indicator Assignments

Indicator assignments allow the same definition to be used across outcomes and programs.

A housing-related nonprofit could have a job program and a housing program. Each program has a class, but all classes involve a pre-test and post-test to measure participants’ knowledge and the effect of the class. This indicator, the increase in knowledge, can be related to the respective outcomes for both the job and housing classes.

Indicator Performance Periods and Time Periods

This object defines the interval at which the indicator assignments (the specific measure for a specific outcome) are measured. Indicator performance periods are a specific measure of a specific outcome for a specific time.

You can also define a target and compare the target and result to a defined baseline for that time, like the values for the same month last year or a national or regional average.

If a class is part of a program, you could measure the average increase in scores for each month, quarter, or semester (or another interval that makes sense for the class structure).

Indicator performance periods can also be related to funding award requirements.

The same periods can be used across multiple indicator performance periods, so you get a comprehensive view of all the activities in that timeframe.

Indicator Results

Records either the interim or final results for an indicator performance period (a specific measure for a specific outcome for a specific time). If a flow automatically creates the record, it also records the flow and version that created it.

Benefits of Outcome Management

Tell the Story of Change

Outcome management tells the most important story of your organization: the change you want to make and why it matters. Quantifying and recording outcomes gives concrete evidence of the difference you’re making instead of what you’re offering.

This story is what you tell to other stakeholders, such as donors, granting organizations, and even staff.

Improve Programs

Change management focuses on the results of activities rather than on the activities alone. An effective outcome management strategy should show activities that are doing well and highlight those that need improvement. Data-driven decisions are an essential strategy of thoughtful leadership.

Secure Funding

Donors look for measurable results and organizations that want to improve and expand their services.

Outcome tracking makes it easier to quantify impact when applying for funding, and may even highlight areas that would make the organization eligible for future funding opportunities.

Planning and Accountability

Organizations should pursue accountability and transparency whenever possible, nonprofits included. We are stewards of what is given to us, and outcome tracking demonstrates how organizations steward the resources given to them and the resulting effectiveness.

Clarity and Effectiveness with Outcome Management

Outcome management in Salesforce Nonprofit Cloud represents a significant advancement for nonprofits seeking to measure and improve their impact.

By implementing a comprehensive outcome tracking system, organizations can tell compelling stories of change, make data-informed decisions, secure funding more effectively, and ultimately advance their missions with greater precision and purpose.

Whether you're new to outcome measurement or looking to leverage solutions that will grow with you, Nonprofit Cloud provides the tools needed to track, analyze, and leverage outcome data to grow your organization and drive towards what matters most–fulfilling your mission.

The clarity and effectiveness of outcome-focused management will benefit your organization and the communities you serve for years to come.

Managing Technical Debt in Software Development

2025-05-02T00:00:00Z

(courtesy https://vincentdnl.com/drawing)

The Critical Impact of Technical Debt

Technical debt arises from the sum of all those little decisions that take us away from a 100%-engineered solution.

Every software development project that operates on a timeline and a budget will develop technical debt. Technical debt is not avoidable in the real world, given the constraints we have.

If we focus only on building new features and don't care about resolving technical debt, we are liable to paint ourselves into a proverbial corner. Successful software projects continually work toward paying down technical debt rather than allowing it to build up to a critical mass. Ignoring it will send the project careening toward the edge of a cliff.

When Technical Debt Reaches a Tipping Point

Last year, I managed a project where the client pressed the team to keep adding features, even if they would need to be rebuilt later. The situation was not ideal because they wanted fast development and expected the code to always work. That wasn't a realistic approach, and it quickly built up a lot of technical debt.

In that situation, as a team, we had to take a drastic approach and recommend that we pause feature development entirely for a couple of sprints.

We reached a point where putting out the little technical debt fires every day was choking out our ability to deliver improvements to the project as a whole or to deal with bigger, architectural technical debt on our hands. So we needed to pull the plug for a while and implement a new architecture as the foundation for future development.

What would have prevented a drastic measure like that? Simply building maintenance and resolution of technical debt into the process much earlier. It's alright to put off some necessary aspects of development. But if they are necessary, we can't avoid them forever.

Just like financial debt doesn't go away if you ignore it - and often gets much worse over time - the same is true with technical debt: it has to be paid off at some point.

How to Address Technical Debt

Typically, our approach is to identify key areas of maintenance that need to happen. On many occasions, we can resolve a little bit of existing technical debt as we develop new features. If we are aware of the items that need to be resolved, as a team, we can proactively pay that down wherever possible.

That approach presupposes that we are setting realistic expectations with the stakeholders. Trust helps a lot here. We have to establish that rapport with our clients that we are not unnecessarily inflating the timeline, have the project’s best interest in mind, and are engineering well.

When those items align and a continuous-improvement approach is practiced, ongoing technical debt is minimized. We don't eliminate the need to refactor, but situations that need it should arise from previously unknown information instead of technical debt from previous decisions.

Managing Technical Debt

It's important to note when technical debt happens. Just because a use case isn't in the 80% now, doesn't mean it never will be. And just because we can't or won't take the time now to refactor some architecture doesn't mean it's not a good and prudent idea to do so.

Some software teams may talk about it, then decide it's a future problem and just let it go. When it comes up in the inevitable future, nobody remembers the context, and it becomes an entirely new problem.

It’s much better to document things as they are seen. Track an issue on the project board, even if it is low-priority and not likely to be worked on in the near future.

Next, we have to have some tough conversations with stakeholders about the platform’s trajectory. That's not exciting software development from a business perspective. Often, we don't see visual changes when fixing technical debt, and it can be a difficult value proposition to sell to those paying the bills. But it is necessary.

How Technical Debt Develops in Development

Let's say our Chief Executive Developer reviews code for a major feature. In the review, we see many comments of varying importance to be resolved. He identified some places where the code architecture could be improved.

Given where we are on the timeline for development and when the client wants to launch the feature, we have to decide what gets changed now.

Perhaps we focus on quick wins and hit as many of those out of the review as possible. To not delay the platform launch, we punt on the architecture change. The tests still pass, the QA is going well, and the product "works." It's just not ideally engineered.

That development and decision-making process has introduced technical debt.

The Reality of Development Constraints

Software development always has tradeoffs. We could develop all the features we want in an ideal world with unlimited time and money. But in the real world, with finite time and finite money, we get to set up the project’s building blocks so that we (hopefully) hit all of the must-have features within an acceptable amount of time.

To this end, we often need to look for good 80% solutions that cover the known use cases. That is, we refer to the principle that 80% of outcomes come from 20% of the potential causes, and we apply our efforts to those vital few cases.

As a result, we don't generalize every solution, because doing so would be prohibitive for time and money, and the use cases generally don't exist to justify that expense.

We need to avoid majoring on the minors and get a working product out the door. This reality requires us to make certain assumptions about the use case that are now technical debt.

Transforming Toxic Code Ownership into Team Collaboration

2025-04-30T00:00:00Z

As consultants, we sometimes get a front-row seat to evaluating who sits on the team, if they are sitting in the right seat on the bus to move their organization forward, and if they are the type of member we would want on the team.

Everyone wants to build teams characterized by collaboration, positive contributions, and an iron-sharpening-iron mentality where no single team member is above the constructive criticism of another. This set of principles driving the team remains at the forefront, regardless of the level of seniority.

That's an idealistic viewpoint - the goal, certainly, but many teams do fall short.

On many teams, the reality is, "That's my code; I wrote it, and I don't want other people breaking it." This happens particularly often when a team member over-identifies with some part of the code, a particular tool, a data pipeline, or other aspects of the project. This attitude is evidence of a more toxic code/process/data possession that will not allow the team to move forward.

To address toxic code ownership, team leaders should evaluate and address the environment, facilitate team communication, use well-designed test suites, and implement regular code reviews.

Evaluate the Environment

When that attitude appears, we shouldn't instantly think it’s the problem. Before coming to that conclusion, we need to more holistically evaluate the team, the process, and the code - in other words, the environment.

All things being equal, it's good to hold people to a high standard of character. But if the environment is such that much of the development process is consumed by putting out the various fires that pop up daily, I can understand coming in with a more defensive posture.

When time is already spoken for daily, from the developer's point of view, no time is available to fix problems in established code. Hence, woe be to those who would muck about and potentially introduce problems that the harried developer, as the primary dev for that code, would be responsible for fixing. Touching the code is perceived as a threat.

Some people may bring this attitude even in a more constructive setting. In my experience, the environment can press people in this direction. The wildcard is really what happens when the environment changes. Do they get stuck there? Or can they learn to trust some surrounding changes and lean into a new team dynamic?

How to Eliminate Toxic Code Possession

As a team lead, what can you do to incrementally improve a team toward eliminating toxic code possession? I'd like to focus on three action points:

Communication
Test suites
Regular code reviews

Competence and Communication

Competence should speak for itself, but many development teams don't emphasize communication during hiring. In teams where I have seen toxic possession, the communication factor is missing, and there is most often a single point of failure.

I'm not necessarily talking about soft skills here - really, it's about the developer's ability to efficiently communicate pertinent parts of the code. Can I, as the senior dev, provide a junior dev with some Cliffs Notes on the code's operation?

As that skill pervades the team makeup, there needs to be a place for sharing this kind of information. Sometimes sharing happens during new employee onboarding, but it really should continue past that stage.

How can your team handle the bus factor? What happens if a particular team member gets hit by a bus and is unavailable for an extended period? The team must have enough built-in redundancy to continue.

Building that redundancy is every team member’s job. Toxic code ownership loses its power when more members of the team know how that code/process works.

Test Suites

Teams that exhibit toxic possession have either non-existent or unhelpful test suites that don’t test the right outcomes. When applied consistently and rigorously, test suites are a strong antidote to toxic code possession.

Remember the threat the developer feels when new people come in and mess with the code? Now introduce a well-engineered test suite. If the code breaks, the tests should break and give developers a good idea of where the problem is.

A developer’s fundamental concern walking into a new project is that they don't know what they don't know. The test suite fixes that concern and reduces the likelihood that a problem sneaks through.

Code Reviews

Finally, code reviews are a place to put these concepts together.

When changes are open to review from the rest of the team, there are no "secret sauce" code changes - everybody gets to not only see changes, but discuss them, ask questions, and have general input. Pull requests are a great place to review the tests, make sure the needed new tests are present, and that the team is building that redundancy.

Toxic Possession to Constructive Collaboration

Moving a team from an environment of toxic possession to a more constructive posture takes time and consistent effort. It's worth it, though. Creating an environment where everyone can relax and lean into their strengths will yield healthy pride and satisfaction.

Building UI with AI

2025-04-30T00:00:00Z

For developers who primarily work on backend code, building UI is a necessary evil. Generally, we're not building pixel-perfect renditions of meticulous designs. Instead, we're attempting to efficiently produce a basic flow of operation that feels intuitive and guides the user toward the next steps.

Due to the nature of projects, we won't always need things like modal dialogs in every project. We're not even going to need DOM manipulation in many cases. But when we do, we get to blow the cobwebs off our JavaScript skills.

Over time, I learned to use the AI code generator as my first tool. While the generated code is often imperfect, we can start with a significant chunk of code already fitting the bill by providing some details in the prompt paired with the context the tool observes in the codebase.

Doing this first, followed by revision and refinement, yields a much more efficient programming flow than coming up with all of that code and structure from scratch. In this case, leveraging the AI code generator reduced the development time by at least 50%.

Creating a Modal Dialog to Select and Delete Users

In my latest experiment, I used Augment Code in VSCode to construct a modal dialog flow.

My client needed to be able to select users in a grid view for deletion, with a strong confirmation step on the way. I wanted to apply a select all/none feature, have the modal pop up, and require the user to type a specific bit of text to continue this destructive operation.

Instead of asking Augment for all of the code all at once, I broke that into two basic components:

Select All/None

First, select all/none. I already had a checkbox for each row's selection, so I prompted Augment:

In DOMContentLoaded, I need to add a check box to the top of the first column of the table with the "datagrid" class. When selected, it will be a select-all/select-none for the .check-select boxes in the rows.

Generally, this worked well. I got the structure of the events that needed to be handled, and mostly, it worked correctly.

The AI did not quite suss out how I used the checkbox values to submit a form, but that was an easy revision, causing this to be operational within minutes.

Confirmation Modal with User Input

Next, the confirmation dialog:

When the bulk-action-form gets submitted, we need to have a confirmation step. I want to show a modal dialog that says "This action will remove all of these users' records and cannot be undone. If you would like to continue, type 'permanently delete' into the box below and click Proceed." The modal dialog should have a box for input, and a Proceed button that completes the normal submission of the form.

Now we're getting more specific. The markup for the modal dialog was added to the template, the validation for the text input received some JS code, and the Proceed button was enabled/disabled according to the input validity.

Very usable code came from very little prompting.

Bootstrap Adjustments and UX Details

The template on this project uses the Bootstrap framework. The AI must have gathered from context clues, as it correctly constructed the modal for that layout.

However, I needed the dialog to be at the body-tag level instead of nested well within that view's template. I asked Augment to revise accordingly:

Due to the bootstrap template I'm using, I need the modal dialog to be attached to the body tag.

Some cracks started to show here. The AI's first attempt moved the markup for the modal to JS, making the element completely dynamic. Due to some other details that I was applying later, such as Babel-fueled translations, that would make the code much messier overall.

I called an audible here, moved back to the template markup, and asked Augment Code to simply detach the dialog and attach it to body, which was much more straightforward.

Finally, thinking through what actions should be available on/around the grid when the user is selecting records to remove, I wanted to apply some additional help:

When the bulk-action select has a value, bulk-submit should be enabled (otherwise disabled). Also, a semi-opaque div should be placed to obscure "div.datagrid form.header", so the user can't use those controls until finishing the bulk action (or clearing it).

Both of these were applied successfully without the need for revision.

AI Reduces Development Time

Overall, using these prompts likely cut the development time by 50-60%.

Testing, revision, and refinement remain a time-consuming and integral part of the development process. But having code to start with cuts out the writer's block part of development and takes away some of the "how did I do that before" guesswork.

AI-Driven Library Updates: Modernizing Morphi with Augment Code

2025-04-25T00:00:00Z

We updated our Morphi internationalization library to work with modern Python packaging standards, transitioning from setup.py to pyproject.toml using Augment Code’s chat mode. This approach saved hours of manual configuration work while ensuring our translation tools continue to function smoothly across all our projects.

As a consulting shop, we get to work on many different apps and projects. Most of those, we get to start from scratch - meaning we get to drive the selection of tools and framework. Having a common stack of libraries across the board helps maintain a desired level of efficiency across all of those projects.

One of those libraries is Morphi. It provides packaged internationalization (i18n) services and helpers for libraries and applications.

Morphi abstracts all of the configuration needed for the app, using gettext, setting up Jinja templates, and so on. It also has a CI helper that checks to see if all marked strings have corresponding translations for a locale.

Modernizing Morphi with pyproject.toml

As the Python landscape has shifted from setup.py package setup to pyproject.toml, Morphi has been left behind.

Morphi used setup.py commands to refer to Babel for updating/compiling catalogs. We had an additional command for compiling a JSON file based on the catalog, also set up as a setup.py command.

To bring Morphi into the new era, I wanted to take the same configuration I have had in setup.cfg, move it to pyproject.toml, and update my translation-checking procedure to use it appropriately.

Leveraging AI for the Solution

While that process would have been fine to work through getting all of the CLI options right for pybabel, I supposed that it would have been faster to use some AI code generation.

For my tooling, I'm using Augment Code in VSCode. Augment Code has an agent mode, but I have found it to be inferior to its chat mode for general usage. So, I simply started prompting the chats and allowing Augment Code's gathering of context to assist.

The Prompting Process

For starters, I assumed general ignorance just to see what the bot would propose:

What would I need to change in the Morphi library to run check_translations when a project does not have setup.py? Do the Babel commands work with pyproject.toml?

Immediately, Augment suggested modifying the method so that it would work with either setup.py or pyproject.toml.

This is ideal for a library where we don't want to be very opinionated about how a consuming app is constructed. But it didn't pick up on the idea of putting the Babel config itself in pyproject.toml.

I could see that as a sign to start being ultra-specific about my prompting. But what I've found with Augment Code is that I can continue chatting with low-pressure prompts to guide it toward a desired solution:

I want to use the settings I've defined in pyproject.toml for each step.

Then it figured it out: I wanted identical settings to the ones we used for setup.py. To do this, it generated a solution using the Tomli library to read pyproject.toml and gather the needed configuration.

Handling JSON Compilation

One thing got left out: JSON compilation. This is an extra that Morphi layers over the baseline Babel tools, useful for referring translations to a place where they can easily be used via JavaScript. But Augment Code didn't get the memo on that part, likely because it was not in its context.

To move it forward, I added Morphi’s source code to the context manually in settings then prompted again:

To compile JSON, the Morphi library uses Morphi.messages.frontend:CompileJson.

Again, a simple prompt, and then the bot knew how to fill in the section it had stubbed out for that command.

Testing and Implementation

After setting all of this up, I ran the newly formed check on a project to make sure all of the pieces worked. I didn't really need to make any manual adjustments in this case other than to update Morphi's dependency list with the Tomli library.

Now, we can confidently move our translated apps forward to the new package structure.

You can access our Morphi GitHub repository here.

How Valuable Problems Prevent Valueless Solutions

2025-04-25T00:00:00Z

When given a problem, it’s easy for teams to jump in and start thinking of how to fix it.

But before we think about scope, estimates, features, costs, or rollout, we should ask:

Is the problem valuable?

We usually associate value with worthiness–something is valuable, therefore I must pursue or keep it. Saying a problem is valuable is jarring; we’re trying to fix them, not get more of them.

We tend to value a problem’s solution when we should value the problem itself:

A solution may not show us what caused the problem.
A solution may not prevent the problem from happening again.
A solution may really be valueless.

Valuing the problem instead of the solution leads to valuable solutions and prevents unvaluable ones. This results in better ROIs, better resources spent, and better teams and companies to show for it.

Reframing Value in Problems

Value is not only worthiness, it’s an advantage. Value represents strength, possibility, and priority. Value involves (but often is not restricted to) inherent rank; something is more or less valuable than something else.

When we think of value, we often think of accomplishment rather than potential.

Say you have $10,000. You may decide that you want liquid funds and that money is valuable in a savings account, but what if you want to grow it instead of keeping it? Investing those funds may be more valuable because of what they can do, not just what they are.

Value isn’t static—it’s dynamic. It’s context-driven, forward-looking, and tied to opportunity.

We need to transition from thinking about value as realized, instead considering value as further possibilities and opportunities to grow our teams and companies.

Valuable problems are the ones worth not having anymore.

Defining Value

We can’t fix everything (much to my disappointment). We’re finite people who run finite businesses with finite resources.

We have to decide what problems are worth addressing. Determining what is valuable requires us to ask:

Does the problem exist or even matter?
Does solving this create unnecessary complexity?
Are there more aspects to the problem that we need to consider?
Is there the possibility of tangible benefits rather than just features?
Will this happen again, and when?
Can we devote resources to this?

Valuable problems become filters for focus. Teams can avoid chasing every issue and concentrate on what truly matters.

We can quantify and define value in many aspects, whether financial, practical, or relational. It’s critical to define value from multiple perspectives and not just ours. A need from one perspective may be a want according to another, and vice versa.

Problem or Symptom?

Is the problem a problem or a symptom?

The easiest way to tell if a problem is a problem is if it 1) creates more problems or 2) repeats itself.

You could apply value to both of those attributes. The more valuable a problem, the more additional problems it creates or the more it repeats itself. The application isn’t without nuance. We have to consider the value of the problems that a problem creates as well.

We often work backward from specific problems to determine the root cause. This requires beginning with an accurate understanding of the problem.

We often rush through that process or try to understand the problem while fixing it. Stepping back and getting the full picture with as much context as possible helps define the symptoms and the problem.

Good diagnosis takes time and restraint, but it’s how we stop treating symptoms and start solving systems.

Assessing a Problem’s Value

Fully defining the value for a problem starts with present and future outcomes:

How does fixing this improve the current and future experience?
How does this potential solution contribute to current goals or pave the way for new ones?
What changes will this make outside of us?
Can we start now, keep going, and keep growing?
Will we get more than what we give up?

Often, planning for the present or future is at the expense of the other, however much that expense may be. We can’t have our cake and eat it, too.

Balancing may look different from team to team, project to project, or even iteration to iteration, but what is important is that we continually balance both and refuse to accept one over the other.

Honestly answering these questions in light of the present we have and the future we know now prevents worthless solutions or solutions that ignore the core problem they should address.

Effects of Defining Valuable Problems

Organizational Culture

Plan your team’s execution based on problems rather than features. Every task your team has should relate directly to a problem.

Consistently point out, ask for, and encourage analysis and asking questions. Create problem-focused metrics and KPIs. Praise clarity over speed. Normalize saying, “I don’t know yet.”

This builds a culture where understanding is more important than urgency. Teams that value time use it to define the right work, not do more of the wrong work faster.

Time is Money

Time creates pressure like few other things in an organization. Time represents resources and investment; we can’t make more of it like other resources. It’s even more important to use it wisely.

Would you prefer to take X amount of time to understand the problem deeply and build the right thing?

Or half that time to understand the problem quickly, build the wrong thing, and then do it again for Y number of times until you get it right?

Solution Iteration

Iteration delivers better solutions faster and gives a solution the flexibility to change as problems change. Good iteration must have direction and intent alongside velocity.

When someone asks us to build a tank, we build a roller skate, a skateboard, a sedan, and finally a milk truck–precisely what our client needs (and they’d agree!). Before the first iteration is done, we’re planning the second.

Solving problems often requires iteration because the solutions result in meaningful change. The results are strongly tied to goals and must be intentionally pursued, requiring conscious effort and alignment from everyone involved.

How to Prevent Valueless Solutions

Clarify Goals

Valuable problems clearly relate to organizational goals and have measurable metrics. If we can't tie a solution back to a strategic objective, it may not be worth solving at all.

Look for Patterns

Do problems have the same cause or affect the same thing? Grouping them reveals underlying systems that need focused, deep attention to identify the systemic problem instead of ad-hoc fixes.

Identify Causes and Effects

Causes and effects emerge in the patterns we identify. Understanding these causes and effects will:

Distinguish problems from symptoms and help distill larger issues into manageable chunks
Prioritize what problems affect the most issues and have the potential for the most impact
Avoid solutions that inadvertently create more problems

Creating Valuable Solutions for Valuable Problems

Valuable solutions address the full needs of a valuable problem. The clearer the problem and its value, the more likely we are to create beneficial solutions.

The best problem solvers spend more time understanding the problem, effects, and future potential of its solution before designing it.

Pursue Simplicity and Clarity

Valuable solutions pursue as much simplicity as is practical to meet the problem’s needs. Keeping simplicity in mind allows solutions the flexibility to scale to future needs or to iterate in logical ways that move towards goals rather than fight them.

Solutions also require technical and organizational clarity. Define roles, responsibilities, and assumptions early. Ensure accurate and complete vision transfer. Align stakeholders before sprinting into build mode.

Clarity empowers teams. Simplicity enables scale.

Measure Outcomes and Gather Feedback

Just as defining a valuable problem doesn’t happen in a vacuum, neither does evaluating the solution to that problem.

Valuable problems, when solved with valuable solutions, will always lead to growth.

Evaluating Existing Codebases

2025-04-23T00:00:00Z

"It works most of the time - we just need some updates done here and there.”

"We acquired two programs and want to combine them into one."

Shouldn't be too hard, right? After all, it's just building on what already exists.

As engineers, we don't know what we don't know, and we're allergic to assumptions. We can't start project timelines and estimates until we know the code.

We need to begin by evaluating the existing codebase. The main goal in this assessment phase is to understand the level of effort required for basic development tasks, refine estimates, and identify things that may need done before working on

Benefits of Evaluating Code

Create Realistic Timelines

When we develop our own code based on our common toolchain, we already know how long certain tasks should take.

Something analogous would be booking time at the auto repair shop. If your car needs an alternator, the mechanic can look up the agreed-upon time for changing it and charge for the service accordingly.

Software development always has unforeseen complexity that any estimate needs to account for. However, with enough experience, we can attenuate our estimations to what we've seen with the benefit of hindsight.

We don’t have that experience when we step into new-to-us codebases of unknown origin. Our evaluation intends to determine a coefficient of sorts that we can use to inform our more general estimation process.

Identify Strategic and Necessary Options

Along with aligning shared expectations between our team and clients, our evaluation allows us to recommend specific paths forward with the code.

Not all codebases are created equal. Some are well-engineered, have great structure and tool choices, and do not require much maintenance effort. As you might guess, this is a rare case.

We often find several red flags in other codebases that should be resolved before work can commence on the client's desired features and updates.

Sometimes, a codebase has gone through several teams’ hands before ours, and the mix-and-match of paradigms is evident.

Key Assessment Areas

So, what do I look for when new code crosses my desk? I have three goals:

Understand the general structure and expected tools
Step through parts of the code as if I were performing a code review for someone on my team
Identify any security issues

Architecture and Tools

The general structure is important because if we maintain this code, I need to know how to introduce it to the team member who will primarily work on it.

Fundamental questions all apply here:

What's the language?
Is the language being used well?
What are the steps to start development?
What framework is in use?

Code Quality

The code review step allows me to read a code sample with an eye toward detail.

Most often, we can't review the entire codebase in detail because the time required would be prohibitive. A developer needs to work in the codebase for a while to get a handle on the layout. Depending on the size, getting a good idea of all the pieces could take weeks to months.

We don't have time for that in a time-boxed evaluation, but we can get a general sense of how well-organized the code is.

For example, we can determine if a test suite exists. If it does, does it pass? Looking at a sampling of tests present, do they test what we expect them to test?

Security Vulnerabilities

To round out the assessment, we look for common patterns that would introduce security vulnerabilities. Patterns like SQL injection or cross-site scripting injection can be fairly easy to spot if you know what to look for.

If we don't see anything obvious, we can report to our client that we did that due diligence. That doesn't guarantee the code has no security issues, but we have some confidence that the previous developers thought of it.

The Result: Recommendation

At the end of the evaluation, we meet with the client to review the results. Generally, we can provide some recommendations to move forward well. And we'll have some practical experience to back that up rather than just guesswork.

Python Generators to the Rescue

2025-04-23T00:00:00Z

For one of my projects, I had a Python script generate some GeoJSON data from database records.

Under the original load, the script worked fine, but with an expanded dataset, it became a memory hog and couldn't run to completion on our servers.

Fortunately, I could use a generator function to alleviate the memory issues.

What are Python Generators?

Traditional functions return their results once execution is complete. A generator function returns results as it executes.

You can iterate over the return value of a generator function, processing results as they are produced, rather than waiting for the complete result list to be calculated before iterating.

The Original Approach: A Memory-Intensive Function

The initial version of the GeoJSON-calculating function returned a complete GeoJSON feature collection with thousands of features as a Python dictionary containing a list of features.

That Python dictionary was then converted to JSON and written to a file. With large data volumes, the JSON became too large for the available memory.

Here's a simplified example:

def process_large_dataset(db_connection):
    # Loads entire dataset into memory at once
    all_features = []

    # Query database for records
    cursor = db_connection.cursor()
    cursor.execute("SELECT id, latitude, longitude, name, type FROM locations")

    # Process each record into a GeoJSON feature
    for record in cursor.fetchall():
        feature = {
            'type': 'Feature',
            'geometry': {
                'type': 'Point',
                'coordinates': [record[1], record[2]]  # [longitude, latitude]
            },
            'properties': {
                'id': record[0],
                'name': record[3],
                'location_type': record[4]
            }
        }
        all_features.append(feature)

    # Return complete GeoJSON structure
    return {
        'type': 'FeatureCollection',
        'features': all_features
    }

# Usage - memory intensive approach
geojson_data = process_large_dataset(db_connection)

# Write to file
with open('locations.geojson', 'w') as f:
    json.dump(geojson_data, f)

The Solution: Generator-Based Processing

To fix this, I converted the GeoJSON function into a generator.

The function looped through the relevant database records and generated a GeoJSON feature for each record. Instead of appending that feature to a list, it yielded the individual feature.

Here's a simplified example of the new function:

def generate_geojson_features(db_connection):
    """Generator that yields one GeoJSON feature at a time"""

    # Use server-side cursor for efficient memory usage with large datasets
    cursor = db_connection.cursor(name='server_side_cursor')
    cursor.execute("SELECT id, latitude, longitude, name, type FROM locations")

    # Fetch and yield one record at a time
    for record in cursor:
        yield {
            'type': 'Feature',
            'geometry': {
                'type': 'Point',
                'coordinates': [record[1], record[2]]  # [longitude, latitude]
            },
            'properties': {
                'id': record[0],
                'name': record[3],
                'location_type': record[4]
            }
        }

    # Clean up cursor
    cursor.close()

# Usage with batching to maintain valid GeoJSON structure
def write_geojson_in_batches(db_connection, filename, batch_size=1000):
    """Write GeoJSON file using batched processing to limit memory usage"""

    with open(filename, 'w') as f:
        # Write GeoJSON opening
        f.write('{"type": "FeatureCollection", "features": [\n')

        feature_generator = generate_geojson_features(db_connection)
        first_feature = True

        while True:
            # Process a batch of features
            batch = []
            try:
                for _ in range(batch_size):
                    batch.append(next(feature_generator))
            except StopIteration:
                # No more features to process
                pass

            # If batch is empty, we're done
            if not batch:
                break

            # Write batch to file with proper JSON formatting
            for feature in batch:
                if first_feature:
                    first_feature = False
                else:
                    f.write(',\n')  # Add comma between features

                # Write the individual feature as JSON
                f.write(json.dumps(feature))

            # Clear batch from memory
            batch = None

        # Close the GeoJSON structure
        f.write('\n]}')

# Usage
write_geojson_in_batches(db_connection, 'locations.geojson', batch_size=1000)

Practical Memory Management

The script calling the GeoJSON function would collect a batch of the yielded GeoJSON features and write the batch to a file. Thus, the number of features in memory never exceeded the batch size.

Note that the code to write the GeoJSON file became slightly more complex; however, the reduced memory usage was more than worth it.

Generators for the Win

After this simple optimization, the script could run on our servers without eating all the available memory.

This approach is useful anytime you are working with large data volumes. For instance, scrape 10,000 web pages and feed their content to an LLM. Happy generating!

Nonprofit Cloud Program Management Objects

2025-04-16T00:00:00Z

The objects and data structure of Nonprofit Cloud (NPC)’s Program Management feature are very similar to those in the Program Management Module (PMM).

PMM is a program management package designed for nonprofits that use the Nonprofit Success Pack (NPSP) to track and report on programs, services, and outcomes.

While NPC’s structure is very similar, it also has a few new Program Management objects that improve data tracking and reporting compared to PMM, especially for larger organizations.

Benefit Assignment, Benefit Type, and Program Cohort Member address common challenges faced by nonprofits in monitoring whether benefits actually reach their intended recipients.

This overview will also be helpful for organizations adopting program management in Salesforce’s NPC.

You can find additional guidance for NPC at the Nonprofit Cloud Best Practices Community Asset Hub, as well as a useful guide to map programs and benefits in Nonprofit Cloud.

New Objects in NPC Compared to PMM

NPC introduces a few new objects compared to PMM:

Benefit Assignment
Benefit Type
Program Cohort Member

Benefit Assignments

PMM is a straightforward way to easily track program benefits or outcomes that happened. But what about outcomes that didn’t?

NPC has the advantage of quickly identifying outcomes that should have but have not yet or did not happen.

One major advantage of NPC’s data model is that it tracks assigned or enrolled benefits (services in PMM) to a person or group that have not yet been disbursed or delivered.

This facilitates easy identification and intervention to deliver program benefits to those who need them most.

Benefit Types

Benefit types are categories of benefits that apply across programs. For example, if you offer a financial literacy program and an early childhood education program, “class” could be a benefit type that both programs would use.

Using benefit types and measurements helps you report on the same benefits regardless of the program (eg, classes, distributions).

Program Cohort Members

NPC introduces the Program Cohort Member, an object that better defines the specific cohort membership for a program engagement.

This improves reporting for the cohort in light of the specific memberships rather than the cohort in light of the overall program membership that would be available out of the box in PMM.

A program enrollment (or the specific person enrolled in a program) can be part of many cohorts, and a cohort can have many program enrollments.

NPC Program Management Objects

NPC's Program Management Data Model

Participants

Like PMM, participants can be a person or a group (eg, household). Since people and households are modeled differently in NPC, so are program participants.

Individuals are represented by person accounts, and organizations or households are non-person (or business) Accounts with related contacts. Both types of accounts can be related to a program with a program enrollment record.

Programs

An initiative or group of benefits, similar to PMM.

Benefits

The specific activities of a program that measures what your organization does. Benefits in NPC correspond to Services in PMM.

Program Enrollments

A program enrollment record represents a unique enrollment in a program for a specific person. A person can enroll in multiple programs at various times, and Program Enrollments record when participants start, stop, or re-enroll in a program.

PMM’s equivalent is Program Engagement.

Program Cohorts

Program cohorts group program enrollments to streamline reporting. Cohorts can represent specific locations, timeframes, or cycles.

If you have multiple distribution centers, each center can be a cohort record. Or, if you offer drives or classes in specific timeframes (monthly, quarterly, etc), those can be cohorts.

Benefit Sessions

A planned or scheduled time for benefit delivery. This could be a single class session, a day that a food bank is open, or a scheduled counseling session.

Benefit Assignments

Enrolling a program participant in a specific benefit. These are used especially when program participants don’t automatically receive all benefits of that program or choose not to.

Even if someone is enrolled in a program, you should track their benefit assignments. This is what connects your people and programs to the actual services you deliver that will result in change.

Benefit Disbursements and Benefit Schedules

A benefit disbursement is an individual benefit activity for a person or group.

If your organization distributes funds, food, or other resources, a benefit disbursement would be a dispensation of those funds or resources to a person on a specific date.

If your organization holds classes or events, a benefit disbursement would be a participant’s attendance at a class.

Benefit disbursements can be ad-hoc or recurring and can be tracked in bulk. Benefit schedules help streamline attendance tracking or recurring benefit disbursements for multiple people that you know in advance.

Tracking Programs and Differences

Nonprofit Cloud's Program Management feature builds on the solid foundation established by the Program Management Module, while offering enhanced capabilities for organizations looking to track program outcomes and service delivery with greater precision.

For organizations transitioning from PMM to NPC, understanding these structural similarities and differences will make the migration process smoother. The improved data model allows for more comprehensive reporting and better tracking of participant journeys through your programs, ultimately helping you demonstrate your organization's impact more effectively.

Whether you're implementing program management in Salesforce for the first time or upgrading your existing system, these tools provide the framework needed to track not just what your organization does, but the meaningful difference those services make in your community.

Vibe-Coding an MCP Server

2025-04-16T00:00:00Z

I built a Model Context Protocol (MCP) server that interfaces with Indianapolis's trash pickup website, allowing AI assistants like Claude to look up trash collection schedules with a simple prompt. This demonstrates how MCP can turn everyday web services into AI-accessible tools with minimal coding effort.

Indianapolis has a nice web app for finding your trash pickup day. In addition to the pickup day, it shows your bulk pickup day, your trash provider (which varies based on geography), and the provider's phone number.

Due to undiagnosed issues with mental math, I always forget when the bulk pickup day is for my side of town (it turns out it is the second full week of the month). What better way to serve humanity than to throw GPUs at the problem?

What MCP Is and Why It Matters

Model Context Protocol (MCP) allows AI models to interact with external tools and APIs without requiring users to write custom integration code. MCP makes AI assistants significantly more powerful by performing actions in the real world rather than just providing information.

I decided to write a Model Context Protocol (MCP) server to interface with the indy.gov trash pickup app so I can look up my trash pickup day without the arduous burden of clicking three or four times.

An MCP server is basically an interface that allows LLMs to perform actions without the LLM user needing to write custom code. For example, with only a prompt, you can:

Get your trash pickup day
Create calendar events
Order pizza
Create 3D models

MCP unlocks a lot of exciting possibilities as well as some unique challenges. More on that later.

How I Built It: Maximum Results with Minimal Effort

Because I was creating the server in my spare time, I was determined to write as little code as possible.

I fired up my coding agent Aider and described my specification. After Aider asked for some low-level details, it created a Python implementation for me. Impressive, most impressive.

Since I haven't "embraced the exponentials" enough to run the code without reading it first, I opened the server code in my editor.

Some IDE errors indicated that there was a problem with the MCP library. On closer investigation, Aider had used a random Python library rather than the official Python MCP SDK. However, this was easy enough to fix manually.

Testing and Integration Process

At this point, I wasn't sure how to test that the server was working correctly. Fortunately, the MCP SDK has a command line tool that runs a web GUI where you can poke at your server.

Once I was satisfied it was functional, it was time to integrate with an LLM. After a few false starts, I successfully added the MCP server to Claude Desktop's JSON MCP config file. Now my trash pickup tool shows up in the Claude UI!

My Claude MCP config file:

{
  "mcpServers": {
    "indy_gov": {
      "command": "uv",
      "args": [
        "--directory",
        "<your_downloaded_location>/indy-gov-mcp/",
        "run",
        "server.py"
      ]
    }
  }
}

Note that uv makes it easy to run MCP servers. I wrote another post with 5 uv dependency features developers should know about if you want to learn more about uv.

My server in Claude:

Using the MCP Server with Claude

Next, I asked what my trash pickup day was. Since Claude had access to my trash pickup tool, it knew it could answer.

Based on the MCP server config, it knew to ask for my address. Once I responded with my address, Claude asked me to approve calling the MCP server, with a suitably scary security warning.

Once I clicked allow, Claude handed the MCP server my address and received a JSON response. Finally, it converted the JSON response to human-readable text and responded. I was able to follow up by asking what my next bulk pickup day is (something the indy.gov web app doesn't show).

Notice that even though I ignored Claude’s instructions about address format, Claude was smart enough to pass the correct format to the MCP server.

The Potential, Security, and Implications of MCP

While my use case was rather trivial, I instantly gained an appreciation for the capabilities of MCP. It's easy to imagine MCP servers that can perform a host of actions on my behalf. They could even work in tandem to carry out multi-step actions.

For a thorough deep dive, I recommend Addy Osmani’s post MCP: What It Is and Why It Matters.

A cautionary note: it was clear to me that the security model of MCP is as full of holes as Swiss cheese. For instance, by changing the docstring of my MCP server Python function, I was able to change what data Claude passed to my server.

MCP servers can execute highly privileged code on your system. Malicious servers or even malicious prompts could really ruin your day by hosing your computer or siphoning your bank credentials.

For now, keep a human in the loop and treat MCP-enabled AI tools as a hostile environment. I recommend Simon Willison’s post Model Context Protocol has prompt injection security problems for further reading.

Conclusion and Resources

Ultimately, I’m sure the security and usability issues will be mitigated, though not eliminated, over time. With judicious usage, MCP servers will soon become an essential part of your AI toolbox.

You can access the GitHub repo for the trash pickup MCP server. Use at your own risk.

AI Agent-Driven Development with Augment Code

2025-04-11T00:00:00Z

I have been skeptical of code generators. Of course, I used to be skeptical of code formatters, but I ended up embracing them wholeheartedly. Typically, we are not a first-adopter team - we let others go through the process of finding pain points and reap the benefits later on. Now that AI coding agents are much more common and gaining popularity, I decided it was time to try one out.

For my tooling, I've been using Augment Code as a context-aware chat solution in VS Code, so I decided to try out Augment Agent.

I found that Augment Agent had significant productivity benefits by generating functional code structures quickly, but was limited in pattern recognition, code organization, and testing, highlighting that they serve better as accelerators for human developers rather than replacements.

Building a Weighted Calculation Comparison

The platform is a calculator, and the user's profile are the inputs. Depending on the profile, the calculator produces results for a number of items, which are combined in a single result. The items are weighted, so the output can be adjusted by changing the weights. My client wanted a way to see a comparison of different weights.

My initial prompt is below:

I need to add a new feature. We'll start with a grid report of users with their profile fields. Selecting a user will bring up a form to select two Parameter records by their label. The first Parameter record should default to the current is_primary record. Submitting the form will calculate non-live CalculationResult records, then go to a view to display the results side-by-side.

The agent spent a while "thinking" after the prompt to look at different pieces of code context. This is in contrast to Augment Code's Chat mode, which seems to provide more instantaneous results even when applying changes to multiple places in the code. That said, this was a bigger ask to have it generate more pieces by itself.

The immediate results were quite promising. With one prompt, I had the structure of a grid view for user profiles, a form for selecting calculation parameters, views to use these with needed permissions applied, and the Jinja templates to tie up the UX. It even added a navigation link for me.

Addressing Limitations

The results, though decent, didn’t work right away. I decided to dive into each piece in turn and evaluate what was happening.

For all of the criticisms, bear in mind that the agent essentially developed a 70% solution, which is a huge productivity boost.

For the grid, I added some prompting to make the agent adjust the existing columns, add new columns, and correct some query conditions. This type of specific update was handled acceptably.
Commonly-used mixins in the project were not applied to the form and views.
I would have thought that in all of the context-gathering that happened at the beginning, the agent would intuit the usage of those mixins and base classes.

I didn't take the time to prompt again to see if it would adjust itself in this case. At a certain point, it's just easier to make the changes myself.
No tests present.
That's not too noteworthy in itself, as this was not something I requested in my prompt. But as a developer, it's informative to see the agent’s assumptions for what we want generated.

I wonder if, as agents get smarter, they will begin to build a developer profile for who they're working with and learn that testing needs to be a first-class citizen in each framework (even if we don't explicitly ask for it each time).
Code duplication in the Jinja templates
Pieces of the template were the same markup, just shown for different score results. I want to see that wrapped up in a macro to deduplicate, but the agent is quite happy to generate the same code over and over again instead of factoring the common pieces.

When working with the agent and prompting it to adjust the templates, it could easily handle that duplication. The agent doesn't care if I'm asking it to change one instance or a hundred.

This type of shortcoming highlights how code would easily become needlessly complex if the agent were left to its own devices. In this instance, I manually adjusted it again. But I want to try a prompt at some point to see if it will correct its duplication.

The bottom line is that the results were actually better than I anticipated for a tool of this kind. The output is certainly not production-ready (or even working in some cases).

In some ways, the agent is like having a junior-level developer who can code some things but doesn't care to test whether the code works. Then, the rest of the process is something like code review.

AI-Assisted Development

The productivity boost is undeniable—even with its flaws, the agent delivered a substantial portion of the feature in record time. What would have taken much longer was condensed into minutes of prompting and refinement.

That said, these tools aren't replacing developers anytime soon. They're more like eager apprentices who need supervision and guidance. The agent lacks the judgment to make architectural decisions, fails to follow established patterns without explicit instruction, and seems to have no concept of maintainability or technical debt.

For now, I'll use AI agents as accelerators rather than replacements—letting them handle the 70% that they can while I focus on the nuanced 30% that makes code truly production-ready. As these tools evolve, I expect they'll become increasingly indispensable, even to skeptics like me.

When is Continuous Deployment (CD) Needed?

2025-04-11T00:00:00Z

When building a project spec from scratch, one of the items that often gets left off the list is deployment. The spec misses it, estimates miss it, and many project teams don't even discuss it until it's time to do it.

A well-thought-out deployment process must be one of the primary checklist items for the project planning process.

The question, though, is what kind of deployment process? Options range in scale, repeatability, complexity, and reliability.

The usefulness of a scripted deployment pipeline is well-established. Sure, Joe Coder could connect to a server and run all the steps manually from a checklist. However, that type of operation is error-prone due to the human factor. It's not automated, it does not repeat well, and deployments will typically take longer to complete (if/when done correctly).

So we want a pipeline, but how complex does it need to be? And does the pipeline need to reach full maturity right away?

Those are good questions, and the answers depend on the project goals.

Complexity

Often, when starting a custom software development project from scratch, we want quick iterations and rapid deployments. The goal at that stage of the project is to have a tight feedback loop between the development team and the project stakeholders.

In contrast, I've worked with teams that consider full continuous deployment (CD) as a basic piece of the process. Load up Kubernetes right away, prepare for that scale right away, and set up that pipeline very early in the project.

Is that the best place to spend developer effort early in a project? Or is it better to have a simple, established deployment pipeline that just requires a developer to start a script and then scale up to CD later on?

During the part of the project lifecycle that benefits from quick iterations and quick deployments, waiting for CD pipelines can stifle a fast response to issues and bugs. Fully containerized deployments, in my experience, can take a while for building a container to complete.

Scale Limitations

As the solution grows and takes shape, we have to consider scale limitations. Having a developer fire off an Ansible (or similar) script to deploy will get the solution very far down the road to completion, but we become limited in our deployment targets.

If the solution scales up to need a fully containerized solution that uses Kubernetes or something similar, that's one of the signs that the platform is "growing up" to the point that it will require development resources focused on that process.

Early in platform development, the developers have very little context at that stage for what may eventually be required:

What will the constraints be?
What kinds of tasks need to run periodically?
What will be the actual scale that needs support? These are all questions that point toward optimizations needed.

We do not want to prematurely optimize when those circumstances are unknown. Allow the usage scale to determine when it is best to make the switch to a more distributed architecture.

Nonprofit Cloud Fundraising Objects

2025-04-09T00:00:00Z

Nonprofit Cloud (NPC) uses several objects in addition to Opportunities to track gifts pledged and given, receipt of those gifts, designations, and influence for donations. These include:

Gift Commitments
Gift Transactions
Gift Designations
Gift Soft Credits
Gift Refunds
Donor Gift Summaries
Gift Batches

Nonprofit Success Pack (NPSP) relied on Opportunity to track every kind of revenue, whether received or pledged. NPC separates these types of donations in its data model.

Reporting on received vs. projected is more straightforward, but getting a complete financial picture means accounting for multiple objects.

Another consideration is that you could run into the “where is my data?” issue or have the extra mental overhead of where to track what kind of donations and when.

Defining a clear process and expectations and leveraging Salesforce features to make the user experience easier can help alleviate those mental gymnastics.

NPC’s fundraising objects can serve the right organization and help make reporting and planning easier, but the data model may be too complex for others.

Why Not Opportunities?

While NPSP tracked gifts using only the Opportunity object, it hasn’t gone away in NPC! Understanding received, projected, and pursuing revenue will help distinguish when to use what object.

NPC intends that Opportunities represent gifts that staff are actively working to land, especially grant funds or other significant donations. If you’re familiar with the lead/contact distinction, you can consider Opportunities as the “lead” of your revenue process.

Your organization has defined a clear objective (such as a $10,000 grant award or a $5,000 donation to a gala) and is actively cultivating relationships with the donor to receive that donation.

Once someone commits to giving (but hasn’t given yet), that Opportunity would turn into a Gift Commitment, then a Gift Transaction(s) is entered once your organization receives the donation.

A Closed/Won Opportunity isn’t a donation in Nonprofit Cloud - it means that the specific source being pursued either has a Gift Commitment or a Gift Transaction. Your team should be on the same page as to what should happen when an Opportunity is Closed/Won.

Using Opportunities allows staff to focus on intentionally pursuing larger donations or sources of revenue and gives a clear view of the pipeline in the works versus received or promised upcoming gifts.

NPC Fundraising Objects

NPC's Fundraising Data Model

Gift Commitments

A donor’s committed (but not yet received) funds. These can be commitments from a person or organization and related to a campaign or schedule. Commitments can be time-based or open-ended (defined by the Gift Commitment Schedule).

Also indicates how the commitment will be fulfilled if applicable, such as a trust, insurance, or other annuity/fund.

Gift Transactions

A received donation and payment information, or what would have been a Closed/Won Opportunity in NPSP. These can be optionally related to a specific campaign, gift commitment, and gift commitment schedule.

A gift transaction can be related to a matching employer gift outside of using soft credits.

Gift Designations

A specific category that donors can indicate they want their donation to go towards. Gift Designation records include several valuable rollup metrics, such as total transaction amount, current year amount, and last year amount.

Gift Designations are not the same as Campaigns. Campaigns represent a concerted effort to influence a group of people in some way. This could be marketing-related and usually is, but it doesn’t have to be (for example, recruiting).

Gift Designations tell your organization what the donation should go towards. This could be the same thing as a Campaign or a subcategory and may be accounting-related.

A Campaign may be a hunger drive, while a donor could specify that their gift be used for administrative overhead or leadership development.

Gift Refunds

While we’d love never needing this, Gift Refunds represent both partial and complete refunds of donations.

Entering a Gift Refund adjusts the Current Amount and Refunded Amount on its related Gift Transaction.

Salesforce automatically updates the Gift Transaction’s status to Fully Refunded if the Gift Refund is for the full amount.

Gift Soft Credits

Like NPSP, soft credits indicate that a person or an organization has influenced a donation. They didn’t give that particular donation directly, but they played a part in making it happen.

For example, if a company donates to your organization because of a board member, the board member would receive a soft credit.

As in NPSP, soft credits are very flexible. Soft credits can be either a percentage or dollar amount, and like NPSP, the totals for a donation can exceed the original donation amount.

One important limitation - soft credits can only relate to Accounts out of the box, including Person Accounts. If a Contact isn’t a Person Account, additional configuration will be needed.

Donor Gift Summaries

In NPSP, opportunity rollups were on the Account/Household or Contact record. NPC moves these amounts to Donor Gift Summaries.

Donor Gift Summaries alone do not report on totals for a specific group of people (eg, household) but offer all the metrics in NPSP.

Donor Gift Summaries offer an additional scoring feature to grade or categorize donors on donation recency, funds, and frequency.

Gift Batches

Gift Batches are NPC’s version of NPSP’s Gift Entry. Gift Batches allows you to enter gifts all at once and rely on Salesforce to process them into their respective records:

Gift Transaction
Gift Designation
Soft Credit
Accounts/Contacts/Person Accounts

Gift Batches processes and shows the details and status of the entered gift batch. Like NPSP, you can perform a dry run to catch and resolve any errors or discrepancies before processing the gifts.

Implementing Fundraising

Nonprofit Cloud's fundraising data model represents a significant shift from NPSP's opportunity-focused approach

By separating donations into distinct objects—Gift Commitments, Gift Transactions, Gift Designations, and others—NPC offers greater precision in tracking and reporting.

This architecture provides a clearer distinction between received and projected revenue but requires users to navigate multiple objects to get a complete financial picture.

The key to success with NPC lies in thoughtful implementation. Organizations should establish well-defined processes for when to use Opportunities versus Gift Commitments, create clear user guidelines, and leverage Salesforce's customization capabilities to streamline the experience.

While the more complex data model might feel overwhelming initially, the potential benefits in reporting accuracy and fundraising strategy can make it worthwhile for many nonprofits.

Ultimately, your organization's specific needs and capacity will determine whether NPC's sophisticated fundraising objects are the right fit.

Organizations with complex fundraising operations and dedicated Salesforce administrators may find tremendous value in the granular control NPC provides, while smaller teams might prefer NPSP's more straightforward approach.

Either way, understanding these fundamental differences will help you make an informed decision about your Salesforce nonprofit solution.

Benefits of Type Hints in Python

2025-04-09T00:00:00Z

Python code can be annotated with type hints that indicate the intended data type of a variable or function. Here's an example:

class Message:
    def send(self, text: str, recipients: list[str]) -> bool:
        try:
            messaging_service.send(text, recipients)
            return True
        except MessageSendError:
            return False

We see that the Message.send method expects text, which should be a string, and recipients, which should be a list of strings. The send method returns a boolean value to indicate success or failure.

Type hints have several benefits:

Help prevent errors caused by mismatched data types
Document usage for other developers
Enhance code editor functionality
Help AI understand your code

Over the years maintaining Python code, I've seen a lot of type-related errors appear in deployed systems. Usually, they are easy enough to fix, but type hints combined with running a type checker would have caught these problems before they shipped.

Since not all of the libraries I regularly work with have full support for types, I don't validate types for an entire project. Rather, I run the type checker in my editor for instant feedback.

When working with unfamiliar code, it is never fun to see a function with a signature like def update_address(self, address):. Is the address a string? A dict? An object? While I can determine the answer from reading the code, I'd rather not have to mentally execute code (sometimes several layers deep) to know how to call a function.

When type hints are used appropriately, they boost the efficiency of your editor. You can hover over a function call and see its signature. You can jump to the definition of an object or function with a keypress. Readability and efficiency matter since code is read more often than it is written.

Another editor benefit is refactoring. If you rename an attribute of a class using an LSP, it will only rename usages of that attribute if the usage is typed. An example clarifies:

# Refactor name -> full_name
class Person:
    name: str

# Untyped. This function will not automatically be refactored to use person.full_name
def set_name(person, name):
    person.name = name

# Typed. This function will automatically be refactored to use person.full_name
def set_name(person: Person, name: str):
    person.name = name

Additionally, static types can make it easier for AI coding tools to understand your code, and by extension, to generate more-correct code. For example, if a function argument has a type annotation, an AI tool can use RAG to locate the type definition and add it to its context automatically.

Given the benefits for developers, it makes sense to add type hints to a codebase where feasible.

Pair Programming in Developer Onboarding

2025-04-04T00:00:00Z

Turning a newly hired developer into a fully efficient, contributing team member requires a concerted effort.

Your new employee needs to be introduced to the codebase, brought up to speed on the project management workflow, receive code reviews for continual improvement, and weigh in on other people's code reviews to build a voice on the team–all an investment in the employee's career and work with your company.

As team leads, our first instinct can be to rush through all of those steps as quickly as possible to get a return on the hiring investment sooner than later. But, as with many team operations, sometimes we need to slow down to speed up.

One final aspect of onboarding that contributes to quality code and efficiency is pair programming.

Pair programming is valuable for the new hire and the team as a whole, but it does raise some considerations when managing your team members and their contributions to the team and the project as a whole.

Benefits and Value

Even when accounting for variance in team member makeup, we can establish a culture in which pair programming brings value to new hires for a few reasons:

The new employee gets face-to-face time with other team members.

This allows for organic team growth, establishes camaraderie with the new member's involvement, and builds a bedrock of shared experience.
The new hire doesn't know what they don't know about the code.

Getting up to speed will take some time. We ask them to drink from the firehose when introducing the codebase, but building experience by doing increases confidence quickly.
Pairing a more senior-level developer with a new hire will increase the team's code IQ level.

The senior dev can help introduce concepts like architecture, testing, or frameworks that wouldn't normally come up in team conversations, thus orienting the new dev to the team’s coding culture.

For pairing to be the most valuable to the new hire, they need to drive the session, not the more senior dev.

While that can feel intimidating, the new dev must get a feel for making code decisions in that codebase. The senior may need some coaching to understand that pair programming is a team confidence-builder.

Considerations

Personality Differences

Pair programming can be a touchy subject. Some developers enjoy pairing all the time, but others feel like it slows them down intolerably.

While we might be tempted to pigeonhole the latter category as "not a team player," we would be better positioned to respect and understand personality differences.

Resistance to Criticism

What if a developer doesn’t accept criticism of their code? Ideally, that should have been addressed specifically in the hiring process.

If you have reached the onboarding stage only to find this out for the first time, you'll need to watch the team’s dynamic closely.

Balancing Team Profitability and Satisfaction

If your company bills by the hour, trading time for money, you're not going to win popularity contests with clients by doubling the bill.

Conversely, you can only eat so much unbillable time before the profitability of the new hire just doesn't make sense. How useful pair programming is in general depends on the team's constraints and balancing billable versus unbillable time.

Along with that, the more senior dev will likely feel like they're wasting their time, even if they're sold on the pairing concept. They'd rather be developing some of the more esoteric parts of the application, enjoying the challenge of harder problems to solve.

I use time-boxed pairing on my teams so that it's not all-consuming. We can have a new hire pair with a more experienced team member for 2-3 hours daily with great results.

We allow that to continue for the first week, then discuss with everyone involved to get a sense of how it's going and what value may be had from continuing.

Balance in Onboarding

Pair programming is just one tool in a comprehensive onboarding strategy, but it's powerful when implemented thoughtfully. As with most team dynamics, the key is finding the right balance.

By creating structured, time-boxed pairing sessions rather than open-ended commitments, we acknowledge its inherent value and limitations.

Short, daily sessions for a limited time benefit the team through knowledge transfer, relationship building, and code quality improvements while staying the potential drawbacks of decreased billable hours and developer frustration.

Each new hire brings their own learning style, personality, and expertise to the table. The most successful onboarding experiences allow for individual differences rather than forcing a one-size-fits-all approach.

Successful onboarding doesn’t rush to maximum productivity but instead lays a foundation for long-term success. Investing thoughtfully in onboarding practices builds better code and a stronger, more cohesive, and ultimately more productive team.

The short-term investment of time yields long-term dividends in code quality, team cohesion, and developer satisfaction. Indeed, sometimes you need to slow down to speed up.

AI in Business: Hype vs. Reality

2025-04-04T00:00:00Z

In today's rapidly evolving technological landscape, businesses face a critical choice: embrace artificial intelligence or risk falling behind competitors. At a recent lunch and learn session, Caleb shared practical insights on how businesses can overcome AI uncertainty and start implementing effective AI solutions.

The AI Adoption Dilemma

Many business professionals find themselves stuck on "the fence" of AI adoption. On one side lies the fear of falling behind competitors already leveraging AI. On the other side looms uncertainty about implementation: where to start, what tools to use, and whether catching up is even possible.

This hesitation is understandable. Simply scrolling through LinkedIn reveals an overwhelming and often contradictory flood of AI content. The message seems to be: "Your business will keel over and die by the end of the year if you don't start making huge investments in AI right now."

Understanding AI: Beyond the Hype

To move forward with AI adoption, business leaders need a clearer understanding of what AI actually is and what it can do:

Generative AI: AI that creates original content such as text, audio, and video
Foundation Models: Unspecialized AI trained on large amounts of data (like ChatGPT)
Large Language Models (LLMs): Foundation models focused specifically on text-based tasks
Retrieval Augmented Generation (RAG): Allows AI to retrieve additional information from databases or the internet
AI Agents: AI that can act autonomously given a mission and tools

What AI Can Do for Your Business

AI capabilities fall into two major categories: enhancing automated workflows and augmenting human workers.

Enhancing Automated Workflows

AI can perform previously impossible tasks with superhuman speed and flexibility. Some real-world applications we’ve seen in our projects include:

Automated inspections: Using drones and AI to detect machine damage requiring repairs
Processing unstructured data: Analyzing over 100,000 job listings to extract salary, benefits, and other key information
Conversational impersonation: Creating AI that can mimic an expert's opinions and communication style based on their content

Augmenting Human Workers

Beyond automation, AI can make individuals more effective by expanding their knowledge base and processing power:

Strategic decision-making: Using AI to identify cognitive biases and suggest alternative solutions
Breaking down complex tasks: Converting vague client requirements into specific development tasks
Coding assistance: This allows developers to focus on design and architecture rather than syntax

AI's Limitations and Risks

Despite its power, AI has important limitations that businesses must recognize:

It's not truly human: AI lacks understanding of what it says and may state falsehoods convincingly
Limited creativity: Though it generates original content, it's based on training data, not true creativity
No emotion or conscience: AI follows its training without ethical judgment

Additional constraints include:

Dependency on training data: AI can't know what it hasn't been trained on
Prompt effectiveness: AI doesn't understand implicit context or your business's specifics

Businesses must also address risks including:

Privacy concerns: Some AI models train on data you provide, potentially making private information public
Reliability issues: AI can produce inconsistent or incorrect results
Misinformation: AI can state falsehoods confidently
Overreliance: Depending too heavily on AI can create vulnerabilities

How to Start Adopting AI Today

The session provided a clear roadmap for businesses ready to move beyond uncertainty:

Start small: Create a ChatGPT or Claude account and begin experimenting
Identify opportunities: Look for bottlenecks in your business processes
Research solutions: Consult reputable sources, not just social media
Create a formal plan: Establish clear objectives and implementation steps
Iterate: Continuously evaluate and improve your AI implementation

Moving Forward

The next step is clear: be excited about AI, not anxious. By adopting AI thoughtfully, businesses can automate routine tasks and focus human talent on unique value creation. This allows teams to be both happier and more productive.

AI is certainly a strength if it is used well. It can be a weakness if it is not used well. By understanding AI's capabilities and limitations, businesses can confidently step off the fence and benefit from this transformative technology.

Bulk Updating Large Volumes of Records in Salesforce

2025-04-02T00:00:00Z

When working with Salesforce, there are times when you need to update a large volume of records. Doing this manually can be time-consuming and prone to errors. Using anonymous Apex directly quickly runs into governor limits.

Fortunately, Salesforce provides tools like Batch Jobs to help you handle bulk updates efficiently, ensuring you stay within governor limits and avoid performance issues.

One of the most common ways to perform bulk updates is by using the Database.Batchable interface in Apex. This allows you to break the update process into smaller chunks, processing records in batches.

Each batch processes a defined number of records (e.g., 200 records per batch), reducing the risk of hitting limits like the total number of records updated in a single transaction.

Here’s how you can use Apex to update records in bulk:

Create a Batch Class: You define a batch class by implementing Database.Batchable<SObject>. The start method selects the records, the execute method updates the records, and the finish method can be used for any post-processing tasks.
Run the Batch in Anonymous Apex: After creating your batch class, you can execute it in the Salesforce Developer Console using Anonymous Apex. This runs the batch asynchronously, so it doesn’t block the user interface.

Example code for initiating a batch that updates 200 records at a time:

Database.executeBatch(new YourBatchClass(), 200);

Here’s a sample batch job for updating Account records:

public class AccountUpdateBatch implements Database.Batchable<SObject> {

    // Start method that defines the query to select Accounts
    // Add any filters here to the query.
    public Database.QueryLocator start(Database.BatchableContext BC) {
        return Database.getQueryLocator('SELECT Id, Name FROM Account WHERE Name != null');
    }
    // Execute method that processes each batch of records
    // Modify this to alter the Account records as desired
    public void execute(Database.BatchableContext BC, List<Account> scope) {
        for (Account acc : scope) {
            acc.Name = acc.Name + ' - Updated'; // Example: appending "- Updated" to the Account Name
        }
        update scope;
    }

    // Finish method to handle post-processing if necessary
    public void finish(Database.BatchableContext BC) {
        System.debug('Batch Process Completed');
    }
}

Note: Salesforce will not allow you to add or remove Apex directly on production. You’ll have to install and remove this code using CLI tools, change sets, or some other deployment method. It may also affect your test coverage, which would prevent deployment.

Using this approach ensures that you can handle large updates efficiently while respecting Salesforce's limits and ensuring minimal impact on system performance.

It’s a good practice to test this on a full sandbox and to make data backups before running it on production. When manipulating large volumes of data in this way there is the possibility that you can make a mess of your data.

You should also inspect your organization and understand the implications of updating these records - are there triggers or flows that will run?

As always, code responsibly.

AI Analysis of a Web Page

2025-04-02T00:00:00Z

AI can help when a project needs to analyze a number of web pages for information.

Recently, we had a project that needed to take an arbitrary web page (provided as input) and attempt to extract job listing information.

Without AI, we would consider that an intractable problem for a limited budget. It might be doable if we were focused on a single site, as long as the site's layout remained consistent. But supporting any number of layouts and content distributions?

Enter the LLM.

In this case, we're using OpenAI's platform API, and that service doesn't fetch the page contents for you. It would be nice if it did, but we need to perform that step ourselves.

That's not all bad, though, because we can take the opportunity to strip out some tags that may confuse the results. Script, style, iframe, navigation, and any forms all need to go.

The rest of the content can be passed on in a prompt after being chunked for length. When chunking HTML, we need to be aware of what tag we're in, so if the chunk isn't big enough for the complete tag, we can break it down and give it a closing tag.

OpenAI has a feature that allows us to pass a Pydantic model to make better sense of the model's results and give us a structured output. For each chunk, we can get an object that has the potential title, description, date, relevant links, and other information on the page as needed.

After all of the chunks are run, we simply need to combine the description contents, then we can run the full record through any needed ensuing processes.

Parallelization of Link Checking

2025-03-28T00:00:00Z

Sometimes, the most effective optimization is understanding and working with the existing system's constraints instead of adding more resources. Scaling software infrastructure doesn’t mean finding the most complex solution; rather, it requires finding the most pragmatic one.

One of our projects has a component that is essentially a link aggregator. For all of the links being tracked, we need to periodically check to see if they are no longer active. As an opening approach to be scaled up, we initially settled on updating link status once a week.

That's not to say that we run a single, giant process to refresh every link at, say, midnight on Saturday. Given the number of links being tracked, that would be prohibitive. Instead, we refresh throughout the week, grabbing a set every few minutes to be the next block performed.

Scale must happen, whether in the size of the set or the frequency of the action. In this case, we wanted to shift our weekly check to a daily process, meaning our links get checked seven times more often.

Given the number of links being tracked and the queue burn-down rate in the weekly check, this would require a more robust approach.

We have a queue for stacking up links that need to be checked. We're already doing some parallel action by having multiple processes grab tasks from that queue. So, we have a few options for the approach to scale this up.

Three Options

First, we could simply increase the number of processes.

But server resources are finite, so that means either provisioning a server with more memory to support the number of app instances required or provision a fleet of smaller instances. There is a more cost-effective way to do this.

Second, we could pivot to a different queuing mechanism and move the link checking to a functional component, like a lambda. Then, we could scale up as many as needed.

As an approach, this is valid and would solve a long-term projected concern. But the scale at which this would be necessary is far off.

This means the multidimensional effort (infrastructure, developing/testing the lambda, etc.) would be a hefty investment at this phase. This certainly deserves future consideration, but there's a more cost-effective and less labor-intensive way to accomplish what we need now.

So, I settled on option three: parallelize the parallel processes.

Parallelization Considerations

The fact is, every time we check a link, we lose a lot of cycles to the network latency. The key bottleneck when it comes to checking links is the network. That's an I/O problem, not CPU-bound, which would require scaling up the hardware.

Given the I/O bind on the problem, we can process a batch task rather than a single link at a time in one of our processes, spin up threads to accommodate several links at a time, and just wait for completions on all of them.

When our queuing process runs every few minutes, we can create one or more batches of links to be run in parallel in one of our background tasks. Give each batch an identifier, like a UUID, record that on the links to be checked in the batch, and then queue a task with that identifier.

We do need to plan for the potential of something breaking. In other words, if something goes sideways in the link-checking task and our links don't get their batch ID cleared, how do they get requeued?

We'll also need to track when a link has been batched. A second task can simply clear any stale batches after a few hours, freeing the links to be queued for review once again.

Results

In my testing, I saw that running a batch of links in parallel on a single process eliminated 80% or more of the runtime.

That's 80% per process, of which there are several, so we have saved well more than enough to accomplish our 7x addition of queue throughput.

Now, our process can happily run a daily refresh on the full set while having significant room to scale before more complex approaches are necessary.

Scaling as a Solution

By implementing batch processing with parallel threads, we transformed a potential scaling challenge into an elegant solution.

We achieved a significant performance improvement—reducing runtime by 80% per process—without resorting to expensive infrastructure changes or complex architectural redesigns.

This method embodies a core principle of efficient software engineering: solve the immediate problem with the least friction while keeping future scalability in mind. Our solution provides immediate benefits and leaves ample runway for future enhancements.

Sometimes, the smartest optimization is the one that works now, scales incrementally, and doesn't prematurely complicate your infrastructure.

Code Reviews in Developer Onboarding

2025-03-28T00:00:00Z

Bringing a new developer onto the team is a multiphasic process that builds on hiring. We don't just sign the employment contract and drop the new person into the mix. Instead, we need to continually build a team development environment and culture in which a new member can quickly thrive.

Once we have communicated the essentials of the codebase and the team's common workflow, our new developer needs to start writing code.

Typically, it’s prudent to assign some low-hanging fruit - smaller issues related to a specific place in an app that need brief, focused attention.

It's not the time to discuss major architectural issues or far-sweeping refactors. Those can come later as our nascent developer builds their mind map of the code.

But how do we maintain a high level of code quality when a new team member is unfamiliar with our common patterns?

That's where code reviews come in.

Code review should be part of your team culture, but it is especially important during the onboarding and ramp-up phases. It’s a time to exhibit radical candor, enforce consistency, and be open to feedback yourself.

When your new hire posts a pull request, that's the time to hold the line on code quality, architecture, testing, awareness of vulnerabilities, and everything else that comprises our concept of worthy software.

Radical Candor

Code review is a wonderful time to employ radical candor. We need to call out things that need improvement quickly and concisely.

Done correctly, this is not a time to count positives and negatives and ensure they come out even. Reviews should be as objective as possible and unforgiving of things that could compromise an app's foundation.

That's not to say we should become one of the notoriously acerbic developers who use personal attacks and caustic responses to bully their points. Quite the opposite: quality code can quickly become messy.

The desire to maintain good code and architecture should be the driving force to focus on the code and keep the personal out of it. The goal of feedback is to demonstrate the standard and hold the bar high for the new developer to shine.

Make your new hire aware during onboarding that their early code reviews will be verbose: "Don't take it personally. Everyone gets that here."

Consistency

The more consistent the review process and feedback are during onboarding, the more comfortable a developer will be to hold to the standard themselves. What is acceptable cannot be a moving target.

For example, if we call out the separation of model and view code once but accept a PR later that combines them, we send the message that we either don't care or aren't paying attention.

Be Open to Feedback

Code review goes both ways, too. We have a lot of input on the new hire's reviews, but we should also be open to input ourselves. To that end, expose other team members' PRs to the newcomer's input.

This accomplishes two purposes for the benefit of the team. First, the less-experienced developer (in this codebase) gets an idea of the improvements needed and how one of the more-experienced developers proposes to do so. Second, our new hire gets to develop a voice on the team.

Future Onboardings

Doing this review process consistently and maintaining code quality will pay off in future onboardings.

As we bring other new developers onto the team later, will we take pride in how we did it this time? Or did we cut corners in hopes of just adding capacity to get things done faster? If the latter, we'll have some egg on our face when we introduce someone to the code next time.

A Culture of Code Reviews

Ultimately, onboarding a new developer is an investment in both individual and team growth. Instead of creating a gauntlet of criticism, we build a collaborative environment where all developers understand, respect, and collectively maintain high standards.

The code review process is a quality control mechanism and a cultural touchstone that communicates your team's values, expectations, and commitment to excellence.

By approaching each new team member with radical candor, maintaining consistent feedback, and creating opportunities for two-way communication, onboarding becomes less of a mere administrative task and more of a strategic opportunity. We cultivate a shared understanding of what makes great software and a team that continually elevates its craft.

Every line of code reviewed, every piece of feedback given, and every collaborative moment shapes not just the current project but the future of your team's technical excellence.

Migrating from NPSP to NPC

2025-03-21T00:00:00Z

If your organization currently uses NPSP, you may wonder whether to migrate to NPC.

Before diving into the process, it’s important to note that moving to NPC isn’t an immediate necessity. The decision depends on various factors, including your organization’s size, goals, and capacity to handle the transition.

For those who have decided to migrate, this guide provides an overview of key considerations and a high-level process to help ensure a smoother transition.

Since each migration will vary based on your existing org structure, data, and NPC’s evolving features, a thorough planning phase is essential.

Before You Begin

Salesforce will most likely provision an entirely new org rather than modify the current org. This has implications for data and metadata transfer.

If you used a trial org to do any configuration work that you want to move to the provisioned org, that won’t transfer automatically. If needed, you can package custom work you’ve done in a trial org and migrate that to the new org.

If you receive free licenses under the Power of Us program for NPSP, you’ll have to work with Salesforce to transfer that discount to your new org.

Plan

"In preparing for battle, I have always found that plans are useless but planning is indispensable." ― Dwight D. Eisenhower

Audit… Well, Everything

Take the time to go over everything in your organization with a fine tooth comb. Take inventory of everything and decide what should transfer, what shouldn’t, or what needs to change.

If you haven’t already, determine the number of users and types of licenses you’ll need. Map old license types and their features to new ones and determine who needs those licenses.

If you have users with a platform license, determine what kind of license they’ll need once you migrate. This may also involve some permission and sharing work.

Custom Work

Pay particular attention to any custom or added configurations and determine whether those should migrate. These include:

Apps, Lightning Pages, and other UI
Automation - process builders, workflow rules, flows, and Apex
Data - custom objects/fields, validation rules, list views, reports, and dashboards
UI/UX - lightning pages, page layouts, buttons/actions, LWC,
Productivity - email templates, files, notes, and attachments
Other - Experience sites, custom metadata

It’s easy for stuff to accumulate and be forgotten about, so it may be worth working with a partner to identify what exists in your org and whether it should be moved.

If you are, ask if they can give you an overview of metadata in your org to review easily.

Implement Best Practices

Move existing workflow rules or process builders to flows if they still support your business processes.

Use Lightning Web Components instead of Visualforce pages where possible for more efficient rendering and performance.

Take the time to review profiles and user personas and map those to NPC permission sets, including custom permissions.

Implementing best practices often involves technical debt. Migration is a natural time to review the org and clean up technical debt that may have accumulated over the years or as Salesforce has updated.

Like decluttering a closet, cleaning up technical debt helps the org run smoother and reduces future time and money spent on maintenance or feature development.

Clean & Backup Data

In addition to technical debt, this is a fantastic time to clean up your data.

Deduplicate records, consider deleting or archiving old records, and ensure all required data exists and data is as up-to-date as possible. Stepping into a new org with clean data is remarkably energizing.

Back up your data regularly during cleaning and migration, especially before and after significant edits or moving data.

Data Mapping

As part of your planning process, map each original object and field to the new ones. This helps:

Show discrepancies between field types and data types and if data needs to be reformatted before import.
Plan the data import process.
Highlight what custom object-and field-level customizations need to be built.

If data won’t transfer to its corresponding field in NPC, consider reformatting if possible, saving it in a custom field, or archiving it.

Salesforce’s entity relationship diagrams or NPC developer documentation are helpful (even if you aren’t a developer!). They review all standard objects and fields, their purpose, types, and other details.

The Nonprofit Cloud Best Practices Group has helpful resources for orgs looking to implement NPC, especially NPSP to NPC translations and data mapping resources.

Onboarding

Create a plan to test a buildout, refine as needed, and onboard your team into the new org. Find “super users” that can help you test and give you good feedback.

You may want to build out specific operational areas and then onboard those respective teams so that you aren’t onboarding everyone all at once. For example, donor processing first, then donor management and development, then programs.

Migration Process

Salesforce recommends the following order for migrating data. This is largely informed by the standard data model.

Migration needs and order depend on what your org currently uses. The order of custom objects will depend on the kind of their relationships with other objects.

Overall, the operational order for migration is as follows:

People, Organizations, Groups, and Households
Addresses
Campaigns
Fundraising
Tasks & Events - Replace Engagement Plans with Action Plans
Program Management
Case Management
Outcome Management
Grantmaking/Budget Management

Fundraising

Accounts, then Contacts - Person Accounts and new data model for groups
Campaigns
Gift Commitments and Gift Designations
Gift Default Designations
Gift Commitment Schedules
Payment Instruments
Outreach Summaries
Outreach Source Codes
Gift Transactions - NPC doesn’t allow $0 Gift Transactions
Gift Transaction Designations - NPC requires an amount and percentage on a Gift Transaction Designation
Gift Refunds, Gift Tributes, Gift Soft Credits, and Donor Gift Summaries

Action Plans

Action Plan Templates, Template Versions, Template Items, and Template Item Values
Action Plans
Action Plan Items
Document Checklist Items and Tasks

Program Management

Migrate Organizations, People, and Households - Person Accounts and new data model for groups
Migrate Programs
Program Cohorts and Benefits
Benefit Schedules
Program Enrollments and Benefit Sessions
Program Cohort Members
Benefit Assignments
Benefit Schedule Assignments and Benefit Disbursements
Recurrence Schedule

Case Management

Migrate Organizations, People, and Households - Person Accounts and new data model for groups
Public Complaints
Cases
Referrals and Case Participants
Interaction Summaries, Complaint Participants, and Complaint Cases

Outcome Management

Programs, Benefits, Goal Definitions, and Impact Strategies
Outcomes and Time Periods
Outcome Activities
Impact Strategy Assignments
Indicator Definitions
Indicator Assignments
Indicator Performance Periods
Indicator Results

Households and Group Memberships

Migrating group and household membership objects can happen anytime after accounts, contacts, and person accounts. These objects include:

Party Relationship Group
Party Role Relationship
Account Contact Relationship
Account Account Relationship
Contact Contact Relationship

Conclusion

Migrating from NPSP to NPC is a significant undertaking that requires careful planning and execution. By auditing your org, optimizing data and processes, and following Salesforce’s recommended migration steps, you can ensure a smoother transition.

While the process may seem daunting, leveraging best practices and working with experts when necessary will help your organization make the most of NPC’s enhanced capabilities.

Taking the time to plan and clean up your org now will pay dividends in the long run, ensuring your nonprofit can continue to operate efficiently and effectively on Salesforce’s evolving platform.

Process Enforcement in Developer Onboarding

2025-03-21T00:00:00Z

The hiring process does not end with employing a new developer, introducing the codebase, then saying, "Have at it!" Bringing new developers onto a project to a place of full efficiency takes time and effort.

A clear, well-documented process ensures that new team members integrate smoothly, minimizing confusion and inefficiencies. Yet, many development teams lack a standardized workflow, leading to unnecessary friction.

To set developers up for success, we need to eliminate guesswork and enforce a streamlined, predictable system from day one.

Define the Process

Every development team ought to have an established process for getting work done. This will include documenting the work that should be accomplished and tracking that work item through the various status changes of its lifecycle.

Document for Efficiency

The team needs to know at a glance what is done, what is being done, and what is yet to be started. Hopefully that process is well-documented for your team, and everybody is on the same page for how to proceed.

That said, in working with many development teams, I have found this to be the exception rather than the norm.

Inevitably, efficiency gets lost in asking what to do next when a process doesn’t exist or isn’t well established. Then we bring a new developer into the mix, and who's to tell them how to track their issues through to completion?

Don’t Make Them Think

In the UX world, the principle for the user interface is, "Don't make me think." The same is true for issue workflow.

Many developers are naturally process-oriented - that is, they tend to want to follow a procedure and will get frustrated when it doesn’t work or doesn’t exist.

They don't want to have to think through what an issue-tracking process should be. They just want to move the issue to the next stage and grab their next item from the queue.

We want to walk new developers through a sane, simple workflow process that everyone on the team follows. The process shouldn’t have a lot of moving parts if we want our developers to reach peak efficiency.

Enforce the Process

Enforcing the process means we call out deviances in that process–for example, when an issue is in the wrong status, the wrong person is assigned, or keywords aren't properly in the PR.

There is a time and place for team leads to “go along to get along.” But if we let the process go and hope that it will all resolve over time, each developer on the team will develop a separate set of habits, meaning we've lost the single process. Encourage them to ask questions as needed on the process, but ensure the procedure is followed correctly.

The time to establish this in the onboarding process is right away. As soon as you’ve introduced the code, assign a few issues to the developer so they can get their feet wet in both the code and the workflow. Typically, these are small issues that will be low-hanging fruit and a confidence-builder.

If something is wrong, ask the developer to fix it instead to be on the same page. The temptation is always there to just fix it yourself. After all, dragging the issue to the right place on the board is faster.

But your developer will not notice the change. This short-circuits the multiplication factor we try to achieve by having everyone in the same process.

Process for Productivity

An efficient development team thrives on a consistent, well-enforced process. By documenting workflows, minimizing complexity, and ensuring every team member follows the same system, we remove barriers to productivity.

Enforcing these habits early in a developer’s onboarding experience helps them ramp up quickly and reinforces best practices for the entire team.

Getting work done isn’t the only goal. We want to build a scalable, repeatable process that keeps developers focused on what they do best: writing great code.

Connecting AWS VPCs for SSH Access

2025-03-19T00:00:00Z

Picture this: you have a nice, shiny Terraform setup that modularizes an entire environment. Each deployed environment has its own network space, so we don't cross-contaminate resources. With your EC2 instances running the web apps, you generated supporting files from live data.

You would like to push those files to the EC2 quickly. “No problem,” you think “I'll just scp them from one to the other.” But the VPCs are separate, the networking is all separate, and nothing connects them.

There are a few ways to resolve this problem. One way is to use an S3 bucket, sync the files from the production server, and then pull them on the other instances.

If your instance hasn't been set up for those commands, this option will require several steps in addition to the S3 bucket terraform: install AWS CLI, configure credentials, etc.

Or, we can proceed with our original idea of SCP. The fundamental issue is the lack of connection between the VPCs. We can solve this with a peering connection, which can be configured in Terraform. Once the VPCs are peered, define routes to direct the traffic from each CIDR block to the other.

We want to be careful here to keep access control tight. We will allow the production server to have SSH access to the non-production instance, but not vice versa.

Production could still get a file from beta if needed, but the process must be instigated from the production instance. We don't want a rogue process on beta to have any potential of performing an action on another deployed environment.

Altogether, the terraform is fairly simple, as below. Your modularized environments will need to provide outputs for the VPC involved, the routing table, and the security groups used for access.

resource "aws_vpc_peering_connection" "vpc_peering_beta" {  
  vpc_id        = module.environment_prod.vpc_id  
  peer_vpc_id  = module.environment_beta.vpc_id  
  auto_accept  = true  
}  
resource "aws_vpc_peering_connection_accepter" "accept_peering_beta" {  
  vpc_peering_connection_id = aws_vpc_peering_connection.vpc_peering_beta.id  
  auto_accept              = true  
}  
resource "aws_route" "prod_to_beta" {  
  route_table_id        = module.environment_prod.public_route_table  
  destination_cidr_block = "10.125.32.0/20"  
  vpc_peering_connection_id = aws_vpc_peering_connection.vpc_peering_beta.id  
}  
resource "aws_route" "beta_to_prod" {  
  route_table_id        = module.environment_beta.public_route_table  
  destination_cidr_block = "10.135.40.0/22"  
  vpc_peering_connection_id = aws_vpc_peering_connection.vpc_peering_beta.id  
}  
resource "aws_security_group_rule" "allow_ssh_from_allow_all_out_beta" {  
  type        = "ingress"  
  from_port  = 22  
  to_port    = 22  
  protocol    = "tcp"  
  security_group_id = module.environment_beta.ssh_in_sg_id  
  source_security_group_id = module.environment_prod.allow_all_out_sg_id  
}

5 Things to Consider when Adopting or Migrating to NPSP/NPC

2025-03-19T00:00:00Z

When considering whether to adopt Salesforce's Nonprofit Cloud (NPC) or Nonprofit Success Pack (NPSP) or migrate from NPSP to NPC, several key factors should be evaluated.

Within the differences between the various platforms, key things to consider include your current solution or workflow, other priorities, and your team, timeline, and budget. The right choice depends on your current setup, long-term vision, and available resources.

This guide outlines some major considerations to help you make an informed decision that will serve your organization.

Why NPSP and NPC?

NPSP and NPC are designed for different types of organizations. NPSP is valuable for smaller, less complex orgs, while NPC is geared for larger nonprofits or nonprofits that want to scale and expand.

We outline some technical differences in our post on NPC vs. NPSP. These differentiators include workflow and operational areas, data models, automation, permissions, reports, and compatibility with third-party apps.

The rest of this guide will focus on five organizational considerations that are worth thinking through as you look to implement or migrate to NPSP/NPC.

1. Current Solution/Workflow

A large part of deciding what solution to use involves analyzing what you currently have.

If you have NPSP and are considering NPC, why? What problems would NPC solve? What would NPC support in the future that NPSP can’t?

If you don’t have a Salesforce-based solution, what about the platform would make life easier? Do you want to integrate data, report on it, or analyze it? What workflows or processes would it support or automate?

Part of auditing what you currently use is any custom work done either in Salesforce or your current solution.

It’s worth considering migrating that custom work, how it would subsequently look or function, if it shouldn’t be migrated, or if a process needs revising instead of migration.

2. Priorities

Evaluating priorities for any business initiative encompasses the priorities that the initiative supports and adjacent priorities separate from the project.

Does implementing or moving to a new platform provide tangible benefits? Can you quantify the impact that a new solution will bring?

It’s essential to be specific. Rather than a generic goal (for example, “updating a system”), a solution should have concrete benefits that address real needs in your organization.

Would other priorities need to be rearranged or deprioritized? Would this be temporary and time-bound or should they be deprioritized indefinitely? Can your organization still accomplish the necessary priorities alongside this new project?

3. Team

Accurately evaluate your team’s abilities and resources before starting a migration or implementation. If they don’t have the skillset to accomplish it, consider augmenting the team or adjusting the project.

Also ensure you have the right people on the project. They should be competent, clear communicators, give effective feedback, and see the project through to the end. Enlist a variety of roles, from corporate sponsor to power users and everyone in between.

You may enlist an external team to supplement the project. A partner can be a valuable knowledge source, help with implementation and configuration, and save time.

However, using a partner requires the investment of time and budget. Finding and vetting a partner that can give you a good return on that investment can take time.

4. Timeline

Given your unique organizational needs, how long do you expect the migration or implementation to take? How long should it take?

Be sure you’re factoring adequate time for discovery, building, testing, refinement, and data migration (which is a good time to consider fixing your bad data!).

Consider the timing and whether it should be planned further in advance. Especially if you’re considering NPC at the end of your fiscal year or during an event-focused or initiative-focused season, like a yearly fundraising event, the timing should align with organizational goals.

5. Budget

While budget is a critical facet of the discussion, it should come after the considerations listed above. If those aren’t in place, the budget will inevitably be negatively affected.

Nonprofits can get ten free licenses for either NPSP or NPC. If you need additional licenses, NPC will be more expensive than those for NPSP.

You will also need to determine if you will need more licenses. Unlike NPSP, platform (or “lightning platform”) licenses aren’t available in NPC. You’ll most likely need to grant those users a full license instead.

If you use a partner to help implement or migrate your Salesforce instance, they will need to build in time for discovery, building, testing, and possibly data import. Moving processes to Salesforce as part of the implementation or migration will also require time.

Making the Choice

Choosing a Salesforce tool for your nonprofit is a strategic and technical decision. Carefully evaluating your current workflows, priorities, team capabilities, timeline, and budget ensures a smoother transition and better long-term outcomes.

While both platforms offer powerful nonprofit management tools, the best solution is the one that aligns with your organization's needs today and where you want to go in the future.

NPC vs. NPSP — Which to Choose?

2025-03-14T00:00:00Z

Choosing the right Salesforce solution for your nonprofit is a critical decision that impacts operations, fundraising, and long-term sustainability.

With the introduction of Nonprofit Cloud (NPC) in 2023, organizations now face a choice between the long-standing Nonprofit Success Pack (NPSP) and this newer, more robust platform.

While both options offer powerful tools tailored to nonprofit needs, their structures, costs, and functionalities differ significantly.

Understanding these differences can help your organization determine which solution aligns best with your mission, budget, and growth plans.

Once you decide to migrate, thorough planning is essential.

What are NPSP and NPC?

NPSP was released as a “starter pack” in 2008 that grew within the nonprofit community, especially smaller organizations. NPSP is a free package designed to be installed over a standard Salesforce cloud (usually Sales). It's easy to implement and helps smaller orgs hit the ground running faster.

Salesforce introduced Nonprofit Cloud in 2023 as a standalone cloud rather than an installed package. It’s part of their Industry clouds that offer more advanced, robust features.

NPC’s goal was to better align with other specialized industry solutions that Salesforce offers and leverage the features in those solutions specifically for the nonprofit sector. Instead of just focusing on fundraising, NPC measures a nonprofit’s impact in activities and outcomes.

Differences Between NPSP and NPC

Cost

With the Power of Us program, nonprofits can receive 10 free licenses and discounted additional licenses. NPSP is a relatively low-cost option, outside of ongoing maintenance and development.

The licensing cost for NPC is higher than it is for Sales Cloud + NPSP, but certain editions of Nonprofit Cloud also qualify for the Power of Us program.

Operational Areas and Functionality

NPSP is centered around fundraising. Nonprofits can use other free and paid packages on an a-la-carte basis to extend Salesforce’s functionality to match their mission.

These include Volunteers for Salesforce (V4S) for volunteer management, Outbound Funds Module for award and grant disbursing, and Program Management Module for program delivery.

These will continue to be supported, but most likely will not receive any new features or development. Like NPSP, some of these are open source and may receive future community backing.

Nonprofit Cloud bundles fund, program, case, and grant management into one cloud. While this supports an integrated system, it may be too many features and thus result in technical debt for some orgs.

As of March 2025, Nonprofit Cloud doesn’t include volunteer management out of the box and may not fully support the V4S package. Core functionality should arrive later this year, but even then may not be a fully fleshed-out solution.

Future Development

Salesforce will focus all new development and features for nonprofits on NPC.

NPSP will continue to function, but it won’t receive any new features outside of features for the cloud it’s built on (usually Sales Cloud). However, NPSP is an open-source solution and might get sponsorship in the future.

Data Model

NPSP is very flexible and has a simple data model. Once installed, it needs relatively little configuration. Since it’s a package, most objects NPSP uses are custom objects.

NPC uses a more sophisticated and complex data model to serve larger nonprofits. It’s a more scalable solution for organizations looking to expand.

Since NPC is a dedicated cloud, all objects are standard. Because it’s a more all-encompassing solution, NPC also includes many objects that aren’t in Sales Cloud or NPSP, such as Care Plans for individuals and Benefits associated with programming.

Inherent in complexity differences are differences in the user experience. Key areas include modeling gifts/fundraising and how NPC models people, households, and groups. At a minimum, you should test NPC compared to NPSP and see how the data model works for real-life scenarios.

Permissions

NPSP includes profiles as part of its package. These profiles were designed as the only configuration users needed to access NPSP objects and features.

NPC favors the permission set-forward model and uses only permission sets and permission set licenses to grant access.

While baseline configurations still require profiles, a Salesforce best practice is to use permission sets to manage user access to apps and objects. Permission sets support a more modular, flexible approach to user permissions to grant users only their needed permissions.

Managing access via profiles within a packaged solution alongside a permission-set based model introduces complexity in org administration, eventually costing time and money.

Automation

NPSP uses apex classes/triggers and workflow rules to automate field syncing, rollups, record creation, and other critical processes. Even with deprecating workflow rules, the automations in NPSP will continue to be supported and work.

NPC relies on flows and other features in the other Industry clouds for automation. The features include Business Rules Engine, Data Processing Engine, and Omnistudio.

These are very helpful for automating complex workflows, especially across multiple departments, and can reduce the need for extensive custom code.

Reports

NPSP includes many common-scenario reports and dashboards that are a helpful starting point for reporting.

Some reports and dashboards that come as part of NPSP include:

Organizations and households that donated last year but not this year
Opportunities by type, accounting allocation, and fiscal year
Contacts with giving total summaries
Four dashboards that cover giving trends, campaign ROI, and forecasting based on open opportunities

NPC doesn’t include any report types out of the box, and creating custom report types can be difficult due to the complexity of the data model.

Some objects can’t be included in custom report types yet, although may be in future releases. NPC also uses many polymorphic fields across the case and program management objects that can’t be included in report types.

Third-Party Apps

Many third-party integrations support the NPSP data model, as it’s been in the ecosystem the longest compared to NPC.

NPC may not yet support the integrations you need. The number of supported apps is consistently growing, but developing and releasing a package takes a long time.

If specific integrations are critical to your organization, ensure the cloud you plan to use supports them.

Making the Choice Between NPSP and NPC

Ultimately, choosing between NPSP and NPC depends on your organization’s size, budget, and operational complexity.

NPSP remains a cost-effective, flexible solution that supports fundraising and integrates well with existing third-party apps, making it an excellent choice for smaller nonprofits.

On the other hand, NPC offers a more comprehensive, scalable system designed to measure impact beyond fundraising, though it comes with higher costs and a steeper learning curve.

As Salesforce continues to develop NPC while maintaining NPSP with limited updates, nonprofits should carefully evaluate their current and future needs before transitioning.

How to Fix Bad Data

2025-03-12T00:00:00Z

In our post on the cost of bad data, we explored how inconsistencies, errors, and outdated information can lead to wasted time, lost revenue, and poor decision-making. But what exactly causes these data issues in the first place?

Data inconsistencies don’t appear out of thin air. They often stem from manual entry errors, outdated records, siloed teams, and a lack of clear standards.

Without addressing these root causes, any attempt to clean up data will be temporary at best.

Fixing bad data involves knowing common data inaccuracies, auditing your data, defining quality, cleaning your data, and prioritizing data cleanliness.

In this post, we’ll break down typical sources of data inconsistencies and explore practical ways to identify, clean, and prevent data cruft from accumulating.

Causes of Data Inconsistencies

Manual Entry and No Standards

Manual entry is probably the cause of most inconsistencies in your data. When data entry is tedious or leaves the user to format the data, users are less likely to enter data at all.

Lack of conventions or standards contribute to this as well. While users still need to execute them, expectations are guard rails that define what kind of data is expected and when data should be collected or entered.

It’s worth examining processes and working with teams to determine what data is needed versus what is assumed as necessary. Team feedback is also invaluable in uncovering friction while collecting data.

Outdated Data

If you aren’t regularly getting the most up-to-date data, you risk outdated reports, dashboards, and analytics. Business decisions depend on context, and leaving out data means missing valuable insights and experience from your data.

Data requirements can change over time, so it’s prudent to go back and fill in data if needed. For example, a company decides that every opportunity in a particular stage should have certain company information.

This is easy to implement for new opportunities, but what about old ones? It may be helpful to go back, even within a specific timeframe such as a fiscal quarter or year, and ensure existing records meet that criteria.

Lack of Sharing

Teams that need the same data but can’t access the same data will inevitably contribute to poor data hygiene. Information collected by one team about a particular set of clients could be completely different from the same information about the same clients collected by another team.

Integrating data across teams and implementing a process to resolve inconsistencies encountered by different teams reduces duplicate data and contributes to accurate data.

On the other hand, integrations can also contribute to data inconsistencies. An integration may be a one-way sync when it should be two-way. A mismatch between the data format and validation could lead to missing, incorrect, or duplicate data. Essential data may not be synced at all.

How to Identify and Clean Bad Data

1. Know Common Pain Points

Data can take multiple formats. An address could be “123 E. Main St.,” 123 East Main, 123 East Main Street, 123 Main St E, for example (or any combination of the above). Phone numbers can have dashes, parentheses, or no delimiter at all.

Data can be inaccurate, incomplete, or have slightly different variations. Decide whether to delete or update incorrect or obsolete data.

Examine business processes to see where to implement and automate data validation. Good candidates include processes like client support interactions, automating address formatting according to USPS standards, or verifying new addresses against the national change of address (NCOA) database.

2. Audit Data Quality

Run tools that scan for missing values, outliers, or atypical or inconsistent data. Asking for feedback from employees or users also helps identify discrepancies.

Compare data across systems to check for discrepancies–for example, if a product catalog in the CRM used for sales doesn’t match the catalog used in the warehouse.

It’s essential to audit the data as it defines the scope and timeline of the cleanup. Good planning is critical to cleaning up the data while not losing sight of other business priorities.

3. Define Data Quality

Once you know what data shouldn’t look like, define what it should look like. All goals should be measurable, and good data is no different.

Clearly outline standards for good data. For example:

How often should data be updated?
Does the data comply with predefined standards? How much?
How many records are correct?
How many fields are missing in a database?
Should record formatting be uniform?

4. Clean Bad Data

Deduplicate and merge data

Automated tools can help identify and alert to duplicate entries, if not automatically merging them.

Unique ids, such as an account number or client ID, can prevent data duplication and ensure data accuracy.
Standardize entry

Use predefined dropdown fields where possible. This reduces the manual effort to input data and keeps data consistent.

Where predefined choices aren’t possible, use uniform naming conventions and data validation rules to enforce consistency. Again, think in terms of preexisting and future data.
Fill in data

Use data from other systems to fill in missing fields, or use a third-party system if possible. Regularly ask users to update their data at specific intervals or times.
Remove obsolete and inaccurate data

Data removal should be governed first by external benchmarks or requirements. Many industries require data to be kept for a certain time.To meet those requirements, records may be automatically deleted or scheduled for a regular review.

Archiving data may be a more appropriate solution or only surfacing older data to those who consistently need it.
Implement data governance

Create clear guidelines for data storage, entry, and validation. These should be company-wide, specific to each department, and tailored to how those departments store and interact with the data to achieve their goals.

Create metrics that measure data quality informed by company goals. Data goals should correlate to company goals, otherwise you’re collecting data just to have data.

5. Prevent Bad Data

Automated Data Quality Checks

This should happen in real time as much as possible. The goal is to reduce friction in formatting data and finding duplicate records.

Using automated features or AI to alert users to duplicate records saves time and manual effort. Surfacing potential duplicate records makes it easy for users to update existing records if applicable.

Automated tools and workflows can also format and clean data. Validation or processes can check for prerequisite data and enforce subsequent data consistency. For example, to require certain documents when creating a record, implement a custom workflow to create the record and require uploading documents simultaneously.
Employee Training

Teach employees the effect of bad data and to value and rely on data as much as the leadership team. Data exists to help them do better at their jobs. Ongoing training should include data entry and management.
Integrated/Sync Systems or Fix Existing Integrations

Reduce manual effort and ensure all business systems (CRM, ERP, finance, marketing) share the same data. Regularly reconcile any discrepancies and consider what information should be shared.
Establish a Schedule

Consider monthly or quarterly mini-audits. It takes less time and is easier to catch issues rather than cleaning up data in longer intervals.

How to Prioritize Good Data

Establish expectations and procedures - implement clear expectations and procedures for data entry, validation, and maintenance.
Invest in automation and/or AI - reduce human errors and reallocate finite resources by leveraging technology.
Steward data from the top down - empower teams to own data quality. Data is everyone’s responsibility, from the CEO to the bottom of the organizational chart.
Audit and maintain data regularly - rather than limited efforts to clean up data, data cleanliness and cleaning should be a regular priority.

Data that Works

Bad data is fundamentally a business problem. If data exists but isn’t reliable, it’s not truly working for your company.

By identifying the causes of data inconsistencies and implementing proactive strategies—such as standardizing entry, automating quality checks, and fostering a company-wide culture of data stewardship—you can transform your data from a liability into an asset.

Cleaning up bad data is an ongoing process, not a one-time fix. With the correct governance, automation, and team buy-in, your business can ensure that data remains accurate, consistent, and valuable.

Designing Flexible Spreadsheet Uploads with AI

2025-03-12T00:00:00Z

For a long time, we've had a common paradigm for our views that expect spreadsheet/CSV file uploads.

The view template provides a definitive list of the expected columns. Each column has a specific header expected to be present in the sheet and a description of what that column should contain. A downloadable template file gives your users somewhere to start formatting data appropriately for upload.

More technical users will understand why that structure is important. Computers are dumb - they don't understand files unless given specific instructions on how to process and analyze them.

Less technical users will find friction because we've just introduced more work. Why can't the computer handle any upload I give it? Sure, one or two details are a little bit different, but it has the information needed.

Why not leverage what large language models (LLMs) do well to make our upload expectations more flexible?

While LLMs aren’t suited for analyzing data, they can be useful in providing structured data outputs and help streamline user experience.

Can LLMs Improve File Uploads?

Here's the case I was working with: a client wanted external users to be able to upload a spreadsheet containing addresses. Regardless of other information in the sheet, we wanted to pin those addresses on a map.

If you’re a developer, your mind is filled immediately with all the ways this can break. What are the address columns named? Does the sheet have one address column or more than one column? If more than one, what order are the columns in?

Curious whether the premise would work, I set about testing it in the most direct way possible: upload the file to ChatGPT and prompt the LLM to provide a structured address output in response.

And what did I find out? Well, not to put too fine a point on it, but ChatGPT is terrible at analyzing files, no matter how specific my prompt became.

Sometimes I got a perfectly valid response, but it wasn't repeatable. I received the expected output in one out of every four attempts at best.

Now, if I'm doing a manual prompt in the chat interface and then evaluating results, this can be encouraging - I can have some reason to retry prompts that didn't work the first time.

From an application automation perspective, though, one out of four is a terrible rate. How would I find signal out of the noise and know which response was correct? What if the response only included some records but not all?

It's not hard to imagine why the LLM doesn't work well with this use case. The LLM is a language model that generates predictive text. It doesn't know how to read files. It does have coding tools it can use, though, if it generates the code.

So ChatGPT writes some code to open and read the file, to varying degrees of success. Then with that layer of indirection, it applies my original prompt to try to mine the data for specific information.

A New Approach: Read Data Before Prompting

Admitting defeat on that tack, I tried a different one. I can't generalize the supported file types too broadly. But if I'm limited to XLSX and CSV, I have the tools to read those in my wheelhouse.

Instead, maybe we can read the file’s data ourselves, then drop the CSV directly into the chat completion prompt. This removes the indirection, takes control of the file handling, and allows the LLM to do what it does best: natural language processing.

Of course, we have context limits to deal with. Our code can't just embed an arbitrarily-sized file's contents into a single prompt. We need to go one step further and chunk the data into batches that will fit in the window.

What did I learn from this tactic? This method achieves a much higher success rate - close to 100%. I found this to be true even if the columns were scrambled.

I thought perhaps the column headers were giving the LLM better context, so I tried a run without any column headings at all. Surprise, surprise - it still gave me valid results.

Enhancing UX with AI-Assisted Uploads

These tactics will only apply to a limited set of use cases. Let's not start uploading a month's worth of financial information this way and expect it to work for complex analysis. But where the opportunity exists, we can leverage AI tools to make the UX smoother.

How to Introduce Code in Developer Onboarding

2025-03-11T00:00:00Z

Good news - you've completed your extensive hiring process! The result? A newly minted member of the development team. As a team lead, while it's nice to exhale once the signed employment contract is in hand, the real work has just begun.

Bringing someone new into the fold isn't just a matter of hiring and then setting them loose on the codebase. You could do this, of course. But if you do, the ramp from zero to fully productive becomes exponentially longer.

This means your organization doesn’t build a return on investment (ROI) in that developer until much later. Onboarding has a cost, just like hiring.

Good onboarding creates a high ROI for your team, the company, and the new developer.

Effectively orienting developers to their projects encompasses documentation and context (what we call vision transfer), team philosophy and communication, and preventing a toxic team dynamic.

Doing these things well during onboarding helps build developer ROI starting from day one.

Documentation and Business Context

Of primary importance is introducing the new developer to the code they'll be interacting with regularly. Developers with a high understanding of the code they’ll be working on feel 42% more productive than developers with little or no understanding.

Start setting up the signposts for where they can expect to find the answers when they have questions about the codebase. If the code is well-constructed, those signposts aren't other developers on the team (although they can certainly be helpful).

Instead, they need to know things like where the data-related code is, where the presentation code is, and where the migrations are.

Essentially, you are walking your team member through the architecture. If your team works with several codebases (or more), having consistent architecture across the board can help a lot.

If the architecture is similar, we don't have to do a basic review on each project and thus rehash the same pieces in different places. Instead, each project’s onboarding can be more about project-specific business problems and algorithms and contribute to vision transfer.

Team Philosophy and Communication

Your team’s collective philosophy should be to bring new members up to speed as soon as possible. That's not all on the team lead, but you are instrumental in establishing that tone and culture.

If that culture doesn’t yet exist on your team, you'll fight some inertia to get the existing developers "re-onboarded.”

Ideally, your team will already be able to communicate the important areas of the code.
Instead of introducing the code yourself, you can tag-team it with team members who have previously spent time in different areas of the code.

An added benefit is the face time between team members that contributes to organic team-building on a personal level.

Preventing Toxic Ownership

One thing to look out for in the team dynamic is "pet" bits of the code. Team members will inevitably feel a sense of code ownership, especially when a developer has been in the code for a long time.

We want our developers to take pride in their work and the problems they've solved, especially if it is well-constructed. But as team leads, we need to watch out for and work to separate a toxic code-ownership stance from healthy pride and satisfaction.

Hopefully you covered this in the hiring process - you want to have efficient, competent, humble contributors to the code.

If your team already operates like this, your veterans can set an example and show humility when a newcomer is about to modify their code.

In doing so, the veterans won't show the code in a manner to scare the newbie off because "here be monsters." Instead, with a nod to how well the code has worked thus far, they can welcome future contributions.

Onboarding as Investment

Successful onboarding is about setting developers up for success on their projects. Onboarding well reinforces a collaborative development environment for new hires and veterans alike.

Providing clear signposts and context, fostering a culture of communication, and eliminating toxic ownership are effective ways to introduce new developers to codebases and projects.

When introducing code is done right, your team gains an engaged, knowledgeable contributor who can deliver value sooner–a win for everyone.

The Cost of Bad Data

2025-03-10T00:00:00Z

Today more than ever before, data is critical to businesses as the driving force behind decisions. Yet many companies unintentionally rely on inaccurate data that leads to costly mistakes, missed growth opportunities, and paralyzing inefficiencies.

Bad data goes beyond correcting a typo in a field. The compound effect of data affects everything from forecasting, compliance, and collaboration to client and stakeholder relationships. Bad data costs companies $12 million on average.

If your company is making decisions based on bad data, you're flying blind. Understanding the true cost of poor data quality in revenue loss, inefficiencies, legal consequences, and relationships, and how to address those, should be a top business priority.

The Cost of Bad Data

Revenue Loss

Data informs everything businesses do and plan. When we don’t have accurate or complete data, it affects historical and future planning and reporting.

Bad data affects how businesses interpret demand and interest. Followup on opportunities may be missed, or forecasted revenue may be incomplete.

If multiple leads are incorrectly categorized as not converted, companies lose out on a potentially valuable source of potential deals. Incorrect or duplicate records could lead to wasted ad spends and marketing budgets on the wrong people for the wrong reasons.

Even outside of potential earnings, bad data can cost businesses big time. Gartner estimates businesses lose $12 million on average due to bad data. This involves potential revenue and the resources to identify bad data, clean data, and implement processes to ensure accurate data moving forward.

Inefficiency

Bad data inevitably affects team productivity. Teams have to spend valuable time and even money to verify, clean up, and reconcile data that should have been accurate in the first place.

Even generating meaningful business activity wastes time if it involves bad data. Selling with no or bad data wastes 27.3% of a sales rep’s time, or about $20,000, per year.

60% of outbound calls reach the wrong person because of bad contact information, the person is no longer with the company, or the lead isn’t qualified based on business priorities and ideal client profiles.

Compound the time it takes to clean and update that data, and you have a sales rep that is almost half as productive as they could be and will take twice as long to achieve their goals. That means bad business for their morale and your bottom line.

Incorrect data has downstream effects on automations and workflows. These can affect teams internally or other aspects of the business, such as client service and operations.

For example, inconsistent data can lead to either overordering or running out of stock. This costs time and money to manage stock, manage backorders, manage clients, and warehouse storage, just to name a few.

Regulatory and Legal Consequences

Poor data can expose your business to possible fines, legal trouble, and eroded trust with stakeholders and clients alike, especially in certain industries.

Strict data regulations govern what data is collected, how it’s stored, and what can be done. Mishandling or miscollection can result in fines, legal action, and loss of industrial compliance.

Inaccurate medical information could lead to denial of claims and possible legal repercussions.

Data and Relationships

Data even drives relationships. Consumers and clients use data to measure trustworthiness and if a company is worth their time, resources, and referrals.

This indicator can take many forms, such as evidence-based results, brand identity and alignment, or stewardship. Now more than ever, clients expect companies to deliver on their promises. How do they know a company has done that? Data.

We’ve all gotten the emails that begin as “Dear {First Name Field}”. Whether we acknowledged it or not, that made the company, in our minds, appear as careless and sloppy. Dirty data will dirty your company’s reputation.

How a company stewards data matters. If a business sends out inaccurate information or isn’t aware of past interactions, a client’s trust in that company will disintegrate. Even worse, that lack of stewardship may go viral, damaging even potential relationships

Other stakeholders rely on data to determine if the business is accomplishing its overall goals. Boards and other committees use it to determine what is working, what isn’t, and what. Poor data erodes stakeholder relationships and confidence in the business investment over time.

Why Good Data Should be a Business Priority

Better Decisions

Better data leads to better decisions. Strategy and direction are no longer gut instincts but confidently backed by experience and context that guide decisions.

These decisions affect investments, resources, and trends within the industry.

Good data means we can also make better decisions faster. No longer does leadership have to question if data is correct or teams spend time cleaning up data before the end of the quarter.

Companies are more nimble, allowing them to respond to and lead the market quickly compared to their competitors.

Better decisions have compound benefits as companies continuously iterate. As businesses make more and more decisions based on good data, it’s easier to either gradually move toward business goals or correct the trajectory when needed.

Better Client Experience

Data helps improve and personalize the client and stakeholder experiences. This leads to more effective and productive interactions that contribute to revenue and mission rather than detract from it.

The more data you have about someone, the more you know them. The more you know them, the more you can market to them. You know their preferences, decision making schemas, and what motivates them.

In turn, you know about their interactions with your business and what about you resonates with them. You know the products that they’re most likely to buy, the locations they visit, the services they’re interested in.

Combined with unsiloed data, this can be very strategic for businesses. Using the entire client persona and experience creates a relationship between your business and your clients. You can then leverage this relationship to find, win, and keep more and more clients.

Better Collaboration

Data is the glue that holds teams together and ensures they’re rowing in the same direction. Siloed, inconsistent, and outdated data causes miscommunication and strategic inefficiencies, slowing collaboration and outcomes.

Integrating data is key to making sure all teams are working together effectively. Making accurate data available across silos reduces conflicting information, duplicate efforts, and inconsistent client experiences.

The intersection of sales and marketing is one of the most crucial cross-functional collaboration relationships. If marketing targets existing clients but their sales data is wrong, they may be targeting the wrong clients, wasting their budget, and falling short on their goals.

Arming both teams with the same good data is essential to improving lead qualification, nurturing, conversion, and client experience. Reducing friction in this process directly affects business revenue.

Data is an Investment, not an Afterthought

The difference between leading your industry or lagging often comes down to the quality of your data. Companies that prioritize data accuracy, integration, and governance unlock faster, more informed decision-making, stronger client relationships, and more efficient operations.

Clean, reliable data enables teams to work together seamlessly, helps businesses personalize client experiences, and ensures compliance with regulatory requirements. Most importantly, it gives leadership confidence that their decisions are based on truth, not guesswork.

If you want to protect your revenue, strengthen your reputation, and drive long-term growth, treating data as a strategic asset is essential rather than optional. Are you making decisions with data you can trust?

The Importance of Software Maintenance Cycles

2025-03-07T00:00:00Z

When a website has been running for a while without any spectacular issues, we can be tempted to set that code aside for an extended time.

After all, if it isn't broken, don't fix it, right? Perhaps we'll wait for a high-leverage feature and that will be the kick we need to dust the project off.

As much as we want to call our software "done" at a certain point so we can stop putting further investment into it, the fact is that all software will degrade in some ways over time.

The features that work will probably continue to work (unless they depend on external services that could break or change), but other pieces of that software's lifecycle are shifting and changing underneath it.

The answers to two key questions determine how often a program or platform needs to get an update:

Does it run on the internet or a third-party service?
Will the software need additional features and changes?

If the answer to either of those questions is yes, the project should be on a regular maintenance cycle.

1. Does it run on the internet or a third-party service?

The world of the internet is constantly moving and changing. Software that was considered secure becomes insecure once a vulnerability is discovered. The problems that arise may not be directly in custom application code, either.

Code libraries save time in application development and enable developers to efficiently generate workflow-specific features without reinventing the wheel.

For example, different code libraries can allow users to authenticate with a username or password or another login method depending on the library.

If a vulnerability is discovered in the library we use for users to log in and get privileged access to certain information and features, every program that depends on that library is now inherently vulnerable.

Dependence on third-party services can also require updates. For example, the procedure for embedding a Google Map on a page has changed a few times over the years.

Or, if you're using a platform like Twilio for automated messaging, you can see new categories of errors that the program hasn't handled.

Some internet-enabled products are built with installers and used on many devices by many users. Pushing updates to those instances may not be top-of-mind when developing the software because the team is focused on features.

The maintenance cycle should be a first-class citizen in the feature framework - we don't want to get into a situation where we can no longer push updates to a myriad of clients.

2. Will the software need additional features and changes?

If the code is stale and we want to add a feature, we can proceed down one of two paths:

We could require the developers to build as much as possible with the existing dependencies.
This strategy will end up hamstringing the development team.

They may have experience in what a set of libraries did some months or years ago, but their active and productive knowledge is in the current context.

This sacrifices both their instant recall and any potential improvements made to those libraries in the interim.

Ultimately, the developers will be less productive and cost more money and time.
We can prefix the feature development with a maintenance push.

The farther apart these pushes happen, though, the more moving pieces are in play.

We could find that multiple dependencies have made significant updates and changes. Typically, the most efficient way to work through such things is to update one library, get the test suite working, and then update the other one.

But if too many interdependent relationships have major changes, the feasibility of this approach goes to zero. At that point, we're left with breaking everything and then attempting to get it all working again.

Both of these approaches sacrifice efficiency due to extra work required.

The counterpoint to these approaches is simple: quick maintenance cycles should be quick.

If all we're doing is updating dependencies and perhaps resolving a small incompatibility here and there, very little effort is involved. At that point, we can plan quick cycles every 2-3 months to keep things fresh with minimal effort.

Maintain for the Long Run

Regular maintenance cycles aren’t just a technical necessity—they’re an investment in your software’s longevity and stability.

By integrating short, consistent maintenance cycles into your software, you can avoid these pitfalls and keep your software agile. A little proactive upkeep every few months can prevent the headaches of outdated dependencies, security vulnerabilities, and disruptive feature rollouts.

Ignoring updates for too long can turn minor incompatibilities into major roadblocks, forcing development teams into costly, time-consuming overhauls.

In the end, software that’s actively maintained is software that remains reliable, scalable, and ready for the next feature.

How CI Can Save You Time and Money

2025-03-06T00:00:00Z

I was working on a desktop application for a client. The application needed installers for Windows, Mac, and Linux for every release. In addition, I wanted to run automated tests to catch any bugs introduced through code changes.

A continuous integration (CI) server could run automated tests and build installers automatically. Implementing CI tests and builds prevents bugs and simplifies development workflow, ultimately saving time and money.

Why CI?

The naive approach to making a software release would be to log into each supported operating system, run the tests, then build the installers.

Doing these tasks manually is not only time-consuming, but also error-prone. Consider the infamous trope of the lazy developer who declares "It works on my machine!" when confronted with a misbehaving program.

Ideally, we want to test and build installers in a pristine, standardized environment that isn't affected by an individual developer's setup. For this desktop application, I knew I would need a Continuous Integration (CI) server to run the tests and build the installers.

What’s CI?

What is Continuous Integration? Like a spellchecker that runs every time you edit a document, a CI server runs tests every time I save my code. Since running tests may take a few minutes, the CI server will email me if there are any problems running the tests. Additionally, the CI server runs security scans to make sure the code is not vulnerable.

For my application, I also configured the CI server to build an installer every time code was marked as ready for a new release. The Mac and Windows installers are additionally signed so they are trusted by the respective operating systems and tied to the organization's identity.

Benefits of CI

Configuring the signing process on the CI servers was time-consuming, but the effort has more than paid off. I can mark code as release-worthy, and the CI system will have installers ready to go in a few minutes. Any developer joining the project can trigger tests and installer builds simply by saving their code, no additional setup required.

While a CI server has initial setup cost and ongoing maintenance, it more than pays for itself in time saved and potential problems avoided. At Level 12, CI is just one of the many ways that we strive to protect your investment in custom software.

Search Techniques in Software Development

2025-03-05T00:00:00Z

Search has long been a problem domain for developers. We want users to input good data without scrolling through thousands of options, so we need a search. But how do we accomplish that search within the specific data?

Basic tools, such as SQL or similarity scoring, and natural language processing can effectively search data depending on the user context and intent.

SQL and Similarity Scoring

In the past, we had some limited tools around this. We could run a SQL query with the LIKE operator. Or, to get fancy, we'd run that query in a way to make it case-insensitive.

But what if the user makes a singular word plural or writes one word as two words? Then we can lean on similarity-scoring tools like Levenshtein distance and trigrams.

Potential Problems

For some data, that's all you need. But say you're searching through a list of company names, and you want to find the company closest to the current input.

We don't want the search to get too creative in that case. We wouldn't want "scottish restaurant" to return "McDonalds", and we may not be looking for "Fedex" when searching for "UPS."

For other data domains, we want some kind of cross-referencing of terms or phrases. If I'm looking for a physician, I might search for “doctor.” That's not going to be within any useful trigram or Levenshtein distance.

These are the searches where our clients ask for a Google-like experience. So, we turn to natural language processing (NLP) and embeddings.

Natural Language Processing

With NLP in search, we take a trained machine learning model that already "knows" similarity in terms and compute a set of numbers based on the model with the set of data we want to search.

When we receive user input, we can compute an embedding for that input and compare its similarity to other embeddings to get the top results.

Hugging Face has many open-source base models for this purpose. Hardware requirements depend on the model as some are more computationally intense than others.

The most intense piece of the process is generating the embeddings for the search set. If the search set is fairly static and won't get updated very often, it's best to compute it once and store it in a file.

While there are several options for file storage, I have favored storing a pandas dataframe in a Parquet file using PyArrow. This keeps the list of strings for which embeddings were computed in the same file as the embeddings.

Of course, as the data set grows, we need to consider alternate solutions like vector databases. But for a limited search of terms, the parquet file will suffice.

Choosing the Right Search Approach

Search is a deceptively complex problem, and the right approach depends entirely on the data and user expectations.

Simple SQL queries and similarity scoring work well for structured data with predictable variations, while NLP-powered embeddings are best when users expect a more intuitive, context-aware search experience.

Understanding these trade-offs is key to implementing an effective search solution. Whether fine-tuning SQL queries or leveraging machine learning models, the goal is to help users find what they need.

Bringing Old Software Up to Speed: The Realities of a Full Rewrite

2025-03-04T00:00:00Z

Sometimes in software development consulting we'll come across a client who needs antiquated software updated to current standards and potential. Quite often, due to the age of the platform, that ends up being a complete rewrite.

One situation that comes to mind right away was a circuit simulation program, which was used to train technicians to troubleshoot problems in the circuit.

Now, this software was decades old and built for earlier versions of Windows. Furthermore, it depended on some products (like Flash) for display and animation that are now obsolete.

Rewriting old software so that a company continues to derive value from it requires revisiting old technology and standards. Revisiting the original build is necessary to update a platform to modern standards and abilities.

Old Technology

The key difficulty in the project was that the old software was essentially the spec. For the most part, we didn't have a specification to work from when designing and building the new solution.

To make headway on the new platform, we needed to be able to reverse-engineer our client's older code. We needed to both refer to the old code and run it.

Of course, the old code wasn't in plain text files that could be read in any code editor. While it was C code, it couldn't be compiled by any C compiler. No - this was the domain of a proprietary IDE, Quest.

Long defunct, Quest is an IDE for which information is very difficult to find. Previously, Quest’s principle use was as a budget-conscious stand-in for tools like Visual C++, with an eye toward drag-and-drop RAD, or rapid application development.

We needed to know how to make OCX controls work to have Flash working, and figure out an obsolete IDE that didn't have a great UX. This is where experience kicks in.

Many developers can fire up a virtual machine with an older version of Windows. But many haven't been around to witness what software development was like back then.

Once you’ve cleared the hurdle of running the old code in a repeatable way, document it. Save any installers and other files needed.

Old tooling is still available in many cases, but getting harder to find, especially proprietary solutions like Quest IDE that didn't have the volume of use to match their competitors. If we need to revisit a project in a couple of years, there's no guarantee we'll still be able to find them online.

Old Standards

Then the work begins to scope out what the code accomplished and how. Often, those details have passed out of the client's knowledge some time ago due to loss of personnel or just the passage of time. So with new eyes, we consider the solutions that the old code provided for so many years.

We can sometimes bring a judgmental attitude toward the earlier developers. We must remember that this code was written under an entirely different set of constraints from what we have now.

Technology was different. Operating systems were different. Memory was a much more highly-prized commodity. The old code was written before most of our modern best practices were conceived or communicated.

So with a clearer spec now in hand, we can continue developing the new platform. This also requires revisiting the business context and requirements to ensure the solution accurately meets the business needs.

Often, the client will need to make changes due to the ebb and flow of assumptions over the life of the previous platform. Any changes and additions should be discussed at spec time if possible.

New Software, Same Value

At the end of the day, we can build the new platform according to modern industry best practices and standards, with modern tooling, and according to current constraints.

While a rewrite involves much time and effort, the end goal is about business value. Time and effort in updating a solution should be invested because we and the client anticipate some benefit that better serves the client today and in years to come.

Why Every Salesforce Admin Needs Inspector Reloaded

2025-03-03T00:00:00Z

Salesforce admins have a lot on their plate to manage and steward their org wisely. The right tools can help increase efficiency and productivity.

Salesforce Inspector Reloaded is a browser extension that can give admins quick access to routine tasks and advanced features. It has many features and benefits that can enhance admin workflows, including managing data, troubleshooting issues, and optimizing org performance.

Given its many time-saving features, Salesforce Inspector Reloaded quickly becomes indispensable for Salesforce administrators.

What is Salesforce Inspector Reloaded?

Salesforce Inspector Reloaded is an open source browser extension available for Google Chrome and Mozilla Firefox. Once installed, a panel can be expanded or collapsed when navigating the org or it can be used natively in a window.

The extension is an upgraded version of Salesforce Inspector, a similarly popular extension. Salesforce Inspector Reloaded also has continued support and improves upon the many features in the original version.

Key Benefits for Admins

Data Management

The extension is particularly valuable for bulk data operations (CRUD) and auditing records. You can export, edit, and import data without using Data Loader, Data Import Wizard, or reports.

Exporting data requires knowing some SOQL, but if you’re just getting familiar with querying, the extension has some templates for queries to get you started. You just need to fill in the objects, fields, and values you’re looking for.

You can insert, update, upsert, delete, and undelete records for standard and custom objects via uploading an Excel CSV or JSON file. The data management UI is a single screen, making the upload process less tedious.

You can quickly adjust the field mappings and adjust the batch processing size if the CPU processing time is a concern

Metadata Access

Rather than navigating through multiple pages just to get field API names, you can see them with a few clicks. You can see API field names, data types, picklist values, and security settings.
This feature significantly helps troubleshooting permissions issues, automations, or record editing issues. When building reports, formulas, flows, validation rules, or apex triggers/classes, you no longer have to check Object Manager for the API names, which is a huge timesaver.

Troubleshooting is much faster as well. The extension quickly surfaces field visibility and permissions to identify why users can’t view or edit certain fields.

Troubleshooting unexpected behavior when testing or executing automations is easier as well with the ability to inspect record data, metadata, and debug logs.

Org Management

Salesforce Inspector Reloaded allows you to search for things in Setup without even having to access Setup at all. Once you log in to the org, you can open the extension and navigate to the flow or permission set pages.

For example, you can manage users, permission sets, and permission set groups, and enable debug logs for specific users. You can log in as a specific user, even in incognito mode.

You can see all fields and values for a record, even ones hidden from the page layout or Lightning page.

You can even mass create fields. Most but not all field types are available - for example, you can’t create lookup fields, master-detail fields, or picklists based on a global picklist value set.

Adding field permissions to permission sets is much easier compared to the Setup page. If all fields have the same permission, you can just click Apply to all Fields rather than manually assign permissions to those fields

Salesforce Inspector Reloaded gives you a quick way to check the API version, release cycle, and maintenance schedule for your org. Rather than navigating to the Company Information page or Salesforce Trust site, the information is quickly available in the Org tab.

Support, Security, and Community

Unlike the original extension, Salesforce Inspector Reloaded has ongoing support. This makes the extension more secure.

The extension’s creator notes that it should be used with an eye on security. By default, any user could use this extension and access org data and metadata via API calls.

If you want to prevent that, you will need to ask Support to enable API Access Control or whitelisting, then use a connected app for certain users to allow access to Salesforce Inspector Reloaded.

Inspector vs Inspector Reloaded

Salesforce Inspector was released in 2013 by Soren Krabbe and is current up to the Winter ‘23 release. One of the most notable improvements in Salesforce Inspector Reloaded is the extension’s maintained support and improved security.

If your org is on API version 57 or later, you may not be able to query certain objects (like any objects in Nonprofit Cloud) or fields unless using Salesforce Inspector Reloaded.

The ability to control access to the extension with a connected app and permission sets is critical. The extension is very powerful, and its functionality should be restricted to only those who need to use it following the principle of least privilege.

Salesforce Inspector Reloaded for Admins

Salesforce Inspector Reloaded is a valuable resource for admins, helping them save time on routine tasks and making it easier to remove technical debt. By reducing clicks and searching, the extension helps save time on tedious tasks.

The extension can also improve speed and accuracy when troubleshooting issues, and enhance productivity when doing in-depth, technical analysis. These are invaluable in helping admins get back to doing more of what they love doing–making their users’ lives easier.

The Value of a Password Manager

2025-03-03T00:00:00Z

In the digital age that we live in, managing passwords is a day-to-day occurrence in our jobs and our personal lives.

Since I work in tech, it is not uncommon for my friends and family to ask me for help with tech-related things. In the process of helping them, I routinely notice that passwords are a pain point for most people and most people have poor habits when it comes to managing them.

In an era where cyber threats are increasing, taking proactive measures to secure your digital life is crucial. Using a password manager improves security and simplifies your online experience by eliminating the hassle of remembering countless passwords.

With its robust encryption, auto-fill capabilities, and security monitoring, 1Password is an invaluable tool for individuals and businesses.

The Risks of Poor Password Management

Without a secure method to store and manage passwords, many users fall into bad habits such as:

Using weak passwords like "password123" or "qwerty."
Reusing passwords across multiple accounts, making them vulnerable in the event of a data breach.
Writing passwords down on sticky notes or saving them in insecure documents.

These practices make it easier for hackers to gain unauthorized access to your accounts, leading to potential identity theft, financial loss, and personal data exposure.

My favorite cautionary tale from my experience is a user that kept all his passwords for his job and some from his personal life in a spreadsheet on a company shared drive. The user was not even aware that the file was in a public location.

Why do I use a Password Manager?

We as a team and I personally use 1Password as my password manager of choice. Here are some of the ways I use 1Password:

1Password’s Family Plan makes it easy to set up and track passwords for my entire family.

Having young kids, they often need to set up accounts to play games with their friends or have a separate Gmail account so I can control the amount of screen time they are allowed to have on their mobile devices and block certain websites using Google Family.
I manage most of my family’s finances.

I watched an acquaintance struggle for months after their significant other passed trying to recover access to everything. With 1Password, every bill and bank login is stored in a shared vault with my wife.

This gives me the peace of mind to know that if something happened to me, she has everything she needs to access our finances.
I keep track of items I buy and set up for myself and friends.

I recently purchased and installed a smart lock on a family member's home. The lock included a 3-page manual and three separate programming codes that had to be configured during the setup process.

I uploaded a digital copy of the manual, all programming codes, the make, the model, and the serial number to 1Password, digitally saving the information for future reference.
All logins can be tied to the website, so 1Password essentially functions as a bookmark. This lets you quickly navigate to the related website and autofill your username and password.

Why Use 1Password

1. Strong, Unique Passwords for Every Account

1Password generates complex, unique passwords for each account, eliminating the need to remember them yourself. This significantly reduces the risk of password-related breaches.

2. Secure Storage and Encryption

1Password uses end-to-end encryption, meaning your data is encrypted before it leaves your device. Only you can access your vault, keeping your passwords safe from hackers and data leaks.

3. Auto-Fill and Cross-Platform Compatibility

With 1Password, logging in is seamless. It integrates with browsers and mobile devices to automatically fill in your credentials securely, reducing the risk of keyloggers capturing your information.

4. Vault Organization and Secure Sharing

You can categorize passwords, store important documents securely, and even share specific vaults with trusted family members or team members without exposing sensitive information.

5. Dark Web Monitoring

1Password’s "Watchtower" feature alerts you if any of your credentials have been compromised in data breaches, allowing you to update your passwords immediately.

6. Two-Factor Authentication (2FA) Integration

1Password can store and generate two-factor authentication (2FA) codes, adding an extra layer of security to your accounts without requiring a separate authentication app.

2FA should also be used on any account that offers it. This helps prevent brute-force, phishing, and other attempts to crack your passwords and compromise your accounts.

Why You Should Start Using 1 Password Today

Managing passwords doesn’t have to be a headache. A password manager like 1Password takes the stress out of keeping track of your logins, making it easier to stay secure without the hassle of remembering a dozen different passwords.

It’s not just about convenience—it’s about protecting yourself, your family, and your accounts from the risks of weak password habits.

If you haven’t already, now is the time to start using a password manager. Whether keeping your personal accounts safe, organizing family logins, or ensuring you’re not scrambling to recover access in a crisis, 1Password gives you the tools to stay on top of your accounts.

Mapbox Data and Interactivity

2025-02-28T00:00:00Z

Dropping a map onto a web page is a great way to visualize data over a geographic area. Whether to show the distribution of a workforce, demonstrate commute ranges, or analyze demographics, maps can highlight the answers to data questions in a way that other tables and charts will not.

Several tools simplify programming a map from a data source. In this post, we'll focus on Mapbox.

When using Mapbox, a key concern is the balance of data set size versus interactivity. Using a different presentation library for Mapbox can help alleviate issues related to data size and enhance functionality and interactivity.

What is Mapbox?

Mapbox has two general modes of operation. In the Studio, data can be imported into essentially static map layers. These layers then get stacked up to comprise the map presentation.

A large amount of data can be pulled in here in a way that gets server-side computation, so the display becomes very efficient. But, it's not very interactive.

The client-side operation uses the Mapbox GL Javascript library. Using this tool, the developer can interact more directly with the mapping layers, such as adding and removing layers or changing out the data for a specific layer.

While the dynamic operation can make certain display elements pop, we lose the efficiency with large data sets.

All of that data must be loaded client-side and processed in the browser. This makes us much more dependent upon client-side hardware for processing and rendering data.

Data versus Performance

On the one hand, efficiency in development time dictates that we create a single, large data set and deal with degraded client-side performance.

On the other, we could break our map data into smaller areas, have data sets for each, and depend on the map zoom/pan to know whether to load in each one. While that may pose some improvement, it makes the management in code much more complex.

Of course, browser caching helps with the client-side storage of our data set, as long as it doesn't change often. Can we mitigate issues related to the size of the set on the performance front?

Up to certain limits, yes. One of the biggest ways is to use a different client-side presentation library, like deck.gl, that is designed to work together with Mapbox.

Built by Uber, this solution provides a few more configuration tweaks than Mapbox GL. One I have found useful is the ability to turn off high-DPI rendering.

Some devices, such as those with retina displays, have a ton of pixels to compute when rendering map layers.

In many display cases, though, the data being shown has relatively simple shapes, and we don't gain a lot of benefit from that high-resolution render.

When coupled with rendering these shapes for a massive data set with many objects, we can save a lot of processor/GPU cycles each time.

Post-Deployment User Testing in Salesforce

2025-02-28T00:00:00Z

When deploying changes to Salesforce, it’s easy to assume that testing is a one-size-fits-all process. However, this assumption can lead to costly oversights.

The reality is that users interact with Salesforce in widely different ways depending on their roles and permissions. What works seamlessly for one user might create confusion or errors for another.

Why User Testing Is Essential in Salesforce

Salesforce is a highly customizable platform, therefore its functionality varies widely depending on user settings. For example:

A sales representative might have access to specific fields or features tailored to their role.
An administrator may see entirely different UI elements due to elevated permissions.
A manager might view dashboards and reports designed for oversight rather than execution.
An account executive might be limited in what they can view.

These variations mean changes to Salesforce—whether they involve new features, configuration updates, or bug fixes—can have vastly different impacts depending on who uses the system.

Testing in a vacuum (e.g., with a single user profile, usually your sys admin) doesn’t account for these differences.

Post-deployment user testing ensures changes work as intended across all relevant user archetypes. This approach helps you catch issues early, reduce downtime, and minimize end-user frustration.

How Permission Sets and Roles Shape the Salesforce Experience

Salesforce’s architecture is designed to enforce security and role-based access control. Users with different permission sets or roles may experience the platform differently. Here are a few examples:

1. Custom Permissions and Field-Level Security

Some users might have read-only access to certain fields, while others can edit or delete data.
Custom permissions can restrict or expand access to specific functionality (e.g., enabling/disabling buttons or tabs).

2. Role Hierarchy and Sharing Settings

Users in different roles may have varying levels of visibility into records based on sharing settings (e.g., private vs. public ownership).

A user’s position in the role hierarchy can affect how they interact with workflows, approvals, and escalations.

3. Profiles and User Interface Customization

Profiles dictate what a user can see and do within Salesforce. For example, one profile might allow users to create accounts, while another restricts them to editing existing records.

Custom UI elements (e.g., Lightning App Builder layouts) may appear differently depending on a user’s profile or permissions. (Note: Salesforce is deprecating profile-based permissions, but profiles still control many features, including page layouts).

4. Device, Page, and App Usage

Salesforce allows developers to create multiple apps within any given organization. These are terrific for siloing particular information or streamlining user access.

It also means the same data could be displayed very differently depending on where and how you view it.

Furthermore, the Salesforce mobile app has some striking differences from the desktop view that might be very important, particularly for sales reps on the go.

These differences highlight the importance of testing changes from multiple perspectives. A feature that works perfectly for an admin might break—or even go unnoticed—for end-users with limited access.

The Risks of Not Testing Across All User Archetypes

Failing to test across all relevant user archetypes can lead to a host of issues, including:

Broken functionality: Users in certain roles may encounter errors or dead ends when interacting with the system.
Data integrity problems: If field-level security or validation rules aren’t properly configured, users might enter incorrect data—or be locked out of necessary fields.
Missed features: End-users might not see critical updates or changes because their profiles or permissions prevent access to new functionality.

In addition to these technical challenges, inadequate testing can damage user trust and reduce adoption rates.

When end-users encounter unexpected issues, they’re less likely to embrace the platform as a valuable tool for their work.

How to Approach Post-Deployment User Testing

To ensure that your Salesforce changes meet the needs of all users, follow these best practices:

1. Identify Key User Archetypes

Before testing, map out the different roles and permission sets affected by your changes. For example:

Sales reps with standard profiles.
Managers with elevated permissions.
Support agents with limited access to certain records.

This exercise helps you prioritize which user archetypes need to be tested first.

2. Simulate Real-World Scenarios

Create test environments that mirror the actual Salesforce setup for each user archetype.

For example:

Test as a sales rep would, using their specific permissions and role hierarchy.
Test as an admin might, ensuring that new features align with their responsibilities.

3. Involve Stakeholders Early

Don’t wait until after deployment to involve end-users or stakeholders. Bring them into the testing process early so they can provide feedback and identify potential issues before they become critical.

4. Test Edge Cases and Boundary Conditions

Verify how users with minimal permissions interact with new features—and ensure that those with elevated access don’t inadvertently break functionality for others.

5. Iterate Based on Feedback

Be prepared to make adjustments based on user testing results. Even the most thoroughly planned changes can reveal unexpected issues once in production.

Testing from All Angles Ensures a Seamless Experience

Salesforce’s flexibility is one of its greatest strengths—but it also introduces complexity that must be carefully managed.

By prioritizing post-deployment user testing and accounting for the unique perspectives of all stakeholders, you can ensure that your changes deliver value to everyone who interacts with the platform.

Remember: testing isn’t just about verifying that something works—it’s about ensuring it works for everyone. By taking a holistic approach to user testing, you’ll foster trust, improve adoption rates, and create a more robust Salesforce environment for your organization.

When Is It Done?

2025-02-27T00:00:00Z

Let's say I'm a business owner. I've just invested a significant amount of capital to build a software platform that will automate some processes, build business intelligence, and enhance employee efficiency.

How long do I have before that software will need to be fixed? Or, how long can the software endure before it requires expenditure again?

As engineers, we look at software in a mathematical sense: done equals all features complete and no more bugs. As we build test suites to prove software functionality, we’re more and more confident that we are approaching that goal.

Some years ago, a client who liked to ask, "When will it be done?" The question wasn’t about a specific feature or short-term goal. Instead, the question was more concerned with when the software would stop costing money.

Fundamentally, a disconnect exists between the engineers and the stakeholders when someone asks if something is done. One will say, "It will never be done!" And the other, "It has to be done sometime, or it doesn't make sense to keep putting money into it."

Breaking the logjam requires an understanding between the stakeholders and the engineers as to what done means. This involves clearly defining features and their priority, using a QA cycle, and contingency planning for undiscovered bugs.

Features vs Bugs

First, separate the features from the potential bugs.

We define software functionality positively by listing the features of what it must do. Given the development timeline, resources, and budget, we can also list the nice-to-haves.

Estimates are not guarantees, but eliminating the "unknown bugs" part of the equation will provide a firm foundation for engineering and accounting and clearly define goals to accomplish.

Quality Assurance

What quality assurance cycle will the client pursue to prove the software is ready?

QA will discover and classify bugs in the solution and establish a confidence level in the solution's readiness.

The extent of that confidence is directly related to the resources placed to build it. The larger or more complex the platform, the harder that confidence is to prove. In other words, a one-person QA team on a massive platform will not build much confidence.

Ideally, QA is accomplished by non-developer resources who will use the software with a developer's mind.

Contingency Plans

A humble software engineer will always acknowledge that there could be more bugs - whether those undiscovered in the project or those existing in software and library dependencies.

While bugs can be discovered/fixed before features are "done", the reality of software is that bugs can raise their ugly heads at any time.

Some of these will be incidental, meaning they can be worked around without a huge hit to productivity. Others will be showstoppers, halting the use of the platform until something is done.

If QA has happened well and the solution has a solid test suite, showstoppers shouldn't happen. Or, if they do, they may be related to other, underlying code or infrastructure.

Either way, there needs to be an understanding of the potential cost. On the one hand, if a showstopper happens, productivity is lost, therefore revenue is lost. Balance that with the cost to resolve the issue, and fixing the problem is often the right thing to do.

Done means Done

Aligning stakeholders and engineers on what “done” means for software requires a clear understanding of features, the QA process, and the reality of later bugs in software.

As long as there is an agreement on what "done" means and doesn't mean, the reality of unexpected bugs does not have to be a potential issue down the road.

Documenting and prioritizing the software’s features helps. QA and the test suite can build collective confidence above the threshold that meets "done."

Once the project is “done,” changes and fixes that come up later will enhance the solution’s value even further.

Managing Changes in Source-Driven Development for Salesforce

2025-02-26T00:00:00Z

In my experience, Salesforce deployments are often a hidden productivity killer that extends the time it takes to develop new features or fix bugs for admins and developers alike.

To mitigate this, we use source-driven development to manage most of our clients' organizations. Source-driven development helps us know the current configuration of the production environment and all development environments at any time.

This has become a necessary process as we collaborate with our clients. We often have a half dozen or more features in various stages of our development cycle throughout a sprint, and our clients frequently make changes directly in production when developing new features.

By using source-driven development, we can quickly and effectively determine if our clients have made changes we were not aware of and make sure that the changes we are preparing to deploy to production will not conflict with any changes that have been made.

Retrieving Changes

The Salesforce CLI has a command that retrieves any changes made in a source-tracked Developer sandbox since the last time the command was run. Source tracking is not enabled by default on developer sandboxes. It can be enabled by following this article.

Salesforce’s CLI Command Reference reviews the command below in detail.

sf project retrieve start --ignore-conflicts.

This command greatly improves our ability to retrieve our changes into source control, but this is by no means a foolproof system.

Source tracking has some inefficiencies that do not work as expected. Every retrieval should be reviewed in detail for accuracy.

For example, when you assign a Lighting page as the default page for a specific application, source tracking does not automatically include the app when the metadata is retrieved.

Another example is retrieving profiles, which can lead to overwriting metadata. According to Salesforce, profile changes should not be deployed as metadata from one org to another.

Deploying Changes

Once all the metadata is in source control, the next step is deploying the changes to another organization.

We make a pull request to the target branch for the full (QA) or partial (staging) sandbox we use for user testing. The pull request will notify us of merge conflicts between the current feature and ones already deployed to the target branch.

Once a pull request is ready to deploy, we use the Salesforce CLI plugin SFDX-Git-Delta to create deployment manifests with the command below.

This creates two manifests that include the differences between the working branch and the target branch. One manifest is destructive, and the other is a deployment manifest.

sf sgd source delta --from <Target Branch Name> --output .

We then test the deployment. The following command performs three separate functions:

Test the deployment of all metadata changes in the package.xml file
Test the deletion of all changes in the destructivechanges.xml file
Run all Apex test classes

sf project deploy validate -x package/package.xml --post-destructive-changes destructiveChanges/destructiveChanges.xml

If the command fails, it will return detailed error messages for each metadata component that fails deployment or any test class that fails.

This command does not deploy your changes once the deployment is successfully validated but generates a second command to run when executing the deployment.

Document the second command if the deployment will be executed later. The second command contains a system-generated id that cannot be easily found again.

Change Management and the Development Workflow

With this workflow, we can effectively manage internal and external changes in our clients’ orgs. We can easily identify client modifications and compare them to internal changes.

Leveraging the productivity features of the Salesforce CLI and SFDX-Git-Delta plugin enhances admin and developer productivity when retrieving and deploying changes in Salesforce orgs.

This saves time, money, and resources and accelerates feature development and bugfixes.

Active Listening and Client Empathy in Software Development

2025-02-26T00:00:00Z

One of our pillars at Level 12 is value–we don’t want to waste time and money (either ours or our clients) building the wrong thing. We also want to ensure that what we build is really what the client needs and addresses their core problem.

Often we find that when clients ask for something, something else would give them more value, but they don’t know it yet.

Sometimes, building what a client asks for instead of taking the time to deeply know their business and process is the wrong approach.

We call this client empathy. Client empathy is fleshed out in many different ways in our team, but a major way we demonstrate and pursue client empathy is through active listening.

Client empathy demonstrated through active listening leads to better client value and development team ownership and interaction. Active listening is getting involved in someone else’s story, asking good questions, and fully understanding what they say.

Client Empathy

What is empathy? In its most basic form, empathy is fully identifying with someone else. Empathy is when we link arms with our clients, understand their business from top to bottom, and deliver solutions that address their needs and benefit them.

Client empathy gives better results for the client and the development team. The client gets a better solution that meets their needs and anticipates future growth. The solution is scalable in a technical and business context.

The team better understands the client, which prevents building the wrong thing. The team has enough context to look for unrealized value or push back against things they think won’t be valuable to the client.

Active Listening

Active listening is giving someone your full attention when they’re speaking. It also encompasses preparing to listen, receiving verbal and nonverbal messages, and giving feedback.

Active listening differs from passive listening in that passive listening has a higher chance of miscommunication or unmet expectations. Passive listening doesn’t interpret or clarify the full message, so the speaker can’t confirm or clarify the received message rather than the intended message.

Active listening involves:

Paraphrasing and reflection
Asking open-ended questions
Clarifying what was said
Limiting distractions or problem-solving in the moment

Active Listening in the Consulting Relationship

Active listening isn’t just limited to client interactions or the project kickoff meeting. Active listening should permeate every aspect of a relationship or project.

Discovery Phase

The discovery phase, requirements gathering, or project kickoff is probably the first project context that you think of when you think about active listening.

While it’s not the only context in which active listening is demonstrated, it is one of the most important. This portion directly affects what is built, when it’s built, and how it affects other aspects or priorities of the project.

Active listening through open-ended questions and clarification is crucial here. Rather than taking an order of desired features, asking questions to probe deeper into processes and desired results can reveal unspoken insights.

You learn not just about processes but values–why they do things, what they want to accomplish, and their goals.

One thing I struggle with is the tension between listening and doing:

Wanting to preserve and document what I’ve learned, or
Already designing their solution

Both are good and valuable qualities in the right context. A good consultant should know when to mute those tendencies when interacting with clients.

Solution Design

With the information from the discovery, active listening also affects the solution design.
Insights gleaned from the discovery phase directly affect what we build.

We aren’t going to build the tank that the client requests. We’re going to build the milk truck that they need.

If we design solutions instead of listening to the client, we miss information crucial to building the right thing.

As we build solutions, we have enough information to know if other features would be more valuable or if we could remove things because they’re not valuable or high priority at the time. Vision transfer also comes into play here–the team should be equipped to see the end goal and either drive toward that or raise flags for features that may not be in the client’s best interest.

Stakeholder Management

Active listening helps build trust with clients. It aligns the consultant and the client and shows the client that you’re on the same page, what they say matters, and what they say is valuable.

As trust is built, clients become more open. This builds a stronger relationship between the client and the consultant.

Active listening can also help alleviate resistance to change.

Fundamentally, we as humans want to know that we’re heard and understood. Active listening throughout the entire client relationship builds trust. This trust can propel projects through the friction of change for the benefit of the client.

Clients feel comfortable expressing their concerns. Rather than feeling misheard or misunderstood, they know what they communicate is valuable.

The consultant can then address those concerns and work with the client through issues or challenges, leveraging the partnership to benefit the client.

End User Experience

Leveraging empathy in user training is critical because it should inform the end-user experience.

The users are perhaps the most important people to listen to. They know their jobs best and what would improve or inhibit their workflow.

Active listening ensures that training is received and understood, builds trust with end users, and tells them their perspectives and opinions are valuable.

Empathizing and diving deep into their stories also help make the solution more useful. Iterative feedback is critical in providing value quickly and accurately.

Active Listening Drives Results

From start to finish, active listening is key to developing and maintaining client empathy for software development teams.

Listening through the entire solution lifecycle, from kickoff through user training, helps establish rapport and trust with stakeholders and users, ultimately leading to better-built software.

Active listening:

Builds trust
Guards against assumptions
Helps teams build the right thing
Avoids scope creep and extra work

Active listening in software development results in happier, more productive clients and software teams.

Claude Sonnet AI for UI/UX

2025-02-25T00:00:00Z

As an experienced software developer, I've found AI coding assistants surprisingly helpful and frustratingly limited.

A coding assistant helps me automate routine refactoring tasks and is a more efficient way to search the web or look for documentation.

Unfortunately, it can also produce incorrect or outdated code snippets, which can be problematic when working with unfamiliar libraries.

However, I've found that AI is helpful for UI/UX-related questions for developers who primarily focus on data or struggle with visualizing how users will interact with software.

I recently used the Claude Sonnet AI model and found its outputs especially helpful. It approached my problem with a fresh set of "eyes" and generated a wireframe-like design and relevant code, allowing me to visualize its suggestions.

UX Challenges for Developers

I like to think that I have a good intuition for UX issues—at least ones that are glaringly obvious.

As a full-stack developer, I often have too much of the software’s internal workings in my head to determine objectively whether the interface is easy to use. I also have trouble visualizing UIs and workflows in my head.

Because of this, I like working with mockups produced by skilled designers, but not every project I undertake has a UI/UX designer.

Leveraging AI for UI Feedback

In such cases, or when I just need a quick feedback loop, I've started using the following instructions for Claude Sonnet (with high creativity):

You are an experienced UX designer. You work well with developers and can explain UX principles in terms they can understand.

Here's an example prompt I used recently:

My app allows users to subscribe to different notification lists to receive text alerts. A subset of those lists are "required". This means that the user must be a member of at least one required list, while the other lists are optional. An example would be a school with lists "parent", "teacher", "student". What sort of UI would facilitate enforcing these constraints? I want to show available lists for subscriptions while indicating to the user that they must belong to a required list. If they try to remove a required list, I want to show them feedback.

Claude produced a simple ASCII art UI and explained its design choices. It also adjusted the design as I provided further details about the use case.

I like that it defaulted to ASCII art for the UI, as I didn't have to sift through generated code that wasn't relevant to my framework.

Once it generated a UI I liked, I asked for code in the particular CSS framework I was using.

AI as a UX Consultant

AI is helpful for UI-related questions such as:

How can I word this error message in a way that makes sense to regular users?
Given a database model, what would be the best UI for updating a given subset of fields?

For developers who aren’t as skilled in UI/UX design or who need an objective opinion, AI can provide helpful feedback and even framework-specific code, making developers more productive.

The Art of Organizing Your Django Project: Apps vs. a Single Core App

2025-02-24T00:00:00Z

When building a Django project, one of the first decisions you face is how to structure your application.

Should you break it down into multiple apps or consolidate everything into a single core app? Let’s explore both approaches and help you decide which might be right for your next project.

Multiple apps offer flexibility, reusability, and scalability, making them ideal for larger projects or agencies that work across many clients. On the other hand, a single core app simplifies development and reduces complexity for smaller, more focused efforts.

Ultimately, there’s no one-size-fits-all answer. What matters most is choosing an approach that aligns with your project goals and team capabilities while keeping your codebase maintainable and future-proof.

What Are Django Apps?

In Django, an “app” is a module that encapsulates functionality related to a specific aspect of your project. For example, one app might handle user authentication, while another manages product inventory.

Apps are designed to be modular and reusable, making it easier to build projects by assembling pre-built or custom components.

The default Django project template includes an app directory, but you can create as many apps as needed. This modularity is a key strength of Django, allowing developers to organize code in a way that aligns with the problem domain.

Why Use Multiple Apps?

Reusability Across Projects

One of the primary benefits of using multiple apps is reusability.

If you work on multiple projects, especially in an agency setting, breaking functionality into separate apps makes it easier to reuse code across different sites or systems.

For instance, a customer relationship management (CRM) app developed for one client can be adapted and reused for another.

Clear Separation of Concerns

Apps help enforce the separation of concerns, making your codebase more organized and maintainable.

By isolating functionality into distinct modules, you reduce the risk of code bloat and make it easier to understand how different parts of the system interact.

Easier Testing and Scalability

Smaller, focused apps are simpler to test and debug. Unit tests can target specific components without worrying about dependencies on other parts of the system.

Additionally, when scaling your application, modular apps make it easier to distribute work across teams or deploy services independently (a precursor to microservices).

Future-Proofing Your Project

If you ever consider migrating to a microservices architecture, Django apps can serve as building blocks for future refactoring.

Each app represents a logical boundary that aligns with the principles of service-oriented design.

When Might a Single Core App Be Better?

While using multiple apps offers many advantages, there are scenarios where consolidating everything into a single core app makes more sense:

Small-Scale Projects

For small projects or proofs of concept, creating multiple apps can feel like overkill.

If your project doesn’t require reusability across different sites or teams, sticking with a single app simplifies the structure and reduces overhead.

Rapid Development Cycles

In fast-paced environments where speed is critical, a single core app can streamline development.

Without the need to manage dependencies between apps, you can move faster without worrying about how changes in one part of the system affect others.

Minimal Complexity

For developers new to Django or teams that prefer simplicity, a single app reduces complexity.

There’s less to learn and fewer moving parts to manage, making it easier to onboard team members.

Best Practices for Organizing Your Apps

Whether you choose multiple apps or a single core approach, certain practices will help you maintain a clean and scalable codebase:

Define Clear Boundaries

If using multiple apps, ensure each has a well-defined purpose. Avoid overlapping functionality that could lead to confusion or duplication.

Minimize Interdependencies

Apps should be as self-contained as possible. Reduce dependencies between apps to make them more modular and easier to work with.

Use Packages for Reusability

If you’re building apps intending to reuse them across projects, consider packaging them. This makes it easier to distribute and install them in different environments.

Document Everything

Regardless of your approach, thorough documentation is essential. Explain how your app(s) are structured, what each part does, and any dependencies they have.

Use What’s Best

The decision between using multiple apps or a single core app in Django depends on the specific needs of your project and team. This choice has implications for maintainability, scalability, and even future flexibility.

Risk Management in Software Consulting

2025-02-24T00:00:00Z

Engaging as a software consultant with new clients requires drinking from the firehose to learn how the client operates and what is valuable to their business. Every business is different, even those within the same industry.

Part of learning the client’s business and processes requires learning about risks. The success of a software project will often rise or fall based on a shared understanding of risk management.

This shared understanding encompasses how well the consultant understands risks in the business context, shares that knowledge with the client, and considers the risk inherent in services the software uses.

Risk is Part of Understanding a Business

A distinctive of a good consultant is the ability to articulate risks in terms of severity when software development is often approached as a commodity.

Effective consultants will be able to speak with the stakeholders at a business level, even more than at a technical level, to build an understanding of a client's needs.

Budget and delivery timelines can take up a lot of discussions as they’re often key reasons for choosing a particular consultant for the job.

Those reasons provide a quantitative (though predictive and often inaccurate) comparison, but budgets and timelines don't give the stakeholders any idea of how well the consultant understands their business.

Business needs extend beyond cost and scheduled deliverables; they also encompass contingency plans, security considerations, and remediation.

A good consultant will deep dive into existing risks and plans and anticipate potential risks and their severity.

On the Same Page

I don't know how many times I've walked into a business and the first thing they want me to know is, "The computers are down today," “The network is down,” or “The phones aren't working.”

Somewhere, something has stopped functioning, and the business may or may not have procedures to mitigate the outage or personnel trained in those procedures. A mismatch of values and understanding about risk can be disastrous.

As a consultant, it's not fair to the client to leave out risk. What happens if this piece breaks down and has a day-long outage? How much money will be lost? Is it worth bringing another service online for a while to mitigate the outage?

Risk and Services

When designing a software product or platform, we field and integrate many different services over the internet. Reliance on third-party services can help a platform reach operational status much more quickly. No one wants to plan for the platform to go down for any length of time.

But a competent, conscientious consultant, knowing what happens in the real world, doesn't leave that to chance–he asks questions and assesses the risks.

For instance, a lot of companies are beginning to integrate generative AI into their workflows. Let's say you build your workflow on one of the major players, like ChatGPT, Gemini, or DeepSeek.

It's well worth asking the question, what happens if that service goes down hard for a day or two? Or, when you scale to a certain level, what happens if that service is used too much, encounters rate limitations, and the software can't use as much of the service as you would like?

One backup plan is to have multiple AI models online in case of needed failover, but this can greatly increase a project's complexity.

The ideas discussed in a risk management conversation may not be immediately actionable. A client may not want or be able to immediately put resources toward having an operational backup plan that can slide into service at a moment's notice.

However, having the conversation is still valuable because it explores some technical feasibility without the added pressure of an active outage.

Results

Good consultants, especially those at the CTO level, should present the pros and cons of various approaches to risk management.

That starts with classifying various risks from minor annoyances to organizational risks that can bring down a company.

Little one-minute outages here and there may not be a big deal, as long as they don't happen very often. But losing a company's database due to hardware failure and not having a backup - well, that can spell doom.

As the consultant drinks from the firehose of contextual learning, existing and potential risks should become part of the conversation around a proposed software solution.

User-Centered Salesforce Training and Vision Transfer

2025-02-21T00:00:00Z

Effective Salesforce training teaches users how Salesforce helps them do their job better, not the latest and greatest features. Our goal is to empower users with a tool that helps them achieve their goals.

User-centered Salesforce training means that the system should be built with their needs in view, training should apply to roles, daily tasks, and business goals, and training should be interactive and ongoing.

Build Well, Train Well

Training finds its roots long before the demo session. It all starts with how well we understand what the users need to do and why they need to do it.

One of our pillars at Level 12 that informs how we work and what we build is vision transfer. Vision transfer refers to how well we transform a client’s business needs into actionable tasks and preserve accuracy and context.

In other words, vision transfer means that everyone on the project should understand:

why the business needs what we’re building on a micro and macro level
what we’re building is a gainful investment for the client

This informs everything at Level 12 - why we work in sprints, how we get clients involved with their projects, our goals when meeting with them, and how we run our teams. It’s what separates us as a company from other development firms.

This understanding shouldn’t stop when we’re done building. It should permeate demos, training, and requirements gathering and building.

Our goal isn’t to showcase but to demonstrate how what we built meets their needs and brings them more value than what they had before.

Empower Roles

If vision transfer is done well, we should deeply understand who is using the platform and why. Our guidance then, should address those goals and demonstrate the platform’s usefulness in achieving those goals.

Each feature should correlate to the person’s responsibilities and goals. If you can’t answer how something will make them more productive and meet their goals, users won’t see its value.

Even our language can go a long way in showing users. Abandon technical, feature-oriented language in favor of value-based language. Instead of logging opportunities, show your reps how to track deals.

Creating role-based training paths prevents the overwhelming sense of something new, especially if users aren’t familiar with the platform or have never used it.

Software is only as good as its usefulness. No one gets any value from solutions that aren’t helping people do their jobs or businesses run.

Role-based training is also a strategic context to demonstrate the value that Salesforce can bring to specific jobs.

What an administrative assistant needs to do in Salesforce is quite different than the sales rep, which is quite different from what a sales VP wants.

Just as we wouldn’t gauge these jobs by the same benchmarks, we can’t lump them together in terms of what they should know.

Contextual and Consistent

Inevitably, users will feel like they’re drinking from a firehose. Salesforce can be a lot, and it can be overwhelming when trying to do a job and adapting to something new.

First, step out of your shoes. Separate from the work so that you can see it from an outside perspective. Even physically and mentally take a break from it if possible.

Then, design initial and ongoing support and resources. Resources should give users the information they need, when they need it, and where they need it. Strategically serve them rather than inundate them with information.

We’ve found that users learn best by doing, especially those new to Salesforce. Depending on the group and context, a variety of formats can help users get hands-on for the first time:

Demonstrating their workflow and specific features, then letting users pilot before finalizing the work
Hands-on, real-time training and guiding users through the platform instead of showing them
Using real examples and data instead of placeholders to help users envision what their data will look like
Recordings and videos to refer to later if needed
For larger group settings, working in groups or going through mock situations

Thoughtful, consistent training will depend largely on the audience:

Use in-app guidance
Keep office hours for accessible drop-in discussions or questions
Keep documentation, guides, or videos
You can even make it fun - use games or competitions

Training That Works

Effective Salesforce training is more than just teaching features—it’s about helping users see how the system supports their daily work and business goals.

By building with users in mind, aligning with roles and responsibilities, and making learning interactive and ongoing, we create a foundation for success.

At Level 12, vision transfer is at the core of our approach, ensuring that every solution we build is not only technically sound but also valuable and intuitive for those using it.

Training is an extension of that process. It’s not about showcasing functionality but demonstrating real-world impact.

By empowering users with role-specific, contextual, and consistent training, we turn Salesforce from just another tool into an integral part of their workflow.

Thoughtful training doesn’t just improve adoption; it makes Salesforce a platform that genuinely helps businesses and individuals thrive.

Checklists and Developer Productivity: Getting Over the Hump

2025-02-20T00:00:00Z

If you find yourself staring at your screen instead of making progress, try breaking a big problem into smaller ones by using a checklist.

This forces you to plan your work systematically and gives you positive feedback as you complete each task.

Big Problem, Small Tasks

Recently I was working on an update for a new project using a framework I was unfamiliar with. The update was fairly broad in scope.

Progress was slow as I worked to simultaneously assimilate the data model and the unfamiliar, framework-specific code.

After a few days of spinning my wheels, I realized I needed a different approach. I began by splitting the update into a series of subtasks.

I keep project notes in Obsidian, so I created a new document with a simple markdown checklist. I determined what parts of the project to update and added subtasks for each part.

If necessary, I added child tasks under the subtasks for even better granularity. Any notes or questions that needed answering for that subtask were also documented in the list.

Checking it Off

Once I had a checklist, I was able to tackle one piece of the update at a time. Seeing each item checked off in turn was highly motivating.

Like many productivity techniques, dividing tasks into subtasks seems like a no-brainer. My true takeaway is to force myself to reach for these techniques sooner until they become an instinctive part of my mental toolkit.

Version Control, Git, and the Salesforce Admin

2025-02-20T00:00:00Z

Often only associated with developers, version control and Git are becoming more relevant to Salesforce administrators. The concept can be intimidating for those with little technical experience, solo admins, or even admins who are part of a team regardless of size.

Version control can serve Salesforce admins well in managing and stewarding their org as it has many advantages over other workflows.

Ultimately, a deep understanding of version control gives you a deeper understanding of Salesforce and the changes you’re making, making you a better, more thoughtful admin.

What is Version Control and Git?

Essentially, version control in Salesforce is a way to track changes in files. These files contain the metadata that forms the org’s framework–incuding configurations such as flows, objects, apex triggers, classes, and tests.

You can implement version control in many ways, but Git is the standard choice for Salesforce. Git allows different people to work in isolated environments without the risk of overwriting someone else’s work.

With Git, the files are kept in a repository. The main branch of that repository holds all the files that (should!) correlate to the production org.

Gearset, Copado, and many other tools all have a UI dedicated to manage version control and the development pipeline, but may be cost prohibitive depending on the team and budget.

We’ve found VS Code with GitHub (or another repository host) to be more cost effective for smaller teams.

Branching

Besides the main branch, various other branches represent work in progress. These branches also have copies of the files but allow work to be performed independently of other work. The files on these branches correlate to whatever work is happening.

If two admins are working on features that involve the same objects, branches in Git can represent that work without the files for one feature possibly overwriting the other.

Depending on a specific workflow, branches can represent a dev, staging, or QA environment, development of a specific feature, or any other work being performed.

Committing Changes

As you make modifications, you commit those changes to your branch, effectively saving the changes within the metadata files.

You should commit often as you work instead of all at once when you’re finished, and each commit should correspond to a logical piece of work (for example, all the changes to a page layout or changes for each flow if you’re working on multiple flows).

Pushing to Production

Once all the changes are on the branch, you will open a pull request to merge the changes into the main branch, or whatever branch is next in your pipeline.

Pull requests are typically reviewed by other people to ensure accuracy, quality, and that the customizations achieve the outcome.

Why Version Control?

Deep Dive
- Even a small change can have a ripple effect throughout an org. Thinking of your org in terms of metadata files helps you realize how a change can affect other parts of the org.
- This makes you more aware of how Salesforce is built, the effect of technical debt on your org, and the extent of configuration involved in even the smallest change.
Tracking Changes
- Using version control means you have a history of the metadata files in your org. You can see when they were changed, who changed them, and the content of the files before the change.
- Not only do you have a history of the changes in production, but you can keep a history of changes in development or waiting to be deployed to production.
- You know, down to the line number, the modifications made to your metadata.
Rollback, Recovery, and Security
- If something goes wrong, you can easily restore a previous version of your org from the files in the repo. On a larger scale, you have a backup of your org’s configuration.
- If you work in an industry where security and compliance are especially important, you have an audit trail.
Collaboration
- Version control makes it easier to work with other admins, developers, and consultants. It’s clear what person made what changes when.
- However, this requires everyone’s buy in. If everyone involved in the project doesn’t understand the importance of version control and use it, your history will be incomplete, which undermines the very reason for using it to begin with.

Getting Started with Git

Many tools make managing org metadata easier, but understanding what is going on ‘under the hood’ reinforces the development pipeline and furthers the admin’s understanding of the metadata that lies underneath their org.

Resources

DuckDB for Data Exploration

2025-02-19T00:00:00Z

At Level 12, we often need to make sense of datasets from a variety of sources. One tool in our data analysis toolkit is DuckDB.

DuckDB's speed, versatility, and unified SQL interface allow us to quickly gain insights from diverse datasets.

What is DuckDB?

DuckDB is an embeddable, columnar database system. What does this mean?

Embeddable: DuckDB can be used as a library in multiple programming languages, including Python.
Columnar: DuckDB has a columnar, vectorized query engine which allows it to more efficiently process analytical queries compared to a traditional relational database management system (RDBMS).

File Type Support

DuckDB can load these file types:

CSV
Parquet
Excel
JSON

You can mix and match datasets of varying types into DuckDB tables, then run queries combining the disparate datasets using SQL joins.

This ability to query and join multiple datasets using a single interface, namely SQL, is immensely valuable.

Data Source Support

DuckDB can read from:

Local filesystem
http endpoints
Cloud storage such as S3
Database servers such as PostgreSQL and MySQL

This allows you to compare and join local data to files in cloud storage without having to manually download them.

For example, to view a parquet file from S3 using the DuckDB CLI:

SELECT * FROM 's3://my-bucket/file.parquet';

The full power of SQL is available to read and transform the data.

Also, while DuckDB can load datasets into memory, it can save multiple tables into a single database file for later use.

Diverse Data and DuckDB

In summary, DuckDB is a powerful and flexible tool for working with diverse datasets. Whether you’re working with local files, cloud storage, or live database connections, DuckDB’s unified SQL interface simplifies the process, allowing you to extract insights quickly and efficiently.

Its ability to efficiently process analytical queries, support multiple file formats, and seamlessly integrate with various data sources makes it an excellent choice for data analysis.

Level 12 Blog

The Hidden Costs of Offshore Development

The Offshore Development Promise

The Hidden Effects of Offshoring

Is Partial Offshoring a Good Compromise?

The Reality of Partial Offshoring

The Better Alternative

Conclusion

TravelTime vs. Google Maps API

Understanding Data Needs and Sources

Google Maps

Distance Matrices and Cost

Isochrones

Commute Wait Time

TravelTime

Distance Matrices and Cost

Isochrones

Commute Wait Time

Real-World Expectations and Accuracy

Real Application of TravelTime

Making the Right Choice for Your Project

Further Reading

Solving TravelTime Coordinate Validation Errors: PBF vs Shapefile Comparison

The Modern Mapping Landscape and TravelTime Coordinates

The First Attempt: ShapeFile Format

ShapeFile

Limitations of ShapeFiles

The Solution: PBF Files with Highway Filtering

PBF Files

Filtering for Driveable Roads

Future Improvements: Automated Validation

Key Takeaways for Developers

Nonprofit Cloud Outcome Management Objects

What is Outcome Management?

Nonprofit Cloud Outcome Management Objects

Programs and Benefits

Care Plans and Goal Definitions

Outcomes

Outcome Activities

Indicator Definitions

Indicator Assignments

Indicator Performance Periods and Time Periods

Indicator Results

Benefits of Outcome Management

Tell the Story of Change

Improve Programs

Secure Funding

Planning and Accountability

Clarity and Effectiveness with Outcome Management

Further Reading

Managing Technical Debt in Software Development

The Critical Impact of Technical Debt

When Technical Debt Reaches a Tipping Point

How to Address Technical Debt

Managing Technical Debt

How Technical Debt Develops in Development

The Reality of Development Constraints

Transforming Toxic Code Ownership into Team Collaboration

Evaluate the Environment

How to Eliminate Toxic Code Possession

Competence and Communication

Test Suites

Code Reviews

Toxic Possession to Constructive Collaboration

Building UI with AI

Creating a Modal Dialog to Select and Delete Users

Select All/None

Confirmation Modal with User Input

Bootstrap Adjustments and UX Details

AI Reduces Development Time

Further Reading

AI-Driven Library Updates: Modernizing Morphi with Augment Code

Modernizing Morphi with pyproject.toml

Leveraging AI for the Solution

The Prompting Process

Handling JSON Compilation

Testing and Implementation

How Valuable Problems Prevent Valueless Solutions

Reframing Value in Problems

Defining Value