I’ve always been the type to dive into things headfirst. Curiosity guiding me through life’s twists and turns. That restless spirit led me from military service in 1992, where I built a dBase system for vehicle maintenance at 8SAI (South African Infantry Battalion), to today as a Solutions Architect at Salesforce. Along the way, I learned some hard lessons about data quality, operational reliability, and long-term maintainability, specifically, lessons that have shaped me into the architect I am.

Early Years: Tinkering in Software

After my military stint, I returned to Cape Town with time on my hands. I spent those years getting my hands dirty in software engineering, obsessing over languages like C++ and Delphi XE while building systems for vessel monitoring and catch prediction using interpolation and thematic maps. It was a practical phase where language choice felt like a means to an end and unbeknown to me at that time, what really mattered was understanding the underlying problems.

Hardware, Data, and the Sea

My work on vessel monitoring systems (VMS) involved getting devices manufactured and writing drivers for hardware integration. This meant grappling with Iridium satellite receivers, GPS, cellular modules, Wi-Fi, and even acoustic telemetry through Doppler devices. The challenge was turning messy operational data into something useful and that historical catch data with twenty or more parameters required careful interpolation to generate map layers for scientific allocation and quota support.

GIS: Where Mistakes Are Mapped

GIS (geospatial systems) was a natural progression, offering immediate visual payoffs from my code. But it also taught me a harsh lesson: bad assumptions make for ugly maps. I built systems that looked perfect on paper but failed in the real world when noisy data hit. The lessons here were humbling with the realization that maintainable outputs depend on high-quality inputs, and GIS exposes your weak points more clearly than most business systems do.

The Command That Wiped a Database

A defining failure came in 1996 at a loans company, where I tried to clean up database indexes with a single command:

del *.dbf Instead of del *.idx

The result? A catastrophic data loss that taught me firsthand about the fragility of production systems and the importance of testing in controlled environments. It was a costly lesson, but one I’ve never forgotten.

Custom CRM: Discovering Structure

My own custom-built CRM taught me another crucial lesson: control without structure rots over time. As my systems grew more complex, I realized that governance required more than just data models, it needed boundaries of behavior and fallback paths to handle uncertainty. This led me towards a focus on architecture as a way to ensure stability and longevity in my designs.

Salesforce: Constraints for the Better

When I started working with Salesforce, I found it refreshing that the platform already enforced constraints through governance frameworks like Metadata API checks, Lightning App Builder limitations, and Apex code restrictions. These guardrails forced me to think architecturally from day one, designing with clear boundaries instead of just building without oversight.

Agentic Systems: Changing the Landscape

As Salesforce evolves towards more agent-assisted workflows (e.g., prompt-based interactions or autonomous decision making), I’ve had to adapt my architectural approach. Agentic systems bring non-deterministic elements into deterministic business processes, introducing new risks like unpredictable outputs, heavy dependence on data quality and context retrieval, and governance challenges around explainability and trust. This forces me to think beyond traditional flows and triggers, designing systems that can handle probabilistic components while maintaining audit trails and fallback paths.

The Long View: From Syntax to Systems

Looking back, my journey has been less about specific tools or platforms and more about evolving from syntax-focused coding to system-level thinking. I went from just “making things work” in my early days to designing with constraints that ensure scalability, governance, and adaptability. The world of software has changed, but the core lessons—respect for structure, discipline, and clear architecture—remain timeless.

Closing Thoughts

If you’re an engineer or architect just starting out, my advice is simple: question everything, don’t rush into production without testing, and prioritize long-term maintainability over short-term wins. And when you hit your first big failure (and you will), learn from it as those scars make you stronger in the long run.