In 2002, I began working as an Oracle database administrator at a government agency. Most people in the Netherlands know about the agency because it processes traffic fines. Therefore, it isn’t popular with the general public, just as the Internal Revenue Service isn’t. If someone asked who my employer was, I kept it vague and said the government or the Department of Justice. It didn’t take long before something went seriously wrong. On my second day on the job, one of the production systems crashed after running the batch jobs, leaving the database corrupt. In hindsight, that was a bit peculiar. After three days of searching, which included a weekend, I still hadn’t found the exact cause. When the operator restored the backup of the previous evening, which was still valid, and ran the batch jobs, the database became corrupt again. It was probably a software bug, so I advised restoring the backup from the previous evening and upgrading the database software to see if that would solve the issue. Instead, the IT director declared a crisis and set up a multidisciplinary task force to address it.
The head of the task force was a corpulent project leader who decided we should find the cause, which I hadn’t uncovered. I just wanted to fix the problem. Every day at 10 AM, there was a meeting to discuss the state of affairs. Every day, I proposed to upgrade the database software to see if it would help. And every day, my proposal was brushed aside. I would have done it myself, but I was a brand-new hire and didn’t have sufficient access rights. And the agency used VAX VMS, an unfamiliar operating system, so I couldn’t install software or restore backups myself. Two weeks later, after the experts had weighed in and after hiring a database corruption expert from Oracle, the cause remained elusive, and managers were getting desperate. Finally, they were willing to consider my suggestion. And it solved the problem. It was a harbinger of things yet to come. During the review, they grilled me for not being interested in researching the cause. I was not a team player and said solving a crisis was more important because it was a production system, so the users needed it to work. And the upgrade demonstrated that it was a software bug.
If you had prejudices about the government, my employer didn’t dispel them. You expect red tape, risk-avoidance, rule-following, and the like. It was all there. One department excelled. If you made the request incorrectly, they would do nothing, even when it was clear what they had to do. You couldn’t disturb them between 10 and 11 AM when they were discussing the work. They didn’t seem to do much, so what did they discuss for 1 hour a day? Some colleagues may remember my so-called crusade against bureaucracy. I often made jokes about bureaucracy and solved problems while ignoring red tape. Still, we perform our job effectively and efficiently, as traffic offenders would agree. And results matter most. Governments are bureaucratic because they implement rules.
Everywhere you go, some people work hard, while others take it easy. I have seen people doing little in corporations for profit as well. At my first project at Cap Volmac, we did nothing for months. Still, I have the impression that the pace of work in the government bureaucracy is, on average, slower than in the private sector. It is hard to put a number on it, but there is a difference. There is less pressure. Decisions take time and require more meetings. This is not a representative picture of the entire public sector. Police officers and teachers may experience stress. But most bureaucrats live calm lives. The hours you work for your employer are working hours. Cap Volmac required me to invest private time in education and corporate meetings. Finally, government employment is more secure.
When I came to work there, another database administrator, Dirk-Jan, a senior who had done several other jobs and hadn’t been a database administrator for long, was already there. After two months, Kees arrived, and from then on, we were three. Kees had a technical background. A few years later, Rene also joined the team. The agency also hired a security officer, a guy in a suit who soon began to make our work harder with unnecessary procedures. For instance, we had to lock up our Oracle manuals in a secure location after work and bring the keys to the porter’s lodge. But our manuals were public information like Windows manuals. Today, you can find this information on the Internet.
At the same time, the system that processed traffic fines had a superuser named after the system itself, with a password equal to the system’s name. Several other systems had the same issue, so the superuser and its password were the system’s name. I notified the security officer, but, being a true bureaucrat, he had more important things to do, such as attending meetings, inventing procedures, and preparing management reports. He added the issue to his list. But an issue like that called for immediate action. And so, I contacted a few senior programmers, and together we fixed that problem.
There were other issues with access rights as well. As they would say in the Professional Skills course, ‘There was room for improvement.’ If a new employee came in, the service desk made a ticket stating, ‘Create user account X as a copy of account Y,’ and sent it from one department to another. Usually, it took two weeks for the ticket to pass through all our departments, and system administrators made errors along the way. Hence, account X was rarely identical to account Y. If people switched departments or left, the defunct access rights were usually not deleted. Perhaps the audit department had figured this out, as our management soon launched a role-based access rights (RBAC) project.
RBAC works like so. You have a role in a department. In ordinary language, it is your job. For your job, you need access to an array of systems. Your job description determines which rights you need, for instance, to read specific data or change it. As a rule, employees should not receive more access rights than necessary to perform their tasks. RBAC is about the rights an employee in a specific job role needs. Business consultants came in and defined job roles and access requirements. A programmer then built an administrative database. However, the database didn’t connect to our systems, so there was no guarantee that the access rights in our systems matched the administration. And if you know how things fare in practice, you know that the administration would soon become stale and pointless. People are lazy, prone to errors, and forgetful. That would change once the administration and our systems are connected. If the administration was wrong, people couldn’t do their jobs properly, so it had to be accurate.
In 2004, I began building DBB, an account administration system, using Designer/2000, while keeping the bureaucrats out of the loop because they would likely stand in the way and make it harder for me. Only my manager and a few colleagues knew about it. DBB automated granting and revoking access rights in our systems, the RBAC way. It took me nine months, as I also had to do my regular work as a database administrator. But when I was ready to implement DBB on the production databases, bureaucrats became aware of what was happening and tried to block it. In their eyes, this was wildcat development. There had been no meetings, nor were there piles of reports to justify it. In early 2005, I introduced it sneakily with the help of the people from the service desk who wanted to use it. They installed the DBB client programmes on their personal computers. And I was a database administrator, so I could install anything I wanted on any database.
The results exceeded anyone’s expectations, including mine. The service desk created the accounts, so the tickets didn’t have to pass through all those departments. We could issue accounts in one day instead of two weeks. The service desk could reset passwords on the spot instead of relaying the request to a department, reducing the time to reset passwords from hours to seconds. And the access rights accurately reflected job roles. So, once DBB was operational, the opposition crumbled, and DBB became a regular application, even though not an official one, which was an essential distinction for bureaucrats. And so, we had RBAC fully implemented.
The DBB logo was a drawing by my wife. She had made it for another purpose. It features several jokers grinning at a set of file folders. To me, these folders symbolised bureaucracy. DBB joked with the bureaucrats, who considered it a rogue system. Supposedly, I was one of those jokers, so I made one of them my avatar on the Internet. DBB was my love child, just like Fokker once was Jürgen Schrempp’s, and for a while, I was overly attached to it. I ensured DBB could survive if I left my employer by producing design documents and manuals. I also built DBB in accordance with accepted Designer/2000 practices. We employed Designer/2000 programmers to maintain DBB. However, I hadn’t followed the proper procedures when building and implementing it, so it never became official. If something went wrong, it was not a mere incident, as would be the case with an official system, but a reason to replace DBB. That is bureaucratic reasoning at its finest. Something went wrong once, which allowed a high-ranking bureaucrat to block further development of DBB.
There have been two projects to replace DBB. In 2006, the first effort stalled because the planners had underestimated the complexity of the matter. They might have thought, ‘If one guy can do it, how difficult can it be?’ In 2016, a new project team realised it was pointless to replace DBB, as it was doing fine, while doing so would have been costly. The newer Java systems ran on Postgres databases and used web access. They did not use DBB. Our management planned to decommission the old Designer/2000 systems so DBB could retire by then. By 2024, DBB finally retired after nearly twenty years of service.
Bureaucrats have a unique way of doing things. In the case of serious incidents, they began filling out a ticket in the incident administration and discussing who should do what, while I pursued the issue. And sometimes, I had fixed it before others had finished filling in their forms. And I didn’t bother filling in forms. The system for which uptime was the most critical went down the most often. The solution was to reboot the system, but the operators hesitated and waited for a management decision. I said, ‘Just do it!’ And then they did. If it went wrong, they could blame me. I didn’t have the rank to make the decision for them and would have received a grilling if it went badly. But time was of the essence. The database was on an Oracle RAC cluster, a cutting-edge technology that had yet to mature. And that was so for a reason. It had to be operational at all times.
American software corporations like Oracle usually launch their products fast and aggressively market them. If customers buy them, they use the sales proceeds to improve these products and make them work properly. That gave American software corporations the lead over their European counterparts because Europeans believed you needed a good product before you could sell it. That was quite naive. Long before their product was good enough, the Americans owned the market and had the budget to make it better than the European product. In this way, Americans discarded failed products without investing much in them, saving costs. So, Oracle RAC on VAX VMS was not a great idea because RAC was in its infancy. At the same time, VMS was an exotic operating system with few customers, making fixing RAC bugs on VAX VMS a low priority for Oracle.
Not surprisingly, the system regularly malfunctioned, preventing users from accessing it. RAC is a cluster of machines accessing the same database. The idea behind RAC was that if one of those machines crashed, the others would remain operational and the database would remain accessible. In reality, the machines often went down in unison because of communication errors caused by the RAC software. And because the whole point of Oracle RAC was to have less downtime, you could do better without it. The crash corrupted the machine’s memory, and looking for the cause was pointless because it was a bug in Oracle software for which there was no fix. The only thing we could do was reboot these machines, which meant shutting them down and restarting them. That would wipe the memory clean, and the system would work again. I figured that out after one time, so the next time, when the symptoms were the same, I didn’t hesitate. The system was critical. It had to be up always. That was why it was our only RAC system. Otherwise, the police might not identify criminals. It was a database with the records of criminals dubbed Reference Index Persons, and the Dutch acronym was VIP, so the Very Important Persons for the Department of Justice.
Bureaucrats often seem to value rules over outcomes, which made me wonder what they were thinking. It could be something like, ‘If I mess things up, no one can blame me if I stick to the rulebook. But if I do the right thing but do not follow procedure and something goes wrong, my job is on the line.’ If something goes wrong, the government hires consultants to investigate the issue and propose changes to the procedures to prevent it from happening again. Consultants thus write piles of reports and make a lot of money on government contracts. Sadly, the next time, the situation may be different, and then it goes wrong again. Over time, the proliferating rules grow unwieldy.
It might make you think it is better to do away with procedures, but that is not a good idea. The proliferation of rules reflects the increasing complexity of society. It is not a problem that you should see in isolation. When a large apartment building burns out, you see once again why there are strict building regulations concerning these skyscrapers. If you aim for fewer regulations, you build these things in the first place. The government’s task is to provide and enforce these rules. There may be room for improvement. It begins with not creating the problem that gave rise to the regulation. Our office processes traffic fines. If we stopped driving cars, most of our work would be redundant. And perhaps, we should give people more responsibilities, but that means accepting that things sometimes go wrong. The result may be that fewer things go wrong.
DBB not only joked with the bureaucrats, but also with me. In June 2010, I received a highly unusual request from a system administrator to manually drop a user account. That hadn’t happened for several years. DBB usually handled that, but it failed to drop this particular account for an unknown reason. The username was ELVELVEN. If you read that aloud, you say eleven elevens in Dutch, referencing the 11:11 time-prompt phenomenon that had once haunted me for a while. Usernames consisted of the first one or two characters of the employee’s first name, followed by the employee’s last name. In this case, the user’s last name was Velven. I don’t remember the first name, but it wasn’t Elvis. To me, 11:11 signals a combination of two related unlikely events. And indeed, the joke had a part two, and it was even more peculiar.
In 2014, during testing of an improvement to DBB, the test indicated that an unauthorised account had infiltrated our systems. The username was the first character of the first name, followed by the last name of the Lady from the Dormitory. Had She been employed by us, this would have been Her username. Her name isn’t common, so this was unnerving, especially since it was the only username that popped up in this list of sneakily inserted accounts. It couldn’t be Her, or could it? It turned out that a guy with the same last name as Hers had worked for us. His first name began with an A as well. And the account wasn’t illegal. I had mixed data from two different dates in the test, which made it appear that this account had sneaked in illegally. But imagine the odds of only this account popping up on that list.
In 2005, after completing DBB, my manager wanted to give me a promotion, and he only wanted to give it to me. My colleague Kees was a tech genius, and he set up the RAC system while I made DBB, so I said he was better than me. My manager responded with the prophetic words, ‘You have the right vision and make it happen despite the opposition. That is far more important than technical skills.’ DBB solved pressing problems using proven technology, while the RAC system only created problems. We used to reduce system downtime, but it produced system crashes, resulting in more downtime. Somehow, I had become his favourite, and that wasn’t because he was such a good manager. He seemed the type of career guy who never stays long in one job. You know the type. He says he will clean up the mess his predecessor left behind and then hares off after a year or two towards his next challenge, claiming he has put things on track, only for the next manager to come in and claim he will clean up the mess.
He never put his promise in writing, despite my repeatedly requesting that he do so. Just before he left, I pressed him again. As the promotion had not yet come through, he wrote that there would only be a minor wage increase, then filed it with the human resources department for processing. A few weeks later, they summoned me to the human resources department. A personnel officer had raised a technicality. It wasn’t against the rules, but against their policies. And so, I couldn’t even keep the minor wage increase. That was a breach of contract, plain and simple, but to a bureaucrat like a personnel officer, only rules and procedures count. It would have been possible to fix this within the rules, but there was also a thing called policy, so they didn’t. My previous manager had already left, and they blamed him for not following proper procedure. His temporary replacement didn’t care, as he was also on his way to another job. After putting a lot of effort into getting it in writing and with my manager already fobbing me off with a minor wage increase, they gave me nothing. I was angry and walked out of the meeting.
After arriving home, my wife told me that a freelance agency had offered me a job. It was the first offer of this kind in years and the first time since working for the CJIB. I was already considering leaving. That made me make a rash decision and resign. In hindsight, it was a noteworthy coincidence that the freelance agency had called me on this particular day. It didn’t take long before I did get second thoughts. Out of the blue, a strong feeling emerged that the decision was wrong. I can rationalise it by saying there weren’t many jobs for database administrators near home. The issues with my son didn’t allow me to work far away from home, while my physical condition didn’t allow for long travels. That may all be true, but these considerations were not the real reason. And I had done freelance work before, so it was not fear of being self-employed. And a government job didn’t seem right for me. But the feeling grew so strong that there was no choice but to reverse course and try to undo my resignation.
Pride is a poor counsel, so I reversed course. There was a new manager, Geert, and he accepted my change of mind. He pledged to do his best to restore my confidence in my employer. He seemed trustworthy, but actions matter more than words. A year later, he promoted Kees, but not me. Due to a bureaucratic technicality, there was only one position. And perhaps also because Kees was his favourite. That didn’t restore my confidence, so I began to distrust him. Geert was still planning to promote me. He gave me financial compensation, so the situation didn’t result in a financial loss. And after several years of bureaucratic wrangling, the promotion finally came through.
Latest revision: 2 December 2025
The Plan For The Future 