LATITUDE 40
  • Home
  • About Us
    • About
    • Our Process
    • Quality Please
    • What Is Custom Software?
  • Services
  • Case Studies
  • Buzz
    • Blog
    • Testimonials
  • Contact

Latitude 40 blog

Reducing Your Risk of Change Through Thoughtful, Incremental Improvement

10/29/2025

0 Comments

 
New stairs take you gradually up to the top of the mountain with clear, blue skies above.
Change is risky. But stagnation is riskier.

At Latitude 40, we work with organizations that know they need to evolve, but want to do so without jeopardizing what's already working. Whether you're refining internal processes, upgrading systems, or rethinking how teams operate, the safest and smartest way to move forward is usually through thoughtful, incremental improvement.

The Hidden Risk of Standing Still

It's tempting to delay change in the name of stability. But over time, that stability becomes fragility. Processes grow outdated. Systems become bottlenecks. Teams adapt in ways that mask deeper issues. The longer you wait, the harder it becomes to respond when change is finally unavoidable.

In today's environment, stagnation isn't neutral, it's a liability. The cost of doing nothing often exceeds the cost of doing something imperfectly.

So how do you move forward without introducing unnecessary risk?

Why Big Change Often Backfires

Many organizations respond to mounting pressure with sweeping, all-at-once transformation. New systems, new processes, new roles. Everything changes at once. But this “big bang” approach often creates more problems than it solves.

Operations get disrupted. Teams feel overwhelmed. And the assumptions baked into the plan (however well-intentioned) don’t always hold up in practice.
​
Even when large-scale change is necessary, trying to solve everything up front assumes you already know the right answers. But in reality, the best solutions often emerge through deeper thought, experimentation, and iteration.

The Power of Moving Deliberately

Incremental improvement isn’t about moving slowly. It’s about moving intentionally. It allows you to:
  • Refine your approach as you go: Each step is a chance to learn, adjust, and improve the next.
  • Think deeply and experiment: Some problems require exploration. A phased approach gives you room to test ideas before committing.
  • Avoid analysis paralysis: You don’t need a perfect plan to start. You just need a smart first step.
  • Deliver impact early: Small wins deliver value early without waiting for a full overhaul. They also build momentum and confidence.
This mindset helps reduce risk, preserve continuity, and build trust across the organization.

Custom Software: A Natural Fit for Continuous Improvement

One of the most powerful enablers of incremental change is custom software.

Imagine a continuous improvement team moving through your organization, tackling whatever is most important at the time. They identify bottlenecks, streamline workflows, and improve outcomes. But when they encounter rigid, off-the-shelf systems, progress stalls. The software becomes a bottleneck unable to adapt to the evolving needs of the business. Even if the software was the perfect fit originally, it may no longer be.

Custom software changes that dynamic. It’s built to evolve. It allows your team to respond to insights quickly, implement changes without waiting on a vendor roadmap, and align technology with strategy in real time.
​
In short, custom software doesn’t just support continuous improvement. It unlocks it.

Our Approach at Latitude 40

We help clients identify the smallest meaningful change that moves them forward. Then we work alongside their teams to deliver it collaboratively. Whether that means building a custom application, creating integrations, refining a workflow, or enabling better decision-making, we guide change with purpose.
​
We don’t push transformation for transformation’s sake. We build solutions that support agility, experimentation, and long-term growth without introducing unnecessary risk.

Final Thought

Change doesn’t have to be scary. When it’s thoughtful and incremental, it becomes a source of strength. And when paired with flexible, custom-built tools, it becomes a competitive advantage.

Build momentum, not disruption. Let’s get started.

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.

About the Author

Andrew Anderson is the President of Latitude 40 and a seasoned technology leader with over two decades of experience in software development, architecture, and process improvement. He specializes in helping organizations achieve operational excellence through practical, low-risk strategies that deliver measurable results. Andrew’s approach combines technical expertise with a deep commitment to agility, guiding teams toward smarter solutions and sustainable growth.
0 Comments

AI-Washing: The New Greenwashing in Software

10/14/2025

0 Comments

 
Custom software is utilizing AI tooling for optimum results.

​The AI Hype Is Real - But So Is the Confusion

Artificial intelligence is everywhere… or at least, that's what the marketing says. From "AI-powered" dashboards to "intelligent" assistants, it seems like every software product has suddenly become sentient.

But when you dig beneath the surface, many of these so-called AI features are just automation in disguise. Automation is powerful and impactful, so that's not a criticism. But calling everything "AI" muddies the waters.

We call this AI-washing, and it's becoming the new greenwashing, the marketing trend starting in the 2000s where companies started exaggerating their environmental friendliness to appeal to eco-conscious consumers. Products were labeled "green" or "eco-friendly" without meaningful changes to how they were made or used.

Why AI-Washing Hurts

AI-washing happens when companies label something as "AI" to make it sound more advanced than it really is. Even when unintentional resulting from misunderstanding or overzealous marketing, the impact is real:
  • Clients chase complexity they don't need: Companies may worry that their current tooling isn't "AI-driven" and fear they're falling behind. This FOMO can lead to rushed decisions, vendor churn, and replacing perfectly good systems with more expensive, less maintainable ones.
  • Budgets balloon trying to implement tech that doesn't fit: AI often requires data pipelines, model training, monitoring, and specialized infrastructure. If the problem doesn't warrant that investment, it's wasted effort.
  • Trust erodes when "AI" doesn't deliver: When expectations are set by marketing rather than reality, disappointment is inevitable; and it reflects poorly on vendors and internal teams alike.
Sometimes all you need is good old-fashioned automation. A client recently came to us asking for an "AI-powered scheduling assistant." After a few conversations, it became clear they didn't need AI at all. They needed a rules-based system that could assign jobs based on technician availability and skillset. No machine learning required.

Automation and AI Overlap

Here's where the confusion often starts: automation and AI aren't opposites, and they're not interchangeable. They exist on a spectrum and often work together.
  • Automation handles predictable, repeatable tasks. It's built on logic, rules, and workflows.
  • AI handles uncertainty, pattern recognition, and probabilistic decision-making.
Sometimes, automation uses AI as an ingredient. For example, a document upload process might use an AI model to extract text from images or classify content, but the rest of the workflow is pure automation.

That doesn't make the whole system "AI-powered." But it also doesn't mean AI isn't involved in a very helpful way.

Not All AI Is Complex - And That's Okay

You don’t need a self-learning model running 24/7 to benefit from AI. Sometimes, a simple occasional use of AI (like using it to summarize a paragraph) is all you need.

That's still AI. It's just lightweight and task-specific.

The key is understanding what role AI plays in your system, and whether it's solving a problem that actually requires it.

When Complex AI Is Worth It

While some AI use cases are lightweight and task-specific, others truly benefit from deeper investment and deliver transformative results when done right.

For example:
  • Predictive maintenance systems in manufacturing use historical sensor data to forecast equipment failures before they happen. These models require training, tuning, and ongoing monitoring, but they can save millions in downtime.
  • Fraud detection in financial services often relies on anomaly detection algorithms that evolve as new fraud patterns emerge. These systems need constant refinement and access to large, diverse datasets.
  • Natural language processing for customer support can go far beyond simple chatbots. With the right training, AI can understand intent, sentiment, and context which can reduce support costs while improving the customer experience.
These aren't plug-and-play solutions. They may require:
  • Clean, well-structured data
  • A clear understanding of the problem space
  • Collaboration between domain experts and data scientists
  • Ongoing evaluation and iteration
But when the problem is complex, dynamic, and data-rich, AI may be essential to staying relevant.

How We Help Clients Cut Through the Noise

At Latitude 40, we don't lead with buzzwords. We lead with questions:
  • What problem are you trying to solve?
  • What decisions need to be made?
  • What data do you have?
  • What would success look like?
Sometimes the answer is AI. Sometimes it's automation. Sometimes it's just a better process. Our job is to help you figure that out and build something elegant, maintainable, and effective.

​AI is a tool. Automation is a tool. So is a thoughtfully designed workflow. The key is knowing when to use which and having a partner who can help you decide.

Final Thought

If you're evaluating a product or planning a new system, don't start with "we need AI." Start with the problem. Then find the simplest, smartest way to solve it.

That's how we work. And that's how we help our clients move faster, with or without AI.

About Latitude 40

Latitude 40 helps businesses achieve operational excellence and long-term business agility through tailored software solutions and expert guidance. By embedding into client teams, Latitude 40 delivers elegant, maintainable software while teaching Agile practices that foster sustainable growth. Latitude 40 builds with clarity, purpose, and a deep respect for the people who maintain and evolve code.

Have questions about incorporating AI into your custom applications? Let’s talk.

About the Author

Andrew Anderson is President of Latitude 40 Consulting and a seasoned software architect with over two decades of experience in developing Agile solutions. He's worked globally as a developer, analyst, and instructor, and is passionate about writing maintainable code and helping teams grow through clean architecture and the Agile mindset. Andrew shares insights from the field to help developers and leaders build better software, and better teams.
0 Comments

From Keywords to Meaning: How AI Powers Semantic Searches

10/2/2025

0 Comments

 

​Understanding Semantic Searches

Traditional keyword search is like looking for a needle in a haystack—if you don’t use the exact word, you might miss the match. Semantic search changes that by focusing on meaning rather than literal words.

Instead of searching through a database of book reviews for "Romance" or "Suspense", imagine typing:
  • "Get the heart racing" and finding reviews like:
    • "I couldn't put it down."
    • "It kept me up all night."
Or searching for:
  • "Excites the heart" and discovering:
    • "A passionate love story that lingers long after the last page."
      ​
Semantic search understands the search intent and emotion behind your query, not just the vocabulary. To make semantic searches possible, AI uses a concept called vector embeddings

​What are Vector Embeddings?

AI models convert text into vector embeddings—arrays of numbers that represent meaning in a multi-dimensional space.
  • Each word or phrase becomes a token.
  • These tokens are plotted in a space with hundreds or thousands of dimensions.
  • Words with similar meanings are placed closer together.
    ​
Think of it like a galaxy of ideas, where “thrilling” and “exciting” orbit near each other, while “boring” floats far away.

​A Cosine Similarity: Measuring Meaning

Once text is embedded into vectors, we need a way to compare them. That’s where cosine similarity comes in.
  • It measures the angle between two vectors.
  • A score near 1 means the vectors (and thus the meanings) are very similar.
    ​
Cosine similarity is the engine behind semantic matching.

Claris ​FileMaker’s New Semantic Search Features

Claris FileMaker Developers now have AI script steps that make semantic search easy to implement.
  • You can embed text, store vectors, and compare them—all within FileMaker and an AI Language Model from a company such as Cohere.
  • This enables smarter search experiences, like:
    • Matching user queries to emotionally resonant reviews.
    • Finding relevant content even when keywords don’t match for better workflow optimization.

​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 implement AI into 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: Mindset Over Dogma

9/18/2025

0 Comments

 
Developer is sitting at her desk with multiple monitors thinking about the design of a software system she's helping write.
Lately, I've seen a wave of criticism and developer backlash against clean code. They argue it's too rigid, too idealistic, and often counterproductive. They point to over-engineered systems filled with tiny methods, excessive abstraction, and unnecessary complexity, all in the name of "clean code."

But this criticism often confuses the mindset with its misapplication. Clean code isn't a checklist or a burden. It's a way of thinking about how your code will be understood, maintained, and extended by others.

The Mindset vs. the Mechanics

Clean code is not a set of rules to follow blindly. It's a mindset with a commitment to clarity, maintainability, and empathy for the next developer. The techniques commonly associated with clean code (like meaningful naming, small functions, and separation of concerns) are tools that support this mindset. They're not mandates.

When developers apply these techniques without understanding the why, they risk creating code that's technically "clean" but practically unreadable. The mindset encourages thoughtful application, not dogmatic adherence.

Why It Matters in the Enterprise

In enterprise environments, code lives longer, changes hands more often, and supports critical systems. Maintainability is a necessity. Clean code helps teams avoid technical debt, reduce onboarding time, and improve collaboration.

Even if you don't apply every principle, understanding the mindset helps you make better decisions. It's not about perfection. It's about writing code that others can work with confidently.

Clean Code Is Empathy in Action

At its core, clean code is about empathy. It's about writing software that respects the time and effort of others. It's about leaving behind code that's easy to read, change, and build upon.

This mindset fosters trust, reduces bugs, and makes teams more resilient. It's not just about how the code looks, it's about how it feels to work with.

Conclusion: Don't Reject the Mindset

Let's be clear: you absolutely shouldn't reject the clean code mindset. If you choose to skip the education and experience that comes from practicing clean code, you're not just avoiding a style. You’re limiting your growth as a developer.

Clean code principles teach you how to think about architecture, readability, and long-term maintainability. These are the skills that separate good developers from great ones. They're far more important than knowing the latest language features or syntax tricks.

Languages change. Frameworks evolve. But the ability to write code that others can understand, maintain, and extend is timeless.

About Latitude 40

Latitude 40 helps businesses achieve operational excellence and long-term business agility through tailored software solutions and expert guidance. By embedding into client teams, Latitude 40 delivers elegant, maintainable software while teaching Agile practices that foster sustainable growth. Latitude 40 builds with clarity, purpose, and a deep respect for the people who maintain and evolve code.

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

About the Author

Andrew Anderson is President of Latitude 40 Consulting and a seasoned software architect with over two decades of experience in Agile delivery. He's worked globally as a developer, analyst, and instructor, and is passionate about writing maintainable code and helping teams grow through clean architecture and practical Agile practices. Andrew shares insights from the field to help developers and leaders build better software, and better teams.
View my profile on LinkedIn
0 Comments

Don't Trust the Docs: Why API Documentation is Often Just Marketing

9/12/2025

0 Comments

 
A vibrant cityscape at dusk featuring large illuminated digital billboards advertising Coca-Cola Zero, Samsung, TDK, Hyundai, and Vogue. A red double-decker bus with an ad for
When evaluating third-party APIs, the documentation is usually your first stop. It's polished, promising, and full of potential. But here's the uncomfortable truth: API documentation is often more marketing than engineering. It's designed to sell you on the idea that integration will be smooth, powerful, and fast. What it doesn't show are the bugs, the limitations, and the painful workarounds you'll only discover once you're deep into development.

The Hidden Cost of Optimism

It's not just technical decisions that hinge on documentation; it's budgeting, timelines, and even product selection. Teams read the docs, see the capabilities, and assume they're real. They plan around them. They fund projects based on them. And when the reality doesn't match the promise, the fallout can be significant.

In one project we worked on recently, our client chose to use a major enterprise product largely because of its advertised integration capabilities. The documentation made it look like a perfect fit. But once we started building, we found that many documented APIs simply didn't work. Some returned internal server errors when used exactly as described. Others had bizarre side effects like updating one field and unintentionally clearing out others, forcing us to implement multi-step workarounds just to preserve data integrity where we could.

The client had already committed budget and resources based on the assumption that integration would be straightforward. Had they known the true state of the API, they might have chosen a different product entirely.

We've actually seen similar examples time and time again (which is why I decided to write about this).

Why Documentation Misleads

Most API documentation is written to attract business and developers, not warn them. It highlights features, not flaws. It shows clean examples, not edge cases. It never mentions:
​
  • Inconsistent or unstable endpoints
  • Poor versioning or breaking changes
  • Internal quality concerns within the product itself
  • Lack of support or slow bug resolution

Even SDKs and sample code are often designed to show the "happy path," not the real-world complexity of integrating with a system that is under-documented or poorly maintained.

How to Protect Yourself

Before you commit to an API, build a prototype. Don't just read the docs. Test the endpoints. Try the edge cases. See how the system behaves under real conditions. And look beyond the vendor's website:

  • Check GitHub issues and changelogs
  • Search developer forums and Reddit threads
  • Evaluate SDK quality and update frequency
  • Ask about support responsiveness and roadmap transparency

This may take some time and funding, but it is worth it!

Conclusion

API documentation is a sales pitch. It's useful, but it's not the whole story. Treat it like marketing material. It's something to be verified, not trusted blindly. Because once you've committed to a product based on fictional capabilities, the cost of backing out can be steep.

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

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.

​The Real Problem Isn’t Agile—It’s Misapplication and Control

Most of the friction organizations feel with Agile doesn’t come from the frameworks themselves. It comes from lack up 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 not just a beginner’s framework—it’s a foundation. 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 isn’t a heavyweight framework—it’s clarity and alignment. 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—mixing 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. 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

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—how teams grow through experience, internalize Agile principles, and eventually move 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—not as a set of rules, but 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—then 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 not rebellion—it’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
<<Previous

    Categories

    All
    Agile
    Claris
    Clean Code
    Custom Vs. Off The Shelf
    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
    • About
    • Our Process
    • Quality Please
    • What Is Custom Software?
  • Services
  • Case Studies
  • Buzz
    • Blog
    • Testimonials
  • Contact