Showing posts with label Bloated Behemoth Enterprise. Show all posts
Showing posts with label Bloated Behemoth Enterprise. Show all posts

Monday, April 28, 2014

A Contrarian Resume

"Contrarians" are a kind of investor who wager against the conventional wisdom. Of course, the words extends beyond just the financial world.

TheHackerCIO is a contrarian.  

He sees no reason to respect conventional wisdom. Historical tradition isn't enough to justify decisions, policies, or edicts. They must be reality based. They must be true. They must make sense. They must have reasons and good ones that justify their prescriptions.  Otherwise, it's time to ignore them, or defy them with everything you've got.

ManagementSpeak, for example is the accepted convention.  Wikipedia explains that:
Corporate jargon, variously known as corporate speakcorporate lingobusiness speakbusiness jargonmanagement speakworkplace jargon, or commercialese, is the jargon often used in large corporationsbureaucracies, and similar workplaces.[1][2] It may be characterised by sometimes-unwieldy elaborations of common English phrases, acting to conceal the real meaning of what is being said. It is contrasted with plain English.
Readers of TheHackerCIO will recognize this as the  language of the Bloated Behemoth Enterprise. One of many pathologies found there.

This one has to be opposed with everything you've got. Why? Because it has evil purposes: dishonesty, evasion, pretense, concealment of truth, deliberate confusion to distract, or at best, a lack of candor, openness, or transparency.

And one of the most pernicious effects of ManagementSpeak is the nearly universal impact on resumes:

  • Boilerplate is mandatory. 
  • Never use a personal pronoun. 
  • Only 3rd person. 
  • Use acronyms to blast the brain. 
  • Ungrammatical Bullet points describing accomplishments which never even feature a subject, but start off with a verb, such as
    • Analyzed requirements with end users
                     instead of
    • I analyzed and discussed requirements and features with key users.
  •  Then, since the result is so mind-stultifying, no more than 2 pages of that, thank you very much.

What brought this to mind was that I applied for a job. The e-submission had a check box for a free resume evaluation, so I unchecked that box, having no desire for more spam to deal with. Naturally, the software ignored my selection and the next morning I had my free evaluation. I immediately clicked the link to unsubscribe, and haven't been troubled again, luckily.

But ...

I read their "eval." ; and it was evil.

They wanted $300 to fix these problems:
1. It was too long.
2. It had a personal pronoun.
3. There were deceitful ways to as they put it "minimize," short term assignments.

Needless to say, TheHackerCIO isn't coughing up hundreds of bucks to get his resume into conventional shitform. But he has been acutely aware that rewrite-time was nearing. Now I just have to do it. Starting as soon as I post this, I'll be doing a full top-to-bottom rewrite.

Contrarian resume is coming. I'm going to be 100 percent grammatical, spelling out the first person for every one of my many accomplishments. It's all about me, as indeed it should be, being my resume, so "I" and "me" are going to be a major element. (I'll report here later with the final count, so be sure to check back here in a couple of days. UPDATE 2014-05-02: I counted at least 60 instances of self-reference, including I, Me, I'll, I'd, and so forth. ) I also will pay no attention to length at all. I will only concern myself with showcasing relevant experience. If I fall one word over to another page, that's the way it's going to be distributed. If it takes 10 pages, so be it. I'm going to highlight my short-term projects, as well, by explaining that the instability was the clients, not mine. I might even mention that I resent them for it.

In short it's going to be fresh, honest, clear, relevant, personal, non-deceitful. It's going to be a blast to write it.

Never yield to evil. It leaves a bad taste. And you won't find happiness that way...

I Remain,


Monday, April 14, 2014

I'm not asking *For* a cable; I'm asking *About* one

Ahhhh, The trials of boutique consulting!

Upper Service organization management decreed to TheHackerCIO that "You are to make no further requests for anything, until further notice. Just keep your head down and do your work. Let us make the requests for things to the end-user." So, all requests for things ended.

But progress was most crucially being held up for want of an ethernet cable! It went like that nursery rhyme:
  • for want of a cable, the device to server went unconnected ...
  • for want of a connected server, the testing became deferred ...
  • for want of testing, the delivery was impeded ...
  • for want of delivery, the project slipped ...
  • for want of completion, (not the battle, but ...) the contract was lost!?!?!?
TheHackerCIO is not for losing a contract. Not on my watch. So he bought one. But he made a crucial mistake ... 

He mentioned in an email that he already had a hub and cable to resolve the connectivity issue. 

So another edict came down "All devices installed on the network must be approved first by the CTO." Damn. He was now forced to reply, "The devices which would resolve this issue are now locked away in my desk, unopened and not to be used until further notice." Double Damn.  Even just the cable would have helped, but now it was out of bounds. 

This is why people hate the pathological politics of the Bloated Behemoth Enterprise!

Luckily, a friendly network tech stopped by in the break room as I and an honorable colleague were getting a cup of coffee. "Anything you need?" He asked. So TheCraftyHackerCIO replied as follows:
"We could really use an Ethernet cable. But we have been instructed not to ask for anything. So I'm not asking for an Ethernet cable; I'm asking about one. What do you think?" He nodded with a grin. And so the problem was solved. 

The immediate problem, that is. The problem of Bloated Behemoth Enterprise pathology remains. Always. 

I Remain,


Tuesday, October 29, 2013

New Wine or Technology In Old Bottles!

"Neither do men put new wine into old bottles: else the bottles break, and the wine runneth out, and the bottles perish: but they put new wine into new bottles, and both are preserved." [ref]

New technology used in old ways also breaks them and leads to pathological systems. The best summary and critique of this pathology, as it exists in Architecture (not Software or Enterprise Architecture, but real, putting-up-buildings Architecture), is this passage, about the Parthenon:
"The famous flutings on the famous columns---what are they there for? To hide the joints in wood--when columns were made of wood, only these aren't, they're marble. The triglyphs, what are they? Wood. Wooden beams, the way they had to be laid when people began to build wooden shacks. Your Greeks took marble and they made copies of their wooden structures out of it, because others had done it that way. Then your masters of the Renaissance came along and made copies in plaster of copies in marble of copies in wood. Now here we are making copies in steel and concrete of copies in plaster of copies in marble of copies in wood. Why?"
Unfortunately, this happens all too often in our world of technology. Consider, as an example, one great Bloated Behemoth Enterprise, whose technology needs were well in place and large-scale even thirty or forty years ago, in the days when Mainframes bearing Tape-drives ruled the earth. 

A computer-historical perspective is helpful here, and luckily TheHackerCIO has spent some time both talking to the old-timers (one goes to our local Users Group) and reading about the bad-old-days. In those ancient times, programs were structured around the tape based file system. A typical program would read, as input, the Customer Master tape, which contained an entry for every customer, and a second tape input -- let's say a New Orders tape -- containing a row for each new order needing processing, and already sorted by customer Id. 

The program, then would read a customer order, then advance the Customer Master file until it located this customer, pull out the data it needed to complete the order, and then record the finalized purchases in yet another tape. Note that when building a new system in this kind of ecosystem, one must always source things from existing files, stored on tapes. At the end of job-run, a new tape has been produced, which is input to the next job. And these jobs are all run on a particular schedule, carefully contrived, and supervised by the operators. 

Now enter the Relational Database. The point of this technological innovation, and the internal genius of its principles,  was to have a Master Database for the enterprise. Instead of files, all data would be stored in tables. Now, updates could be made transactionally to the system of record in real time, at the same time as others were querying that same data to determine how things were changing. To take our example, as new orders were placed, it was now possible to obtain the necessary data from the CUSTOMER Table, and create a row in a NEW_ORDERS Table to handle it. As the RDBMS evangelists put things, this tool allowed for:

  • reduced data redundancy
  • increased data availability
  • increased data security
And there was a whole methodology for properly "normalizing" the data, and consequently eliminating the double-update problem, and eliminating concern with determining the system-of-record, by replacing it with one universal system. 

Unfortunately, the Bloated Behemoth Enterprise dealt with Databases differently. They saw them as Yet-Another-Tape-Based-File System. 

And so, each new development project, at its commencement, began life by creating it's own database, just as they would have defined a new Tape-File layout. They sourced them by creating unload jobs, just as they would have unloaded a Tape and loaded the data into their new Tape File layout. They put new wine into old bottles.

And after thirty years of such accretions, they now have tens of thousands of databases, in every dialect of SQL possible, scattered across myriad platforms, with a tangled web of sourcing one database from the unloaded output of another, all kept in several "AutoSys" style batch-job schedulers, so that the proper, and necessary order of loading can take place. 

Which is to say -- for those unacquainted with this kind of BBE -- that at a particular time in the evening (typically midnight) the online systems are brought down, the databases are all quiesced, backups are taken, then crucial batch jobs run, many of which consist of unload jobs to extract data from one database, just as if it were a Tape, and load up another. 

As time has progressed, this batch window grows longer and longer, to progressively consume the evening -- not to mention the disk space available. 

This is a perfect example of the pathology of putting new technology into old bottles. 

And, en passant, it is an example of why Architecture must never adopt the "timeless (and thoughtless) way of building" that merely tinkers with using new things in the same old way, without spending the time to ensure that a proper understanding of the new way is properly adopted and promulgated. 

Consider this a Cautionary Tale! Always seek to know and find the inner logic of a new technology. Always seek to ensure that New wine get's the proper new bottle it needs. Otherwise, you'll want to get drunk when you see the results. 

I Remain,