A Month in the Basement: Designing an Absence System

It's not about a literal basement – but that state of flow mixed with determination when you face a single, massive challenge for weeks, consuming every unit of your energy and focus.

In my case, it was the 'final boss' of recent months: the full implementation of the absence module in a .NET web application integrated with Oracle DB.

The Scale of the Engineering Challenge

• This wasn't just another CRUD form. It was a challenging migration of complex business logic from a desktop application (C#/.NET) to a modern web environment. My task was to map intricate system rules ensuring that the end-user experienced no change in the program's stability.
• The task wasn't about rewriting code 1:1. I had to recreate and understand HR processes built within the company over years, where every condition had its historical justification.

Glossary: Action vs. Absence

• Action: A single system operation – from submitting a request and editing it, to final approval or rejection,
• Absence: A system record representing an employee's time away (e.g., vacation, sick leave, business trip), where each type follows its own processing lifecycle.

Why was it so difficult?

• Database Layer: A massive amount of PL/SQL code (procedures, functions, triggers) serving as the core business logic,
• Legacy codebase: Maintenance of critical modules dating back to 2005-2010, requiring extreme caution when implementing updates,
• Hybrid Logic: Business rules scattered between the .NET backend and the Oracle database, necessitating a holistic view when analyzing the impact of any changes,
• Reverse Engineering: Working with a legacy system without up-to-date documentation, requiring the reconstruction of logic directly from source code.

Biggest Challenge: Specific Data Selection Logic

The main hurdle was handling unique cases, such as assigning a family member to specific absence types. Unlike standard processes, these required implementing specific selection logic on the backend. I had to develop a dedicated mechanism to correctly process form data and integrate it with existing database procedures, ensuring the consistency of the entire process.

Complexity: ~40 Unique Absence Types

The system had to handle about 40 different types of absences. Each had its own set of validation rules and dynamically changing required fields. This wasn't just a static form – it was a mechanism that had to correctly react and adapt its logic based on the selected business context.

What did this month of work look like?

• SQL Developer as the main interface: Daily procedure analysis, database logic debugging, and data integrity verification,
• Visual Studio Debugger: Long hours tracing data flow from the frontend to the backend layer to ensure seamless integration,
• Team Collaboration: Consultations with senior colleagues to understand legacy design decisions and prevent regressions in critical modules,
• Regression Testing: Verifying every possible scenario—from simple leave requests to complex cases of overlapping absences.

Engineering Satisfaction

This month wasn't a streak of easy wins. It was a tough battle with technical debt and system complexity, which I can certainly call the biggest challenge of my career so far.

However, delivering this functionality — working, tested, and production-ready—gave me a massive boost in confidence. I proved that I can master even the most unpredictable parts of the system.

This experience taught me that being a developer is 20% writing new code and 80% understanding and fixing complex legacy. Sometimes you have to go down to the 'basement' and face the demons of old code to emerge as a much stronger engineer.