LATITUDE 40
  • Home
  • About Us
    • Who We Are
    • How We Work
    • Our Quality Standards
    • How We Forecast ROI
  • Solutions
    • Custom Software
    • Explore Solutions
  • Successes
    • Case Studies
    • Testimonials
  • Insights
    • Blog
    • ROI Guides
  • Contact

Latitude 40 blog

Using Global Fields in Claris FileMaker: A Powerful Tool for Context-Free Data Access

9/9/2025

0 Comments

 
​Every programming language has the concept of global variables—values that persist across the entire application, not just within the scope of a function or class. In Claris FileMaker, this idea is extended through a unique feature called Global Fields.

​What Are Global Fields?

According to Claris documentation:
A field that uses global storage (a global field) contains one value that’s used for all records in the file. Global fields are accessible from any context in the file, even if the field is defined in an unrelated table.
​

This means that unlike regular fields, which store data per record, global fields store a single value across all records and are accessible from any layout or context—without requiring relationships.

​Why Global Fields Matter in FileMaker Layouts

Claris Developers are familiar with the fact that all layouts are based on a primary table occurrence, and to display fields from other tables, you typically need to establish relationships. For example, if you're working on an Orders layout and want to show the Customer Name, you must relate the Orders table to the Customers table.
​
However, global fields bypass this requirement. They can be used anywhere in the app, regardless of table relationships. This makes them ideal for storing values like:
  • Company information (e.g., name, logo, contact details)
  • Session-specific data (e.g., current user ID, selected record ID)
  • UI control values (e.g., filters, flags, toggles)

​A Practical Use Case: Session Context Table

One powerful pattern is to create a dedicated Global Context Table that holds various global fields representing the current session state. For example:
  • gCurrentOrderID
  • gCurrentCustomerID
  • gCurrentPOID

These fields can then be used to relate to other tables dynamically, allowing you to build layouts and workflows that are independent of the current layout’s context.

​Example Scenario

Imagine an Order Details page that shows the most recent Purchase Order (PO) and its status. You can use a global field to store the current OrderID, then relate it to the POs table to fetch the latest PO.

Now, if the user wants to view all POs for that order on a different layout, the global field still holds the OrderID, allowing the new layout to display relevant data without disrupting the relationships or state of the original layout.
​
This approach enables a modular and flexible UI, where different layouts can share context without being tightly coupled through relationships

​Advantages of Using Global Fields

Global fields in Claris FileMaker offer powerful advantages for workflow optimization, especially when designing scalable and efficient solutions:
  • Context Independence: Global fields allow access to data across multiple layouts without requiring table relationships, streamlining workflow design and reducing schema complexity.
  • Session Management: Ideal for storing user-specific or session-specific values, global fields support personalized workflows and dynamic user experiences.
  • Simplified UI Logic: Use global fields to control interface elements like filters, toggles, and navigation states, enabling cleaner scripts and more intuitive workflow automation.
  • Performance Optimization: By minimizing reliance on complex relationship graphs, global fields contribute to faster load times and smoother user interactions, enhancing overall workflow efficiency.

About Latitude 40

Latitude 40 integrates experienced on-shore software development professionals into your organization, forming collaborative teams with or without your existing developers. Together, we identify needs, create tailored software solutions, and instill best practices that drive continuous improvement and ensure agility.

Contact Latitude 40 to learn how we can help with your Claris projects.

About the Author

​Dan DeLeeuw is the Chief Operating Officer at Latitude 40 Consulting and a Certified FileMaker Developer. He consistently maintains the latest FileMaker certifications, reflecting his commitment to staying at the forefront of the platform. Dan is a strong advocate for clean, maintainable, and well-documented code, believing that clarity is key to scalable and sustainable development
0 Comments

Clean Code: Write Code That Explains Itself

8/10/2025

0 Comments

 
Software developer writing clean code via their laptop

Introduction

In the world of software development, clarity is king. While comments and documentation have their place, the best code is the kind that explains itself. That's the essence of self-documenting code; writing code that's so clear, it barely needs comments.

In this post, we'll look at two simple but powerful techniques to make your code more readable and maintainable.

Naming That Explains

Poorly named variables and methods are one of the fastest ways to make code unreadable. Consider this simple example:

var d = DateTime.Now.AddDays(7);
if (u.IsActive && d > u.Reg)
{
    Send(u);
}

Now compare it to this:

var expirationDate = DateTime.Now.AddDays(7);
if (user.IsActive && expirationDate > user.RegistrationDate)
{
    SendWelcomeEmail(user);
}

Same logic. Vastly improved clarity.

Tips for Better Naming

  • Use descriptive nouns for variables: invoiceTotal, userEmail, retryCount
  • Use verbs for methods: CalculateTax(), SendReminder()
  • Use predicate-style names for boolean methods: IsExpired(), HasPermission(), CanRetry()
  • Abbreviations are fine when they’re widely understood or when the full name would be unwieldy
  • Don’t be afraid of longer names if they improve clarity, but use judgment. Sometimes overly long names can hurt readability more than they help

Extracting Logic into Named Methods

Another way to make code self-explanatory is to extract blocks of logic into well-named methods. This not only improves readability but also makes testing and reuse easier.

Before:

if (user.IsActive && DateTime.Now.AddDays(7) > user.RegistrationDate)
{
    SendWelcomeEmail(user);
}

After:

if (ShouldSendWelcomeEmail(user))
{
    SendWelcomeEmail(user);
}

...

private bool ShouldSendWelcomeEmail(User user)
{
    var expirationDate = DateTime.Now.AddDays(7);
    return user.IsActive && expirationDate > user.RegistrationDate;
}

Now the if statement reads like a sentence. The logic is tucked away in a method with a name that explains its purpose.

When Comments Are Appropriate

Self-documenting code reduces the need for comments, but it doesn't eliminate them entirely. Sometimes, the why behind a decision isn’t obvious from the code alone.

Here’s an example where a comment adds value:

// We use a 7-day buffer to account for timezone discrepancies in legacy systems
var expirationDate = DateTime.Now.AddDays(7);

This kind of comment explains why something is done, not what is being done. That distinction is key.

Use comments to:
  • Explain business rules or domain-specific logic
  • Justify workarounds or technical debt
  • Provide context for non-obvious decisions
Avoid comments that:
  • Repeat what the code already says
  • Try to explain confusing code that could just be rewritten

The Real Cost of Poor Naming

We recently worked with a client who brought us in to modernize a legacy system riddled with bugs. The biggest challenge? The code was a mess of cryptic variable names, massive methods, and zero structure. Some classes literally had 100,000+ lines of code and if/else nesting 12 levels deep. It was nearly impossible to tell what anything did.

Simple changes like fixing a validation rule or updating a report were taking 10x longer than they should have. Every fix risked breaking something else because the code was so hard to reason about.

The takeaway? Clean code isn't just a nicety. It’s a multiplier for your team's velocity and confidence.

Final Thoughts

Self-documenting code is one of the simplest things you can do to improve your codebase. It's about writing code that's easy to read, easy to change, and easy to trust.

Start with better names. Extract logic into small, focused methods. And when you need to explain a why, leave a thoughtful comment.

Next time you're tempted to write a comment, ask yourself: Can I just make the code clearer instead?

About Latitude 40

Latitude 40 integrates experienced on-shore software development professionals into your organization, forming collaborative teams with or without your existing developers. Together, we identify needs, create tailored software solutions, and instill best practices that drive continuous improvement and ensure agility.

Need help cleaning up a messy codebase or modernizing your system? Let’s talk.

About the Author

Andrew Anderson is the President of Latitude 40 and a lifelong advocate for clean, maintainable code. With over two decades of experience as a developer, analyst, and Agile coach, he's worked globally to help teams build better software and embrace sustainable delivery practices.
View my profile on LinkedIn
0 Comments

Forget Hybrids: Agile Didn't Need Fixing

7/2/2025

0 Comments

 
A Scrum team is collaborating on a software project. The driver is typing while the others observe and provide feedback.
In prior posts, I explored how most Agile teams begin with Scrum, evolve into Kanban, and eventually move beyond frameworks into a principle-driven way of working. This natural progression reflects maturity; not a rejection of structure, but a deeper understanding of what Agile truly means. In this post, I want to address a common detour on that journey: hybrid frameworks. While often well-intentioned, they rarely solve real problems and can even slow down Agile growth.

​Misapplication and "Control"

Most of the friction organizations feel with Agile doesn’t come from the frameworks themselves. It comes from lack of leadership's understanding of Agile principles, conflicting policy, and tight controls. Agile teams aren’t meant to be managed into compliance. They’re meant to learn, adapt, and evolve.

True agility comes from a solid foundation and lots of experience. Teams need space to experiment, reflect, and grow. Frameworks like Scrum provide structure early on, but that structure is meant to teach, not to constrain. When leadership tries to enforce Agile through rigid rules, they prevent teams from gaining the empirical knowledge that Agile depends on.

Agile isn’t a flexible process layered onto a rigid organization. It’s a mindset that enables the organization itself to become flexible (to pivot quickly, respond to change, and evolve with its customers). If leadership isn’t ready to support that kind of learning environment, no framework will deliver the results they’re hoping for.

​Scrum and Kanban: The Originals Still Deliver

Scrum teaches discipline, rhythm, adaptability, and reflection. It’s a foundation, not just a beginner’s framework. It gives teams hands-on experience with Agile principles and helps them build the habits that make agility sustainable.

Many teams start with Scrum because it provides structure and guidance. As they mature, they often evolve toward Kanban to optimize for flow and responsiveness. Eventually, the most experienced teams go beyond frameworks entirely, adapting their practices to fit the situation, not the other way around. This isn’t abandoning structure. It’s graduating from it. The mindset becomes the method.

When teams struggle with Agile, it’s rarely a framework’s fault. It’s usually due to lack of training and organizational policies that don’t support Agile practices.

Even in larger organizations, where multiple teams need to coordinate, the answer is clarity and alignment, not a heavyweight framework. When teams share a clear product vision, have a unified backlog, and are staffed with experienced Agile practitioners, they can collaborate effectively without adding layers of process.

A single product owner, well-defined priorities, and trust in the teams’ ability to self-organize often go further than any scaled framework. Agile works at scale when the fundamentals are strong.

​Mixing Concepts Isn’t Mastery

Hybrid frameworks often emerge when teams face organizational resistance or lack clarity. Instead of evolving naturally, they adapt to dysfunction and mix roles and rituals in ways that dilute accountability and obscure purpose.

True Agile evolution isn’t about combining frameworks. It’s about mastering the principles and applying them with intent.

Scrum and Kanban are complete systems. They don’t need to be cobbled together with parts from other frameworks. When practiced correctly, they provide everything a team needs to deliver value, adapt to change, and continuously evolve.

Final Thought

​Agile was right the first time. The values and principles laid out in the Agile Manifesto still hold. Scrum and Kanban embody those values in clean, teachable, and scalable ways.

If your team is struggling, don’t reach for a structured hybrid. Look at your organizational policies. Look at your leadership expectations. And then go back to the basics. They still work.

About Latitude 40

​Latitude 40 integrates experienced on-shore software development professionals into your organization, forming collaborative teams with or without your existing developers. Together, we identify needs, create tailored software solutions, and instill best practices that drive continuous improvement and ensure agility.

Agile works. We’ll help you prove it. Contact us today.

About the Author

Andrew Anderson is President of Latitude 40 Consulting and a seasoned .NET developer with over 20 years of experience in Agile software delivery. As a Scrum Alliance CSPO (Certified Scrum Product Owner), he works with teams embedded in client organizations, building custom applications and teaching Agile through hands-on collaboration. Andrew promotes sustainable agility rooted in principles, not rigid frameworks.
View my profile on LinkedIn
0 Comments

Clean Code: The Strategy Pattern in C#

6/30/2025

0 Comments

 

Introduction

In software development, writing code is only half the job. The real challenge (and the real cost) comes later, when that code needs to change.

That's why maintainability is one of the most important qualities of a healthy codebase. Clean, modular code reduces bugs, accelerates onboarding, and supports business agility.

One pattern I find myself using frequently is the Strategy Pattern. It's a simple but powerful way to eliminate brittle if/else logic and replace it with clean, extensible design. In this post, I'll walk through a simple yet realistic example of different order pricing models and show how the Strategy Pattern helps us write code that's easier to understand, test, and evolve.

Setting the Stage: Dynamic Pricing Strategy

Let's say you're building a custom order system for a horticulture company. Different clients get different pricing strategies:
  • Retail customers pay full price.
  • Retail loyalty customers get a percentage discount.
  • Wholesale customers get a volume discount based on order volume.

Before: The Classic If/Else Trap


public class PricingService(IWholesaleDiscountRepository wholesaleRepo,
    LoyaltyProgramSettings loyaltyProgramSettings)
{
    public decimal CalculatePrice(Customer customer, Order order)
    {
        if (customer.Type == CustomerType.Retail)
        {
            return order.BasePrice;
        }
        else if (customer.Type == CustomerType.Loyalty)
        {
            return order.BasePrice * (1 - loyaltyProgramSettings.DiscountRate);
        }
        else if (customer.Type == CustomerType.Wholesale)
        {
            var tiers = wholesaleRepo.GetDiscountTiers()
                                      .OrderByDescending(t => t.MinQuantity);

            var discount = tiers.FirstOrDefault(
                t => order.Quantity >= t.MinQuantity)?.DiscountRate ?? 0m;

            return order.BasePrice * (1 - discount);
        }

        throw new InvalidOperationException("Unknown customer type");
    }
}

What's Wrong?

  • The PricingService is doing too much with its branching logic and different calculations. Real-life scenarios will likely be much more complex too (like wholesale volume discounts are probably based on seasonal order volume, not a single order's volume).
  • Depending on the complexity of your real-world scenario, you may want to apply the Open/Closed Principal, and that is impossible in this example.
  • The logic is not modular - you can't reuse or test pricing strategies independently.

After: Strategy Pattern

Let's refactor this using the Strategy Pattern.

Step 1: Define the Strategy Interface


public interface IPricingStrategy
{
    decimal CalculatePrice(Order order);
}

Step 2: Implement Strategies


public class RetailPricingStrategy : IPricingStrategy
{
    public decimal CalculatePrice(Order order) => order.BasePrice;
}

public class LoyaltyPricingStrategy(LoyaltyProgramSettings loyaltyProgramSettings)
    : IPricingStrategy
{
    public decimal CalculatePrice(Order order)
        => order.BasePrice * (1 - loyaltyProgramSettings.DiscountRate);
}

public class WholesalePricingStrategy(IWholesaleDiscountRepository discountRepo)
    : IPricingStrategy
{
    public decimal CalculatePrice(Order order)
    {
        var tier = discountRepo.GetDiscountTiers()
                        .OrderByDescending(t => t.MinQuantity)
                        .FirstOrDefault(t => order.Quantity >= t.MinQuantity);

        var discountRate = tier?.DiscountRate ?? 0m;
        return order.BasePrice * (1 - discountRate);
    }
}

Step 3: Strategy Factory


public interface IPricingStrategyFactory
{
    IPricingStrategy GetStrategy(Customer customer);
}

public class PricingStrategyFactory(IServiceProvider provider)
    : IPricingStrategyFactory
{
    public IPricingStrategy GetStrategy(Customer customer) => customer.Type switch
    {
        CustomerType.Retail
            => provider.GetRequiredService(),
        CustomerType.Wholesale
            => provider.GetRequiredService(),
        CustomerType.Loyalty
            => provider.GetRequiredService(),
        _ => throw new NotSupportedException("Unknown customer type")
    };
}

Step 4: Application Code


public class OrderProcessor(IPricingStrategyFactory pricingStrategyFactory)
{
    public void ProcessOrder(Customer customer, Order order)
    {
        var strategy = pricingStrategyFactory.GetStrategy(customer);
        var price = strategy.CalculatePrice(order);
        ...
    }
}

Conclusion

The Strategy Pattern isn't just a design tool. It's a way to build systems that are easier to understand, extend, and maintain.

In the example above, we started with a data-driven pricing model that worked, but was tightly coupled and procedural. By refactoring with the Strategy Pattern, we separated concerns and made each pricing rule modular.

This kind of architecture pays off in real-world scenarios:
  • New pricing models can be added without touching existing logic.
  • Each pricing model can be independently unit tested and verified easier.
  • Business rules could potentially be loaded from configuration or external sources.
  • Developers onboard faster and changes are easier/faster, because the code is easier to reason about.

These aren't just technical wins, they're business wins. Clean code reduces risk, accelerates delivery, and supports long-term agility.

About Latitude 40

Latitude 40 integrates experienced on-shore software development professionals into your organization, forming collaborative teams with or without your existing developers. Together, we identify needs, create tailored software solutions, and instill best practices that drive continuous improvement and ensure agility.

Need help modernizing your codebase or designing maintainable systems? Let's talk.

About the Author

Andrew Anderson is the President of Latitude 40 and a seasoned software architect with over two decades of experience in development and Agile delivery. He's worked globally as a developer, analyst, and coach, and is passionate about helping teams build software that is both powerful and maintainable.
View my profile on LinkedIn
0 Comments

The Agile Journey: From Scrum to Kanban and Beyond

6/3/2025

0 Comments

 
A Kanban team member adding testing task to Kanban board
In my previous blog post, I reflected on how Agile has stood the test of time and how most teams begin their journey with Scrum and often evolve into Kanban. I’d like to expand on that idea now by exploring what this evolution looks like in practice and how teams grow through experience, internalizing Agile principles, and eventually moving beyond frameworks into a more fluid, value-driven way of working.

Why Teams Start with Scrum

When teams first adopt Agile, they often start with Scrum, and for good reason. Scrum provides structure, rhythm, and clear roles that help teams internalize the principles of Agile. But more importantly, Scrum teaches through experience. And that experience lays the foundation for deeper agility. The ceremonies, timeboxes, and artifacts create a safe environment for learning discipline, collaboration, and iterative delivery.

What Scrum Experience Teaches You

Scrum isn’t just a framework; it’s a proving ground. Through lived experience, teams absorb Agile values in ways no training or documentation can replicate.

Communication & Collaboration

Scrum encourages frequent, informal communication. Teams learn that great software comes from great conversations, whether refining a story, clarifying a stakeholder request, or observing user behavior. Cross-functional collaboration becomes the norm.

Delivery & Feedback

​Scrum promotes frequent delivery of small increments, which sparks feedback and helps shape the product direction. Agile isn’t just about responding to change, it’s about helping the business discover what it really needs.

Visibility, Prioritization & Flow

Scrum makes work visible and manageable. Teams learn to track progress, surface bottlenecks, and prioritize based on value and risk. They also learn to maintain a sustainable pace.

Agile Values in Action

Scrum brings the Agile Manifesto to life. Teams experience firsthand why working software matters more than documentation, why responding to change beats sticking to a plan, and why collaboration drives better outcomes than rigid processes.

Estimation & Story Definition

Scrum reveals the art and pitfalls of estimation. Teams learn to avoid premature or pressured estimates and to rely on well-defined stories. Good stories (clear, independent, negotiable, valuable, estimable, small, and testable) are the foundation of accurate planning and momentum.

Why Kanban Comes Next

As teams mature, they begin to shed scaffolding. They stop relying on timeboxes and ceremonies. They start focusing on flow, limiting work-in-progress, and delivering continuously. In short, they evolve into Kanban teams.

Kanban offers some freedom, but only to teams that know how to use it. It emphasizes:
  • ​Visualizing work
  • Limiting work-in-progress
  • Managing flow
  • Continuous delivery
For teams that have mastered the fundamentals, Kanban is a natural next step. It removes the artificial boundaries of sprints and lets teams optimize in real time.

Beyond Kanban: Agile Without a Framework

Moving from Scrum to Kanban isn’t a rejection of Scrum, it’s a sign of maturity. Scrum teaches discipline and collaboration. Kanban allows teams to apply those lessons with agility and precision.

But the journey doesn’t end there.

Eventually, many teams evolve beyond any formal framework. They stop asking “Are we following the process?” and start asking “Are we delivering value?” Agile becomes second nature. Teams inspect and adapt continuously, choose tools and practices that fit their context, and focus relentlessly on outcomes.

This is where Agile truly shines as a mindset embodied in everyday decisions.

Final Thoughts

Start with Scrum. Learn the rhythm. Build the habits. As your team matures, you’ll likely evolve into Kanban and beyond. Don’t be surprised if one day you stop asking which framework to follow and start asking how to deliver more value. That’s evolution.

About Latitude 40

Latitude 40 integrates experienced on-shore software development professionals into your organization, forming collaborative teams with or without your existing developers. Together, we identify needs, create tailored software solutions, and instill best practices that drive continuous improvement and ensure agility.

Ready to evolve your Agile practices and build software that adapts with your business? Let’s talk about custom solutions that deliver clarity, speed, and value.

About the Author

Andrew Anderson is President of Latitude 40 Consulting and a seasoned .NET developer with over 20 years of experience in Agile software delivery. A long-time Certified Scrum Product Owner, he works with teams embedded in client organizations building custom applications and teaching Agile through hands-on collaboration. Andrew promotes sustainable agility rooted in principles, not rigid frameworks.
View my profile on LinkedIn
0 Comments

Ten Years Later: Agile Is Still Delivering

4/16/2025

0 Comments

 
A collaborative Agile team is working together building custom software solutions
​About ten years ago, I wrote a series of blog posts that explored the core meetings of Scrum: Sprint Planning, Daily Scrum, Sprint Review, Retrospective, and Backlog Refinement. Each post focused on the mechanics of these ceremonies, but the deeper message was about Agile mindset itself, one built on adaptability, transparency, and continuous improvement. Over time, this approach has proven more enduring than any single framework.

Fast forward to today, and that mindset hasn’t lost a bit of relevance.

While the Agile landscape has expanded to include countless frameworks and hybrid models, I’ve found that the fundamentals still hold up. For most teams, that means starting with Scrum, evolving into Kanban, and eventually moving beyond frameworks altogether into a more fluid, principle-driven approach to Agile where the mindset matters more than the method. Scrum and Kanban remain excellent starting points, teaching core Agile principles without the overhead and dilution that often come with hybrid approaches.

These posts reflect the foundational practices that helped many teams, including ours, begin their Agile journey. They remain relevant today, even as teams evolve toward more fluid, principle-driven approaches:

Here’s a look back at the original posts:
  • Sprint Planning: Where alignment begins.
  • Daily Scrum: A daily check-in that keeps teams focused and connected.
  • Sprint Review: A moment to inspect progress and adapt based on real feedback.
  • Retrospective: The engine of continuous improvement.
  • Backlog Refinement: Keeping the work ahead clear and actionable.
​
Agile isn’t about chasing trends or layering on complexity. It’s about staying responsive, building trust, and delivering value. Scrum and Kanban continue to teach these principles effectively, but the real power of Agile emerges when teams internalize the mindset and apply it fluidly, beyond any single framework.

About Latitude 40

Latitude 40 integrates experienced on-shore software development professionals into your organization, forming collaborative teams with or without your existing developers. Together, we identify needs, create tailored software solutions, and instill best practices that drive continuous improvement and ensure agility.
​
Agility starts with the right team. Talk to us about building custom solutions that deliver.

About the Author

Andrew Anderson is President of Latitude 40 Consulting and a seasoned .NET developer with over 20 years of experience in Agile software delivery. A long-time Certified Scrum Product Owner, he works with teams embedded in client organizations building custom applications and teaching Agile through hands-on collaboration. Andrew promotes sustainable agility rooted in principles, not rigid frameworks.
View my profile on LinkedIn
0 Comments

Custom Software: The Only Way To Maintain Long-Term Control

3/5/2025

0 Comments

 
Picture
​When choosing software to run your business, for your own safety, it may be wise to avoid creating dependencies on other companies. Those dependencies create specific types of risk that can lead to undesired consequences down the road.

Off-The-Shelf Software Dilemma

When choosing an off-the-shelf software package, you do not own the product in any way, shape or form. This means you do not have control over its future. It may do what you need now, but there is no way to know for certain what it will turn into later or how long it will last before being sold to another company or simply discontinued.

We had a customer years ago needing quick help to build a custom ERP solution after having used another popular industry-specific off-the-shelf product for many years that was abruptly discontinued. The product was purchased by another company who then immediately discontinued it and tried to force its clientele onto another completely different (and expensive) platform without giving them much time to come up with an alternate solution. While we can hope that most companies will not resort to this type of unethical behavior, it does illustrate what can happen when you don’t control the product you use.

Aside from that extreme example, other common complaints include:
  • Unwanted changes to your product are suddenly forced through, sometimes causing disruption to your business.
  • You may want specific changes that you can never get approved. This means you are not free to change anything within your company when you’d like to. Any major changes within your business may require a completely new software package.

Custom Software Can Be Better, but...

​By commissioning your own custom software, you can stay in better control. You can change the product whenever you’d like, and you won’t ever be subject to unwanted changes. There are still some things to watch out for, though.

3rd Party Tooling Within Your App

It’s a good idea to try and limit any 3rd party tooling being used within the app. There can be a tendency to try to plug in pre-built components into your app to save some time and money. Sometimes this is still the right thing to do, but some of these tools are so simple that it may be easy to build them yourself so you aren’t subject to the same problems described above with off-the-shelf software packages, albeit on a smaller scale.

​A while back, we were using a popular database technology internally within some of our custom software applications we’d written for various customers, and one day that technology was purchased by a large firm to be used internally and was taken off the market completely. This left our customers in an emergency situation and they needed quick help to adapt.

Maintainable Code

​The quality of the source code is another critical factor that is often overlooked. Custom software should be clean and architected in a way that makes it easy to maintain/change later when you need it to. How to accomplish this as an architect and developer is a large topic that has been evolving for years. There are literally thousands of books that have been published over the last many decades on this subject and the best technical people will always be looking for further improvement. It’s an important aspect of quality that ensures any future developer will be able to easily pick up and continue working on the platform when needed. This reduces the risk of being locked into a single development firm and allows for smoother transitions if you decide to change providers. 

Source Code Ownership

Another thing to make sure of, is that you retain the ownership of the source code itself. We still occasionally have customers find us after paying quite a sum of money to another company to develop their applications, only to find out later that they didn’t own it and would have to pay much more to get their hands on the source code. This has led to many legal battles, so before starting a new project with a development firm, be sure to check the fine print. If you discover the clause that does not give you ownership, run for the hills. This is a relatively common, although disdainful and underhanded practice that says a lot about the firm.
​
If you follow this advice, you will always have the option to move on to another development firm in the future for any reason whatsoever. You may also want to bring the development in-house someday.

Conclusion

​Custom software solutions offer numerous benefits that help businesses maintain their independence compared to off-the-shelf software. By owning the source code and ensuring maintainable code quality, businesses can avoid unnecessary dependencies and retain control over their software. Consider custom software solutions to enhance your operational flexibility and control, and to stay ahead in your competitive market.

About Latitude 40

​Latitude 40 integrates experienced on-shore software development professionals into your organization, forming collaborative teams with or without your existing developers. Together, we identify needs, create tailored software solutions, and instill best practices that drive continuous improvement and ensure agility.
Secure your business against software uncertainty--talk to us about custom solutions

About the Author

Andrew Anderson is President of Latitude 40 Consulting and a seasoned .NET developer with over 20 years of experience in Agile software delivery. He helps businesses build maintainable, high-quality custom applications while fostering agility through collaborative, principle-driven development practices.
View my profile on LinkedIn
0 Comments

Why Offshoring Fails

2/8/2025

0 Comments

 
Picture
Quality as an objective has diminished as companies have jumped onto the offshoring bandwagon, subscribing to the idea that this type of development is both cost-effective and efficient. However, reality says something different. This approach often leads to miscommunicated requirements and subpar results where you are left with a product that doesn't meet expectations. This forces you to either cope with the flawed outcome or abandon the project at a substantial loss. Abandoning your investment is rarely appealing, so companies often end up spending more money on ongoing support for buggy software. In the end, you spend much more than you should for an inferior product. We have seen this scenario play out repeatedly over the last couple of decades.

To be fair, some projects do succeed, but the success rate is poor. By offshoring, you leave your success up to chance rather than building something that guarantees an advantage over your competition. Quality software is still a noble objective and is achievable despite the widespread shift towards the “cheaper” offshoring model.

​What Makes Offshoring Risky & Ineffective?

  1. Communication Gaps: The distance and language barriers create significant communication issues. Misunderstandings and delays are common, leading to misaligned expectations and outcomes.
  2. Overhead Costs: Larger consulting firms often sell you on the idea that increasing headcount will speed up the project. However, this adds unnecessary overhead, making the process less efficient. Smaller, more focused teams are often much more effective despite what they may have told you.
  3. Cultural Differences: Different working cultures and time zones can lead to misaligned work ethics and expectations, further complicating things.
  4. Lack of Accountability: When working with offshore teams, accountability can become diluted. A good team will feel a sense of self-responsibility for the product they are creating, but that is difficult to have when they feel so far removed from their client and the people they are trying to help. This is escalated in cases where your team is scattered around the world. All the other barriers listed here expound on this problem.
  5. Hidden Costs: While hourly rates may be lower, hidden costs such as extended timelines, additional management, and other overhead can quickly add up, making the project more expensive in the long run.
  6. Quality of Developers: There are certainly quality developers all over the world, but since you are so far removed, you may be leaving this crucial aspect up to chance.

The Solution: Local Agile Teams​

Local teams well versed in agile practices working together in a cohesive environment offer a stark contrast to the pitfalls of offshoring. Here’s why:

  1. Direct Communication: Being in the same location allows for face-to-face meetings as needed, real-time collaboration, and immediate feedback. This minimizes misunderstandings and ensures everyone is on the same page, reducing the communication gaps that plague offshore projects. Agile practices rely on such direct and continuous communication.
  2. Empowered Teams: Local teams can take full ownership of their work, fostering a sense of self-responsibility and accountability. Teams learn to manage their progress and quality standards leading to a lack of the need to micro-manage.
  3. Cultural Alignment: Sharing the same working culture and time zone eliminates the friction caused by cultural differences and asynchronous communication. This alignment leads to more cohesive and efficient teamwork, which is essential for agile practices that rely on close collaboration and quick iterations.
  4. Stronger Team Dynamics: Working closely together fosters a sense of camaraderie and teamwork. This leads to higher morale, better problem-solving, and a more dedicated effort towards achieving the right results. Smaller, focused teams can be more effective and agile, avoiding the overhead costs associated with larger offshore teams.
  5. Consistent Quality: With local teams, you have better control and insight into the development team, ensuring that you get skilled developers who are committed to delivering high-quality work. This reduces the risk of leaving the quality of developers up to chance. Agile practices emphasize continuous improvement and high standards of quality.
  6. Long-term Relationships: Building a local team allows for the development of long-term working relationships, which can lead to more consistent and reliable project outcomes. These relationships are harder to establish and maintain with offshore teams. Agile teams benefit from stable, long-term collaborations that enhance their effectiveness over time.

​Investing in local agile teams is not just about avoiding the pitfalls of offshoring; it's about ensuring the success and quality of your projects. By working with a local team that embraces agile principles, self-responsibility, and self-organization, you can build something that is truly excellent and that you can control better over the long-term.

About Latitude 40

​​Latitude 40 integrates experienced on-shore software development professionals into your organization, forming collaborative teams with or without your existing developers. Together, we identify needs, create tailored software solutions, and instill best practices that drive continuous improvement and ensure agility.
Stop gambling with your software quality. Build with a local team you can trust.

About the Author

Andrew Anderson is President of Latitude 40 Consulting and a seasoned .NET developer with over 20 years of experience in Agile software delivery. He helps businesses build high-quality custom applications by forming collaborative, onshore teams that apply Agile principles to improve communication, accountability, and long-term success.
View my profile on LinkedIn
0 Comments

Optimizing Development Teams for Project Success

5/18/2020

0 Comments

 
One common question our customers have been asking for years is, “Can we just start with 10 devs to get our app done quickly?” While it is true that adding resources can speed things up, you have to be aware that you will not get a linear increase in overall productivity. The law of diminishing returns definitely applies here. In other words, if a team of 3 developers can finish a project in 4 months, you will not cut that time in half (deliver after just 2 months) by doubling down on developers. Every project is different, but 3 extra devs might not even buy you 1 month which means that you need to budget financially for the difference.

Why is this the case? Every developer you add creates a certain amount of overhead. There is simply more coordination required within the team, more “management” time (yes, even when handled collectively by the team itself), more opinions that need to be discussed during sprint meetings, potential conflict among team members that needs to be resolved, etc. This overhead increases exponentially as each developer is added.

What this means is that at a certain point, adding another development resource might actually start slowing the team down. We’ve experienced these types of situations where the performance solution was to reduce the size of the team.

So is there any other way to speed up your project? Well you might be able to find ways to increase efficiency within a team, but most professional agile teams are constantly doing so already. So really the practical answer is no. If you need to speed up, you might just have to add resources and pay for the overhead. Just be mindful of how far you take it because the strategy could backfire.

For larger projects, you might consider creating multiple teams instead of one very large one. If you do so, make sure you make each team responsible for separate bounded contexts to help reduce potential conflicts between the work that each team is doing.

On the flip side, we have customers ask, “How can we keep this as cheap as possible?” Well, you might now think that hiring a single developer would be the most economical way to get your project done when the timeline isn’t a concern. Disregarding the inherent risk in having just one developer involved in your project, this also isn’t the case. Getting your project done will likely require many skillsets which will not be found in one developer alone. Also, one developer working alone, regardless of skill level, is not nearly as impactful as he/she would be within a team. As a social species, we all need other people to talk to, bounce ideas off of and get general advice and support from. If your goal is to create a quality piece of software that works well, is maintainable, and can handle changes that you’ll throw at it over a long period of time, then you should give your developers what they need to be productive, which is a good cross-functional team to work in.

Therefore, at a minimum you should consider a team of 2-3 developers for your small project. A team of 2 is very minimal, but is infinitely better than 1 if funds are lacking. Scale up (with caution) as needed to meet your timeline and other requirements. Larger projects tend to have more complexity and require more skillsets. If you are missing a required skillset, that will negatively impact quality and the timeline. Again, cautiously build up as needed, and be mindful of the potentially negative impact any added team members might have.

Agile evangelists state that a team of 5-9 is the optimal size for a team, but 5 devs on a really small project is overkill. We also don't like to go above 7 devs on larger projects. If your project is large enough to require that many developers, then you should be able to create separate teams which would likely be more effective. Again, there are always exceptions and each project is different but this is what we've found to be most successful.

About Latitude 40

Latitude 40 integrates experienced on-shore software development professionals into your organization, forming collaborative teams with or without your existing developers. Together, we identify needs, create tailored software solutions, and instill best practices that drive continuous improvement and ensure agility.

Don’t just add developers—add direction. Latitude 40 builds teams that deliver.
​
Contact us today to discuss how we may be of help to your organization.

About the Author

Andrew Anderson is President of Latitude 40 Consulting and a seasoned .NET developer with over 20 years of experience in Agile software delivery. He helps organizations build right-sized development teams that deliver high-quality software through collaborative, principle-driven Agile practices.
View my profile on LinkedIn
0 Comments

On Things Packaged: Presidents and Software

8/3/2016

 
I’m certainly not wanting to engage in a political discussion here, but it did occur to me that what we’re dealing with in this upcoming election… and every election of my lifetime, are two ‘packaged’ candidates.  They never seem to really ‘fit’ exactly what I’m looking for in a candidate for president.  In fact, that seems to be the theme for everything out there… houses, cars, packaged software!
 
Here’s a thought.  What if you could have a custom presidential candidate?  What if you could choose what experience they had?  What if you could align their political beliefs and strategies to ‘fit’ exactly what you need in a president?  That would be pretty awesome!  Of course, we may have 150 million candidates for president in each election!
 
Since we’re stuck with ‘packaged’ presidential candidates, why should we be stuck with ‘packaged’ software?  It may seem like that is often the only option.  After all, building a custom house is so much more expensive and only for people with lots of money, right?  Same thing with software, right?  Well, I don’t have to tell you the ‘cost’ of something is only in the price tag.  Is it more expensive to buy a house that doesn’t have the kitchen you want, the flooring you want, the basement you want, the landscape you want, the deck you want, the paint you want?   These are all things you could ‘pay’ to improve… or customize and get at some point.  Or you could just settle and deal with what you bought.
 
Or, what about finding the right architect, the right home builder and having them build you a home that has the right kitchen, flooring, basement, landscape, that ‘fits’ your needs exactly?  Or better yet, what about partnering with a custom software development firm (insert shameless Latitude 40 plug here) to build a software application that ‘fits’ your business processes… exactly?
 
So this November (actually every month), choose custom software over packaged software and move your business forward into the future with software built specifically for you… and vote for whichever candidate ‘fits’ you best!  

<<Previous
Forward>>

    Categories

    All
    Agile
    Claris
    Clean Code
    Custom Vs. Off The Shelf
    Forecasting ROI
    On-shoring
    Technical
    Tech Strategy

    RSS Feed

Copyright © 2025 Latitude 40 Consulting, Inc.  All rights reserved.
Latitude 40® is a trademark of Latitude 40 Consulting, Inc. All other trademarks are the property of their respective owners.
Picture
11001 W. 120th Ave. ​Suite 400
Broomfield, CO 80021
303-544-2191
CONTACT US
privacy policy
terms of service
blog index
customer login
  • Home
  • About Us
    • Who We Are
    • How We Work
    • Our Quality Standards
    • How We Forecast ROI
  • Solutions
    • Custom Software
    • Explore Solutions
  • Successes
    • Case Studies
    • Testimonials
  • Insights
    • Blog
    • ROI Guides
  • Contact