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 for something to go seriously wrong. It went so seriously wrong so quickly that you might have suspected a curse if you had been of the superstitious type. On my second day on the job, one of the production systems crashed after running the batch jobs, leaving the database corrupt. 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 hired an Oracle database corruption expert, 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 didn’t play the political game of pleasing the higher-ups by telling them they were geniuses. I was fixated on results and said that solving a crisis was more important because it was a production system, and the users needed it to work. And the upgrade demonstrated that it was a software bug. So, what more was there to say?
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 in a most particular fashion. 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.
There is the prejudice that civil servants are lazy, and jokes about it. Why is there a line running down the middle of the corridors in town halls? It is to avoid bumps between civil servants who arrive late for work and those who leave early. And why do the windows in the ministries go all the way down to the floor? That allows them to look outside while lying down. 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 paid my salary and generated profit for my employer, so it was productive idleness that generated GDP and tax income. And above all, it was a voluntary agreement between a buyer and a seller in a market.
Nevertheless, 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. There is less pressure. Most notably, 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 many bureaucrats live calm lives. And whatever you do for your employer is working hours. Cap Volmac required me to invest private time in education and corporate meetings. Finally, government employment is more secure. If your job gets axed, you get preferred treatment in finding another job within the government.
When I came in, there was another database administrator, Dirk-Jan, a senior who had held several other roles and had recently become one, and a temporary hire who had caused some upheaval, the details of which are now unclear. Yet it is rather typical for database administrators to be loners who do things managers do not appreciate, and it is not a coincidence that I became one. You end up in a situation where you know best and others regularly demand that you do stupid things, so eventually you become like that. 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 a security officer, a guy in a suit on his way to the higher ranks, who soon began to make our work harder with procedures. 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. It is public information. We made jokes like, ‘Now, the cleaners can’t break into our systems.’ They needed passwords to get in, and even if they had them, they had no clue what to do, even with the manuals. 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. And that led them to demand that we do stupid 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. Everyone knew these passwords, which could ruin the system or manipulate data; this was also a serious concern because it was financial data. You could wipe out a traffic fine for a family member if you knew how. 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 without showing any understanding of its seriousness or urgency. That was the kind of stupidity database administrators had to deal with. I contacted the senior programmers, and together we fixed that problem.
There were other issues with access rights. 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 or change specific data. 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 were 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 get in the way and cause it to fail. Only my manager and a few colleagues knew about it. Officially, I was building a password reset screen and a role-granting screen for one system for the service desk to use, and I told my manager it would become a more general solution applicable to similar systems. And that it became. DBB automated the granting and revocation of access rights in our systems using RBAC. It took me nine months, as I also had to do my regular work as a database administrator. When I was ready to implement DBB, 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 for bureaucrats to evaluate. If you, as a manager, don’t know what is happening and some guy is organising the security of your most critical systems, you should be alarmed. So, their attitude was understandable. Yet they also showed no signs of working on the problem. In early 2005, I introduced it covertly with the help of people at 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. While making a test set and imagining job roles, the first one I came up with was ‘slave,’ a practical joke.
The outcome exceeded expectations. 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, the folders symbolised bureaucracy. DBB joked with the bureaucrats, who considered it a rogue system. It was a neat drawing. I took one of these jokers out and made it my avatar online. And so, I became the joker. You know the saying ‘using the joker’ for using the last option in a most desperate situation? Maybe you appreciate a good joke. It now seems a harbinger of things to come.
DBB was my love child, just like Fokker once was Jürgen Schrempp’s. I created design documents and manuals and built it in accordance with accepted Designer/2000 practices, so other programmers could take over if needed. Yet the problem was that proper procedures had not been followed during its development and implementation. If something went wrong, it was not merely an incident, as with the other systems, 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.
Two projects to replace DBB were initiated. 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. I went right on it. Sometimes, I had already 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 was still on the way to maturity. 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, running Oracle RAC on VAX VMS was not a great idea, since RAC was in its infancy. And VMS was an exotic operating system with few customers, making it a low priority for Oracle to fix RAC bugs on VAX VMS.
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 due to 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. 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 just loved working on new technologies. He had developed the RAC system with great enthusiasm. I was a problem fixer. Innovation generates new problems. It makes well-functioning systems obsolete, forcing you to replace them with newer ones that have more problems, leaving you with more work, complexity, and specialisms. There are always reasons for doing it. Usually, it is because others are doing it as well, often because old technologies run out of support, or due to feature creep, which is adding options you don’t need. That is how we dig ourselves deeper into the doodoo. Yet, I was the only one thinking this.
On top of that, and that is an entirely different issue, bureaucrats valued 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 slightly different, and the rules may not cover a particularity, and there you go again. The obvious solution is to write new reports and invent more rules.
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 promote me, but not my colleague Kees, the tech genius. He had 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, not because he was exceptionally good at his job. He seemed a 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. I had fixed a serious problem without any effort from his part. Yet, he could show it off as his department’s accomplishment.
He never put his promise to promote me in writing, despite my repeated requests. I feared that once he was gone, I would be left with nothing. 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. Now, that was already a bit of a disappointment. A few weeks later, they summoned me to the human resources department. A personnel officer had raised a technicality. And so, I couldn’t even keep the minor wage increase.
That was a breach of contract, plain and simple, but to a bureaucrat, 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, I was left with nothing, precisely as I had feared. 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 at my employer. It made me make a rash decision and resign. In hindsight, it was a noteworthy coincidence that the freelance agency had called me precisely on this day. It didn’t take long for the second thoughts to come. Worse yet, 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. 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. It was really an overpowering feeling. In these cases, 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 they didn’t know. Yet, once the position became available, Geert gave it to Kees. At the time, there was one position that my previous manager had promised me. It made me distrust Geert and fear he would dupe me, which he was going to do, even though not this time, but later on. 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, the promotion finally came through.
Latest revision: 9 October 2026
