Alan worked for Maria in the Books-and-Records department of a massive conglomerate. Her team was responsible for keeping all the historical customer transaction records on line and accessible for auditors and regulatory inquiries. There was a ginormous quantity of records of varying sizes in countless tables, going back decades.

Maria was constantly bombarded with performance issues caused by auditors issuing queries without PK fields, or even where-clauses. Naturally, these would bring the servers to their proverbial knees and essentially prevent anyone else from doing any work.

The Red Queen with Alice, from the original illustrations of 'Through the Looking Glass'

To solve this problem, Maria decided that all auditors and regulators would be locked out of the database for purposes of direct queries. Instead, they would be provided with an API that would allow them to mimic a where-clause. The underlying code would check to see if no PKs were specified, or if a where clause was missing altogether. If so, it would run the query at a much lower priority and the auditor issuing the offending query would wait while the servers did the massive scans in the background, so the other auditors could continue working with a reasonably responsive database.

So far, so good.

Alan wanted to build a mechanism to query the list of available tables, and the columns available in each. This could be provided via the API, which the auditors' developers could then programmatically use to create the objectified where-clause to submit as part of a query.

Maria would have nothing to do with that. Instead, she wanted to sit with each potential auditor and have them define every single query that they could possibly ever need (table(s), column(s), join(s), etc). Alan pointed out that the auditors could not possibly know this in advance until some issue arose and they had to find the data relevant to the issue. Since this would vary by issue, the queries would be different every time. As such, there was no way to hard-wire them into the API.

She put her foot down and demanded a specific list of queries since that was the only way to build an API.

Alan went to every auditor and asked for a list of all the queries they had issued in the past year. They grudgingly obliged.

Maria then went on to design each API function call with specific arguments required to execute the given underlying query. The results would then be returned in a dedicated POJO.

Again, Alan groaned that defining a POJO for each and every subset of columns was inappropriate; they should at least design the POJOs to handle the entire column set of the given table, and have getters that represented columns that were not requested as part of a given API query throw a column-not-queried exception. Maria said No and insisted on separate POJOs for each query.

Some time later, Alan had finished building the API. Once it was tested and deployed, the other development teams built relevant GUIs to use it and allow the auditors to pick the desired query and appropriate parameters to pass to it.

This worked well until an auditor needed to add a column to one of the queries. If Maria had let Alan use table-wide column pick-lists and POJOs that had all the fields of a table, this would have been easy. However, she didn't, and made him create another virtually identical API function, but with a parameter for the additional column.

Then it happened with another query. And another. And another.

After a while, there were so many versions of the API that the managers of the other teams blasted her choice of implementation (they had to deal with the different versions of the POJOs for each table in their code too) and demanded that it be made sane.

Finally, under pressure from above, Maria relented and instructed Alan to change the API to use the pick lists and POJOs he had originally wanted to provide.

To implement this required changing the signature of every method in the API. Fearing a riot from his counterparts, he got them all together and offered a two month window during which both old and new versions of the method calls would be supported. This would give their teams a chance to make the code changes without forcing them to drop their current priorities. The other developers and managers quickly agreed to the dual-mode window and thanked Alan.

Then a few of the other managers made the mistake of thanking Maria for the window in which to make changes.

She royally reamed Alan: "Did I tell you to give them a dual-mode window? Did I? You will immediately pull the old methods from the API and re-deploy. You will NOT email the other teams about this. Get it done; NOW!"

Alan had worked very hard to develop a good working relationship with his peers and their respective managers. Now he had been ordered to do something that was downright nasty and would absolutely destroy said relationships.

Alan changed the API, ran the tests, and entered the command to deploy it, but did not hit ENTER.

Then he quietly went around to each of the other managers, told them what he had been instructed to do and apologized for what was about to happen. He was somewhat taken aback when every single one of them told him not to worry; they had dealt with Maria before, that they appreciated his well-intentioned but ill-fated attempt to be a team player, and that they completely understood.

After that, he went back to his desk, hit ENTER, and contemplated asking the other managers if they could use a good developer.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!