"How Hard Can It Be?" Five of the Most Dangerous Words for Access Developers

As software developers, we tend to be eternal optimists.

We believe we can solve any problem given enough time and effort. This optimism serves us well in powering through difficult challenges. However, it can also lead us to bite off more than we can chew.  Developers—of all ability levels—often take on projects without fully appreciating the complexity involved.

After all, how hard can it be? Famous last words.

Complexity Sneaks Up on You

What appears simple on the surface can turn out to be deceptively complex. Business rules that seem straightforward during initial requirement gathering often gain exceptions and caveats as you dig into the details.

Take pricing as an example. At first pass, a product's price may depend on just a couple of factors:

• Product type
• Customer type

Simple enough. But upon further inspection, you find that:

• Certain products have minimum order quantities that affect pricing
• Customers fall into different tiers based on sales volume that impacts discounting
• There are special one-time promotional prices in effect
• Some products require additional services that incur fees
• Taxes vary based on product type and delivery location
• Currency conversions add another layer of complexity

What started as a basic calculation based on two factors has quickly expanded into a complex tangle of business logic.

Problems Can Exponentially Increase in Difficulty

Some problems appear trivial at small scale but become exponentially more difficult as the scale increases.

A classic example is Einstein's Five-House Logic Problem.  The puzzle consists of deducing the owners of five houses based on a series of clues. Solving this puzzle by hand took me nearly two hours, but it was at least feasible.

At five houses, the problem is tractable for a human to reason through. But expand the puzzle to 25 houses or 50 houses, and it quickly becomes impossible to solve manually.

In software, beware situations where you need to implement business rules that must scale across thousands or millions of records. The logic may be straightforward for a handful of records, but prove extraordinarily complex when expanded to enterprise scale.

How to Avoid Getting in Over Your Head

So how do you avoid inadvertently signing up for a nightmare project? Here are three techniques software developers can use to accurately assess the complexity of a potential project before agreeing to undertake the work:

• Break the project into sub-problems. Avoid thinking about the overall project and instead focus on the specific incremental problems that need to be solved. This prevents getting overwhelmed by the enormity of the full project.
• List assumptions and identify dependencies. What are you taking for granted as true that may require verification? What other systems or stakeholders will this project rely on? Making assumptions and dependencies explicit highlights areas of risk.
• Conduct pre-mortems not just post-mortems. Imagining all the ways a project could fail forces you to confront potential issues proactively instead of reactively.  Annie Duke refers to this technique as "mental time travel" in her excellent book, "Thinking in Bets."

Trust Your Gut When Something Feels "Off"

As you gain experience as an Access developer, you'll develop instincts for potential issues with project proposals. Pay attention when something feels "off" about a potential engagement.

Maybe the client insists the business logic is straightforward with no exceptions or special cases. Or perhaps they claim the data volumes will be minimal and performance is not a concern.

Oftentimes, Access project stakeholders leave out important details when initially describing requirements. They fail to mention special business rules, atypical data scenarios, or key integrations with other systems.

When you review a project proposal, beware if it seems overly simplistic. Ask probing questions to unearth missing information. Request examples of edge cases and exceptions to the standard rules.

No matter how much a potential client may try to pressure you by asking "How hard can it be?", don't let yourself get talked into a project until all assumptions have been validated. It's better to identify gaps in requirements early rather than be surprised partway through development.

Conclusion

Software projects often turn out to be much more complex than initially assumed. But by learning to identify areas of hidden complexity early in the process, you can avoid getting in over your head.

Next time you catch yourself uttering the infamous words "How hard can it be?", pause and thoroughly assess the problem. Leverage techniques like breaking work into sub-problems, documenting assumptions, and imagining failure scenarios to reveal the true difficulty involved.

While optimism helps fuel developers through challenging projects, unwarranted optimism leads to failure. Stay grounded in reality and don't let yourself get talked into something you aren't confident you can deliver.

Acknowledgements

• Initial draft generated with the help of Claude-2-100k
• Cover image created with Microsoft Designer