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 fixed issues without telling anyone. 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 plenty of people lazing in corporations for profit as well. At my first project at Cap Volmac, we did nothing for months, but it generated profit for my employer, so it made economic sense. Still, 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 in, there was already another database administrator, Dirk-Jan, a senior who had held several other roles and had recently become one. After two months, Kees came, and from then on, we were three. Kees had a technical education and was brilliant. A few years later, Rene also joined the team. There was also a security officer, a guy in a suit who soon began to make our work harder with procedures, so a true bureaucrat. We had to lock up our Oracle manuals in a secure location after work and bring the keys to the porter’s lodge. Our manuals were public information like Windows manuals, so there was nothing secret about them. And so, we made jokes like, ‘Now, the cleaners can’t break into our systems.’ Today, you can find this information on the Internet. Our management considered database administrators the most sensitive position due to our access to all the data, which led to overdoing things.
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.
Kees had built that RAC system. He was an innovator who liked working on new technologies, and he developed the RAC system with great enthusiasm. I was a problem fixer, and found innovation to be the greatest problem generator of all. It creates new issues while making good-working systems obsolete, so that you have to replace them with newer ones that generate more problems. There is always a reason, usually feature creep, so adding options you don’t need. In fact, all I did was bullshit, as humans managed without information technology until very recently. And now they can’t do without it, and they are locked in a process of mindless innovation they can’t escape. Obviously, I was the only one thinking this, so I mostly kept my peculiar opinions to myself.
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.
Many have thought it better to do away with red tape, which led to an ill-fated push for deregulation. We ended up with more regulations. It didn’t happen in isolation. The proliferation of rules reflects the increasing complexity of society. When a large apartment building burns out, you see once again why there are strict building regulations concerning these skyscrapers. If you give profit-maximising businesses some leeway, they will use inferior materials to boost their profits. So, if you aim for fewer regulations, you shouldn’t build these things in the first place. Otherwise, you have to be extremely careful, for any opportunity to profit will not go unused. And if something goes wrong, there will be costly court cases that benefit only one profession: lawyers. As a result, you pay more, not less, due to deregulation. So, the neoliberal effort of self-regulation failed. Apart from that, there is fraud, but sometimes the only difference is that fraud is illegal, so deregulation can be a way to make fraud legal. Complexity is a cause of failure.
The government’s task is to provide and enforce the rules that keep a society functional. So, if there are no cars, we could do with fewer traffic rules and close down our traffic-fine collection operation. That solves a lot of problems, as we don’t have to keep up all those systems. There is a lot of room for deregulation if you solve the problems that gave rise to the regulation. Ending the profit motive in business might solve many problems and render many regulations redundant, as businesses are always scheming to increase profits at the expense of the public. That generates new problems, but maybe we mistakenly believe that they are worse. And perhaps, we should more often accept that things can go wrong. They go wrong anyhow, and they keep on going wrong, whatever you do. The real problem is our desire that things should be perfect.
DBB joked not only 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 exceptionally good as a manager. Many of my colleagues weren’t particularly thrilled. 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 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 on his way to another job as well. 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, Ingrid told me that a freelance agency had called to offer me a job. It was the first offer of this kind in several years and the first time since starting work at the CJIB. As I was already considering leaving, I made a rash decision and resigned. In hindsight, it was a noteworthy coincidence that the freelance agency had called me precisely 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 near home for me. My son needed a father who was at home and could quickly return home in the case of an emergency, or so I believed. That may all be true, but that didn’t explain these strong feelings. And I had done freelance work before, so it was not a fear of being self-employed. And a government job didn’t seem right for me. Yet, there was no choice but to reverse course and try to undo my resignation.
Life had taught me that pride is poor counsel. A new manager, Geert, had come in, and he accepted my change of mind. My letter had not yet been filed with the personnel department, so the termination had not been initiated. He pledged to do his best to restore my confidence in my employer. He seemed trustworthy and acted as if he were my best friend. It later turned out that the process of creating a new job position was underway, and that the personnel department had misinformed me, likely because the employee didn’t know. Yet, once the position became available, Geert gave it to Kees. There was one position that my previous manager had promised me. That didn’t inspire my confidence. Yet Geert was planning to promote me as well. He gave me financial compensation, so the delay didn’t result in a financial loss. And after several years of bureaucratic wrangling, likely involving countless meetings and the like, the promotion finally came through.
Latest revision: 2 June 2026
The Plan For The Future 