Technical debt is like refusing to fix a leaking roof because it's raining - only to forget about it when the sun comes out.
In this article, I'd like to share some thoughts on computing in professional environments, especially from an engineering perspective. These are based on over 18 years of experience in software and insights gathered from three years of observing workflows and speaking with veterans across industries - financial services, banking, retail, and engineering alike.
The financial industry is used here as an example - not because it is uniquely flawed, but because it is highly relatable and emblematic of issues in many complex corporate environments. The emphasis here is on computing infrastructure, though the discussion touches on organizational and human factors, which are often inseparable in real-world implementations.
As an engineer, I strive for system coherence and comprehensibility. Complexity is natural and even necessary. Complication, however, is a human failure - and preventable. This piece is not about client-facing technologies, but about the internal systems, processes, and philosophies that make a corporation function, scale, and evolve.
Summary
This article is long, so here's the TL;DR:
- Avoid most commercial cloud services unless absolutely necessary.
- Minimize hierarchies.
- Use Azure DevOps (ADO) for task management (there is no equivalent that offers the same integration).
- Provide scriptable, reusable interfaces for historical analysis and reporting (e.g., Grafana, TradeView).
- Use SQL (raw or wrapped) throughout your stack for ETL.
- Avoid PowerBI for anything mission-critical.
- Never use Excel in production.
- Invest in tailored tools for core business functions (e.g., custom accounting platforms over QuickBooks).
- Consider interactive simulations or serious games for training.
- Design your enterprise as API-first, not "AI-first" (AI-first is often just a buzzword).
- Prefer locally deployed AI models, ideally under your control.
- Underpinning all of this is a core belief: existing practices are broken, and a new paradigm is needed.
While Divooka (our own platform) embodies this philosophy, this is not an advertisement. Any platform that addresses the same core issues is welcome - though in years of searching, I've yet to find one that does.
Motivation
For both individuals and teams, the drive for faster workflows and better tools is ultimately about insight. In complex business environments, speed enables iteration, and iteration enables clarity. This is just as true for corporations as it is for individuals. But iteration only works if tools are adaptable.
Hence, the efficiency of problem-solving is directly tied to the efficiency of developing custom internal tools.
For large institutions - national pension funds, tier-one banks, or multi-national insurance firms - this goes beyond tooling. You need:
- Layered access control
- High-frequency analysis
- Security
- Training pathways for new hires (e.g., interns)
More importantly, data accessibility - real-time, API-based, version-controlled - is what drives real analytical agility. Security is not just a technical problem - it is a cultural and process problem.
Top-down visibility is also essential. Leadership should be able to trace any issue through systems with a single click. If they can't, the system has failed - not because of complexity, but because of poor design.
And while executives don't need to understand every implementation detail, they must understand the principles - and more critically, invest in education both for themselves and for entry-level employees. A longer-term view builds resilience, retains talent, and enables innovation.
Making the Best of Existing Tools
Cloud computing has made off-the-shelf infrastructure appealing - but this convenience comes at a cost. Over time, the lack of control becomes a liability, especially at scale. High-performing organizations must eventually invest in internal capabilities.
It is always cheaper in the long run to take matters into your own hands - if you can attract and retain technical talent.
Additionally, code review must be mandatory for anything related to automation - whether for internal dashboards, accounting tools, or production pipelines. Not just for QA, but for education and sustainability.
In software development cycles, a healthy time division might look like this:
- 1.5x Analysis/Modeling
- 1x Development
- 0.5x Code Review
- 0.5x QA
Financial organizations should also standardize on microservices to simplify endpoint access and reduce cross-system coupling.
For any company that uses the word "agile" unironically: Azure DevOps (ADO) remains the gold standard for work item tracking, integrated version control, testing, and pipeline automation.
A critical warning: Beware the proliferation of internal dashboards. While it may seem counterintuitive, the tendency to build highly visual dashboards is a distraction from what matters - reliable APIs, scalable infrastructure, and actual automation.
"API-first" saves 80% of the effort in the long term compared to building UI-first.
The Peer Developer Model
Financial analysts are de facto computing professionals. Any work at scale is computational. And yet, most organizations underinvest in bridging the gap between analysis and implementation.
There are two solutions:
- Invest in training analysts to code (bite-sized, structured, mandatory).
- Assign companion developers - dedicated engineers working side-by-side with analysts.
This is similar to how civil engineers complement architects. The developer's role: implement, optimize, and review code, leaving analysts free to model and interpret.
A junior-to-mid-level OOP developer (familiar with C-family languages) costs \~\$100K and can support 2–3 analysts effectively. This model reduces headcount while increasing productivity.
The Integrated Big Picture
Eliminating redundant tech stacks is the single most powerful way to reduce technical debt. In most organizations, essential functions are scattered across dozens of tools, each requiring specialized training.
The solution is to build reusable internal libraries, APIs, and tooling ecosystems around key functions (data ingestion, transformation, reporting, access control). And yes, this requires investment - but for a firm managing billions, it's well worth it.
Open-source solutions often provide better APIs and lower long-term cost. But the goal isn't cost reduction per se - it's control, efficiency, and resilience. Cost savings will follow.
The All-Rounded Technical Analyst Model
Divooka is our vision for what this looks like in practice: a unified computing platform combining:
- Enterprise-grade C#
- SQL-dominant ETL pipelines
- Python's rich data science ecosystem
- A modular, plugin-based architecture
- Low-code/no-code visual programming
- Fully local, one-click deployment
The result: self-contained, auditable, maintainable pipelines that cover 90%+ of analytical needs, with fewer components and shallower learning curves.
This abstraction allows analysts to become full-stack operators - no longer needing to juggle five tools for one task.
The winning stack: C# + Divooka + Python + PostgreSQL + ADO + GitHub + microservices.
Related Topics
These toolsets raise natural questions about hiring and training:
- What kind of analysts should we hire?
- How fast can we get them productive?
From an engineering standpoint, we want people with structured programming experience - even in entry-level roles. No one flies a plane without a license; why run production data systems without proper coding fundamentals?
Traditional programming bootcamps won't suffice. But a modern analyst can get up to speed in 3 months - if trained with the right curriculum: Excel + SQL + Divooka (Yes, Excel is still needed for practical reasons). That's all you need for 80% of the analytical workload.
Conclusion
This article outlines an ideal - but attainable - vision for computing in complex industries.
These problems can be solved with or without technology. But solving them well requires the right mindset, structure, and investment. Every organization has unique needs, and solutions should be iterative, adaptive, and people-centered.
If any part of this resonates with your experience, I'd be happy to continue the conversation.
Changelog
20250509 Rev 001: Initial draft.
20250520 Rev 002: Refine ideas.
20250609 Rev 003: Adjust wording and refine ideas, staging for publication.
20250620 Rev 004: Polishing.
See also