Category Archives: IT

An Honest Resume Personal Statement

While updating an online version of my resume a nagging web page advised me to include a personal statement: apparently the personal statement is my chance to stand out, make that all important first impression, and firmly affix my lips to succulent corporate ass.

Being programmer oriented, the web page suggested I write about my first computer. This is just conniving HR speak for, “How old are you?” HR cannot directly ask so they’ll probe circuitously. Sorry gals, (HR is a female ghetto), I’m on to you. I am excellent actor and liar. I can play your little game but I am no longer interested. Still your little page made we wonder what my personal statement would be like if I was telling the truth and not spinning like a millisecond pulsar. I think it would look something like this:

I want to solve problems: not create them. You would be surprised how many software organizations cannot tell the difference.

Ask yourself:

  1. Does your organization think the orthodox application of trendy project management “methodologies”1 like agile is a substitute for real insight and work?
  2. Do you bind yourself in SOX inspired straitjackets and wonder why programmer morale and productivity has plummeted?
  3. Do you have an antiquated remote work policy and insist staff show up for periodic management brow beatings and pointless brain numbing meetings?
  4. Are you wedded to standard software tools merely because they are standard?
  5. Are you afraid of iconoclastic viewpoints and meekly seek a lowest common denominator consensus?
  6. Finally, do you follow industry trends or set them?

Perhaps my bad attitude shocks you.

“Who would hire this guy?” you ask.

It’s a fair question. I’ve had my fill of “Software Theater.” I will no longer act like I agree with bad ideas just to get along. From now on I am going to tell people what I really think, not what they yearn to hear.

To work with me your organization must be:

  1. Located somewhere I want to live to or have an enlightened 21st century remote work policy.

I am tired of wasting my life in humdrum hellholes because that’s where an employer is located. This is inexcusable for 21st century software developers. If you haven’t figured out how to manage geographically dispersed remote workers your organization is hidebound, myopic and doomed!

  1. Have a positive attitude about novel approaches to problems and encourage programmer autonomy.

I have often solved problems with nonstandard tools and techniques only to be told to do it again using a standard tool. Sometimes this makes sense but usually it’s motivated by pure organizational fear.

“Oh my God we won’t be able to find someone to support this!”

Or even worse, “We’ll have to learn something new!”

Companies make a big show about “thinking outside the box” while huddling like bed wetting cowards in the corner of one.

  1. Accept the simple fact that work is small part of life and stop trying to manage employees outside of the workplace.

It’s amazing what some companies think they can get away with! Would you believe asking recruits for Facebook and Twitter passwords? Don’t try this with me; I might punch you! Most companies know that asking for passwords crosses all sorts of inappropriate boundaries but even more enlightened organizations often have a “velvet fist” social media policy that basically tells employees not to involve the company in their personal jackassery. This is a reasonable request but it’s usually seen as bullying. Most will shut up: not me! Freedom of speech is fundamental and absolute. Companies that try to silence employees should be ashamed of themselves.

If you’re still reading and think, I like the cut of this guy’s jib. We have enough kowtowing eunuchs on payroll: a few ballsy shitheads may spruce this joint up. I’d suggest you look over my attached resume, peruse my public GitHub repositories, read my blog, browse my extensive photos, and check out what I’m reading. You’ll get a pretty accurate sense of who I am, what turns my crank, how I approach problems, and how I deal with difficulties. Unspoken social conventions demand that we suppress ourselves to work. I will no longer do this. I am what I am; I do what do; I will not change for you.

  1. I loathe the word “methodologies.” The correct word is “methods.” Wanton syllable inflation is a reliable bullshit tell.

Cutting the Stinking Tauntaun and other Adventures in Software Archeology

The other day a software project that I had spent a year on was “put on the shelf.”  A year of effort was unceremoniously flushed down the software sewer.  A number of colleagues asked me, “How do you feel about this?” Would you believe relieved?

This is not false bravado or stupid sunny optimism. I am not naïve. I know this failure will hurt me. In modern corporations the parties that launch failures, usually management, seldom take the blame. Blame, like groundwater, sinks to the lowest levels. In software circles, it pools on the coding grunts doing the real work. It’s never said but always implied, that software failures are the exclusive result of programmer flaws.  If only we had worked harder and put in those sixty or eighty hour weeks for months at a time; if only we were a higher level of coding wizard that could crank out thousands of error free lines of code per hour, like the entirely fictional software geniuses on TV, things might have been different.

Indulging hypotheticals is like arguing with young Earth creationists about the distance of galaxies.

“Given the absolute constancy of the speed of light how is it possible to see the Andromeda galaxy, something we know is over two million light years away, in a six thousand-year-old universe?”

The inevitable reply to this young Earth killing query is always something to the effect that God could have made the universe with light en route.  God could have also made farts smell like Chanel #5 but sadly he[1] did not.  Similarly, God has also failed to staff corporations with legions of Spock level programmers ready and willing to satisfy whatever au courant notion sets up brain-keeping in management skulls.  The Andromeda galaxy is millions of light-years away, we don’t live on a six-thousand-year-old Earth, and software is not created by magic.  Projects work or flounder for very real reasons. I was not surprised by the termination of this project. I was surprised that it took so long to give up on something that was never going to work out as expected.

Working with bad legacy code always reminds me of the scene in The Empire Strikes Back when Han Solo rescues Luke on the ice world by cutting open his fallen Tauntaun with a light saber. When the Tauntaun’s guts spill out Solo says, “I thought they smelled bad on the outside.” Legacy code may look pretty bad on the outside, just wait until you cut into it. Only then do you release the full foul forceful stench.

The project, let’s call it the Stinking Tauntaun Project, was an exercise in legacy system reformation. Our task was adding major new features to a hoary old system written in a programming language that resembles hieroglyphics. I know and regularly use half a dozen programming languages. With rare exceptions, programming languages are more alike than different. From the time of Turing, we have known that all programming languages are essentially the same.  You can always implement one language in another; all programming systems exploit this fundamental equivalence. It’s theoretically possible to compile SQL into JavaScript and run the resulting code on an eight-bit interpreter written in ancient Batch I just wouldn’t recommend you start a SOX compliant software project to create such insanity. This goes double if only one programmer in your organization knows ancient Batch!  The Stinking Tauntaun Project wasn’t this crazy, but there were clear signs that we were setting out on what has been accurately described as a Death March.

Avoiding Death Marches, or finding ways to shift blame for them, is an essential survival skill for young corporate programmers. It’s not an exaggeration to say that a lot of modern software is built on the naiveté of the young. When you first learn to program you are seduced by its overpowering rationality. Here is a world founded on logic, mathematics and real engineering constraints. Things work and don’t work, for non-bullshit reasons! There aren’t any pointless arguments with ideological metrosexual pinheads about “privilege” or “gender.” Programs don’t give a crap about the skin color of the programmer or whether their mother was an abusive bull dyke. After a few years of inhaling rarefied logic fumes young programmers often make the gigantic and catastrophic mistake that the greater naked ape society in which they live also works on bullshit free principles. It’s at this delicate stage when you can drive the young programmer hard. There’s an old saying that salesmen like money and engineers like work so in most companies the salesmen get the money and the engineers get the work. As the great sage Homer Simpson would say, “It’s funny because it’s true!”

Death Marches shatter the naïve. Gaining a greater understanding of the nasty world we live in always does a naked ape good but there’s a cost; your career will suffer and you will suffer: enlightenment is proportional to pain! The school of hard knocks is a real thing and unlike that party school that you boozed through no one graduates alive. I’d strongly recommend a few Death Marches for every working programmer. To paraphrase Tolstoy, “All successful software projects are alike; every unsuccessful project fails in its own way!” You may consider what follows my modest contribution to the vast, comprehensively ignored, literature of software Death Marches.

Code Smell #1: A large mass of poorly written test free legacy code that does something important.

“Refactoring” is a word that I love to mock, but the refactoring literature showcases an astonishingly precise term: “code smell.” Code smells are exactly what you expect. Something about the code stinks. The Stinking Tauntaun code base didn’t just stink, it reeked like diuretic dog shit on choleric vomit. This was well-known throughout the company.  My general advice to young programmers that catch a whiff of rotting code is simple: flee, run, abort, get out of Dodge! Do not spill your precious bodily fluids cleaning up the messes of others.

When recruited a number of experienced hieroglyphic programmers asked me the pointed question, “How do you deal with giant stinking piles of legacy doo-doo?” Maybe it wasn’t quite phrased like that but the intention was clear. They were telling me that they were dealing with a seething mass of half-baked crappy code that somehow, despite its manifold flaws, was useful to the organization and couldn’t be put out of its well deserved misery.

I honestly answered. “Systems that have survived for many years, despite their problems and flaws, meet a need. You have to respect that.” I still believe this!  Every day I boot up ancient command shells that look pretty much like they did thirty years ago.  Why do I use these old tools? It’s simple; they do key tasks very efficiently. I try new tools all the time. I spent a few months playing with PowerShell.  It’s a very slick modern shell but it has one big problem. It takes far longer to load than ancient DOS or Bash shells. When I want to execute a few simple commands I find the few extra seconds it takes to get a PowerShell up and running highly annoying. Why should I wait when I don’t need the wonderful new features of PowerShell?  The Stinking Tauntaun System also met user needs and, just like I am horrified by the clunky ill-conceived incoherence of old shells, Stinking Tauntaun users held their noses and used the good bits of what’s overall a bad system.

Code Smell #2: No fully automatic version controlled test suite.

There is a tale, possibly apocryphal, from the dawn of programming that goes something like this: a young programmer of the ENIAC generation was having a bad day. He was trying to get some program running and was getting frustrated “re-wiring.” Our young programmer was experiencing one of the first “debugging” sessions back when real insects came into play. In a moment of life searing insight our young programmer realized that from now on most of his time would be consumed hunting down errors in faulty programs.  The tale goes dark here. I’ve often wondered what happened to the young programmer. Did he have a happy life or did he, like Sisyphus, push that damn program up the hill only to have it crash down again, and again, until management cried stop!

Debugging is a necessary evil. If you program — you debug. It’s impossible to eliminate debugging but at least you can approach it intelligently, and to this day, the only successful method for controlling program errors is the fully automatic version controlled ever-expanding test suite. Systems with such suites actually improve with time. Systems without such suites always degenerate and take down a few naïve programmers as they decay. The Stinking Tauntaun System lacked an automatic test suite. The Stinking Tauntaun System lacked a non-automatic test suite. The Stinking Tauntaun had no useful test cases what so ever! Testing The Stinking Tauntaun was more painful than dealing with its code. The primary tester had nightmares about The Stinking Tauntaun.


My Power-Point-less illustration of Quality over Time for a system that lacks a fully automatic ever expanding version controlled test suite. Systems without well designed test rigs are almost without exception complete crap. Unless someone is paying you huge bucks it’s best to start sending out resumes when asked to fix such systems. You can ruin your health stirring your yummy ice cream into the shit but it’s almost certain the final mixture will taste more like shit than ice cream.

It’s the 21st century people! In ENIAC days you could overlook missing automatic test suites. Nowadays missing automatic test suites is a damning indictment of the organization that tolerates such heinous crimes against programming humanity!

Code Smell #3: Only one programmer is able to work with legacy code.

When I was hired there were a few hieroglyphic programmers on staff. No single programmer was saddled with the accumulated mistakes of prior decades. We could divide and deal with the pain. During this happy time our work was support oriented. We we’re not undertaking large projects. Then an inevitable bout of corporate reorganization occurred, followed by terminations and a stream of defectors fleeing the new order.  Eventually only one hieroglyphic programmer remained: moi!  Most programmers would have joined the exodus and not taken on the sins of other fathers but as I have already pointed out I am a software whore and proud of it.  Still even software sluts must avoid ending up like the, “there can be only one,” Highlander. Most of those sword duels ended rather badly as I recall.

Code Smell #4: Massive routines with far-ranging name scope.

With noxious fumes already cutting off our air supply we should have stopped in our tracks but we soldiered on because The Stinking Tauntaun System did something important and alternatives were not readily available. The corporation recognized this and started a number of parallel projects to explore New Stinking Tautaun’s.  I wasn’t lucky enough to work on any of the parallel projects. I had to get in the stall and shovel the Tauntaun manure.

We weren’t entirely clueless when we started Stinking Tauntaun work.  We recognized the precarious hieroglyphic programmer resource constraint and tried to divide the work into units that alleviated it. We decided to implement part of the new features in another programming language and call the new module from the old system. The hope was this would divide the work and possibly create something that might be used outside The Stinking Tauntaun System. This part of the project went reasonably well. The new module is entirely new code and works very well. Unfortunately, it was a small part of the greater effort of bolting new features into The Stinking Tauntaun System.

Stinking Tauntaun code is magisterial in its monolithic madness. The hieroglyphic programming language is famous for its concise coding style yet the main routine in the Stinking Tauntaun System is close to 10,000 lines long!  I had never seen hieroglyphic language routines of such length. I’ve only seen comparable programs a few times in my battle scared career. As a summer student I marveled at a 20,000 line, single routine, FORTRAN program.  At first I thought it was the output of some cross compiler but no, some insane, bat shit crazy government drone, (I was working for a government agency in western Canada), had coded it by hand — on freaking punch cards no less! Such stunning ineptitude is rare: most programmers have a passing acquaintance with modular design and know enough to reconsider things when code gets out of hand. We all have different thresholds for judging out-of-hand-ness, for me it’s any routine that’s longer than sixty lines: including the damn comments.

A 10,000 line routine is a monumental red flag but The Stinking Tautaun’s length was not the biggest problem. There is this thing programmer’s call “scope.”  Scope marks out name boundaries. It sets limits on where names have meaning or value. Ideally name scope is limited to the smallest feasible extent. You really don’t want global names! You absolutely don’t want global names like “X,” or “i,” or “T,” cavorting in your code! Most of the cryptic names in the Stinking Tauntaun System had far-ranging scope. Vast scopes make it difficult to safely make local changes. This makes it risky, dangerous and time-consuming to change code.  Large scopes also increase the burden on testers. If tiny changes have far-ranging consequences you have to retest large parts of the system every time you tweak it. All of this sucks up time and drains the pure bodily fluids of IT staff.

Code Smell #5: Basic assumptions about what is possible quickly prove wrong.

It was looking dark. Timid souls would have run but we plowed on. Our naïve hope rested on the theory that we could change a few touch points in The Stinking Tauntaun’s code base and then get out of Dodge before the dark kludge forest closed in. My first estimate of how many routines I would have to touch was around twenty. Two months into the project I had already altered over a hundred with no end in sight. The small orthogonal change we hoped to make was not possible because The Stinking Tauntaun System did not sensibly do one thing in one place. It did sort of the same thing in many places. You couldn’t make a small change and have things sensibly flow throughout the system.  I worked to isolate and modularize the mess but I should have just waved my hands and spent my days on LinkedIn looking for another job.

Code Smell #6: A development culture steeped in counterproductive ceremony.

On top of all these screeching sirens yelling stop there were other impediments. I work in a SOX saturated environment. Readers of my blog know that I consider SOX to be one of the biggest time-wasting piles of DC idiocies ever pushed on American companies. Like many “government solutions” SOX did not drain the intended swamp but forever saddled us with inane time-wasting ceremony and utterly stupid levels of micromanagement. Is Active Directory management really a concern of freaking government? Somehow it’s become one!  One of my favorite consequences of SOX is the religious ordering of development environments and the sacraments for promoting code changes. During the long bruising Stinking Tauntaun project many releases boiled down to me making changes to one file! Pushing a new version to test should have been a simple file copy.

Of course it couldn’t be that simple. Numerous “tickets” had to be approved. Another branch of IT, that was even more stressed and suffered higher levels of turnover than ours, was dragged in to execute a single trivial file copy. In many cases more bytes were generated by all this pointless time-wasting ceremony than I had changed in that single file. Of course all this took time, and as hard as I looked for a useless-time-wasting-bullshit category in our web-based hours tracking system, I couldn’t find one. There’s a management mantra: you can only improve what you measure.  Funny how companies never measure the bullshit.

In retrospect we should have junked The Stinking Tauntaun System or opted for a radical rewrite. It’s ironic but something like this is what’s going to happen. If I was young I would be bitter but I cashed in on this project. In my consulting days I was always on the lookout for Stinking Tauntauns: they were freaking gold mines for those of us that have acquired a taste for the bracing putrid fumes of rotting code.

[1] If you are the type of person that gets your panties in a knot about the gender of hypothetical supreme beings please go away.

Corporate Social Media Policies

You probably work for a company that has a corporate social media policy (CSMP). I’m betting that your CSMP’s preamble starts with words like, “we would never restrict the free speech rights of employees but blah, blah, blah, … It’s what follows the “but” that matters. For example my employer does not want anything I write to:

  1. Adversely reflect on the “brand.”
  2. Divulge proprietary or trade secrets.
  3. Reflect poorly on company officers and employees.
  4. Move our stock price.

This is all just common sense as far as I’m concerned and it irritates me that we now have to sit through more mandatory inane HR training sessions belaboring the obvious. Corporate social media policies join sexual harassment, diversity training and nondisclosure agreements in the ever-expanding pantheon of to be ignored corporate bullshit. In my case my company is safe. I purge my brain of work thoughts the second I leave the company’s parking lot. I refuse to carry company cell-phones and I will fight like a cornered badger to keep work at work. There is a difference between being a professional and being a serf.

Companies prefer managing serfs. The ideal employee is the professional serf. You might think professional serfs are as common as unicorns but you’re wrong. The young often go through a professional serf stage. If you’re a graduate student you’re probably a professional serf. If you’re a top ranked young programmer working seventy hour weeks on some doomed pile of crap-ware you’re a professional serf. If you’re an articling lawyer you’re a professional serf. If you’re a medical intern you’re a professional serf. Many employers want to meet and exploit you. They know that you will burnout or smarten up but HR’s persistent cream dream is to find some naive young genius willing to make the ultimate sacrifice for their good.

I went through a professional serf stage but my bad attitude couldn’t sustain it. Now I think like a corporation; I put a price on everything! If you want me to give a crap about your servers at 2am on Saturday that will be another $15,000 per year and an extra week of vacation time. I’ve found that when you’re completely upfront about these issues you either don’t get the gig, usually a blessing in disguise, or people see they’re dealing with a real professional and want you even more. Corporations have enough simpering eunuchs on the payroll, having a few ballsy shitheads around gives the joint class.

By now you’re probably wondering if I’ve violated my employer’s corporate social media policy. Have I damaged their brand? Have I impugned our CEO? Have I goosed our stock price? Have I exposed proprietary secrets? No, no, no and no! Will I moderate my opinions and think about the company when blogging? No!

Git me a Hub’bery

Sometime ago I crossed my machine synchronization threshold. I routinely work on four operating systems, three laptops, a few servers, a bunch of phones and so on. I synchronized the directories I cared about while forming deep and rewarding relationships with file sharing services like Dropbox. Dropbox is great but its success has attracted the attention of paranoid IT micromanagers and it’s now frequently blocked on internal corporate networks. The beSOXed imbeciles that set IT policies will not rest until it’s impossible to do useful work on corporate assets and people wonder why there is so little return on IT investment.

Living without Dropbox and its many peers is annoying but tolerable provided humble USB ports are still useful but restricting plug-in drives is now standard not-operating procedure in most companies. So if you cannot share files or use USB what’s left? Would you believe GitHub?

GitHub is close to total global dominance in the geeky code sharing world. I would not have expected a version control system to attract a fiercely loyal and dedicated cult following but it has. Linus Torvalds, the Linux demigod, started Git when he correctly observed that all pre-Git version control system were fundamentally flawed because they enshrine the overlord peon hierarchy. The overload, usually some IT nitwit, manages the entire code submission, review and backup process and the peons, that would be us, bend over take it. Until Git appeared the majority of programmers despised and detested version control. It was just more IT management bullshit.  We put up with it because version control is a necessary evil and paychecks are even more necessary evil. We only wished things could be less evil and then Git appeared.

Git dumped the overlord peon hierarchy and adopted the radical notion that all repositories are created equal. When you synchronize Git repositories everything is synchronized. Your local copy contains everything the source does. This makes Git a superb peer-to-peer file distribution tool. Not only are you distributing files you’re also distributing their complete histories. This, almost biological replication model, has resulted in an explosion of Git repositories and the rise of hub sites like GitHub. Git’s dominance would not be possible if it was centrally managed. It’s succeeded because it’s harnessed market chaos.

I’ve used Git for over a year and I have often thought about pushing JOD source to public repositories. This weekend I bit the bullet and set up public repositories. Now it’s easy to Git me a Hub’bery!

Controlling Cell Phones the new IT Frontier

no cell phones

Personal cell phones are on the IT hit list.

It won’t be long before your employer starts jamming or confiscating your personal cell phone. Wait a minute isn’t that a tad hyperbolic? Wouldn’t that trigger an avalanche of “freedom of speech” lawsuits?  Wouldn’t people yell “fornicate elsewhere” and quit?  Ahh, if only it were so.  I would love to be wrong about this but I have a superb track record when it comes to predicating IT control freak trends.

In my long programming career I’ve never met a “liberty loving” IT manager. There’s something utterly intoxicating about being in a place where reliable minions, (dead computers for the most part), completely manifest your vision.  I’ve watched the most libertarian of programmers turn into Dilbertian despots when tasked with network security, software procurement or SOX compliance. IT’s first impulse is to control, control and control even if control is counterproductive.

Here’s the sad news. Most IT polices are counterproductive and they never fix the problems they claim to address.  Consider my case. I have never introduced a network virus, distributed proprietary company information or collaborated with competitors.  Everywhere I’ve worked had specific IT policies for these, and other corporate crimes, but I could have easily circumvented 95% of them at any time. The only defense any of my employers ever had was my personal honesty and integrity.

Unfortunately my personal honesty and integrity is beyond the control of IT and, as I have said before, control is key when it comes to IT. If IT cannot control it they won’t even recognize it!  This is why we end up with abominations like SOX — perhaps the must ludicrous bit of micro-managing nonsense ever foisted on American companies. Incidentally SOX does SFO when it comes to preventing the Enronesque crimes it was intended to prevent. Don’t believe me, ask Jon Corzine about where MF’s billions went.

Exactly where do personal cell phones fit into IT policies? When cell phones first appeared they were just phones. Now they’re web browsers, cameras, microphones, stereos, GPS receivers and recently full-fledged programming environments. So much power and all outside of IT’s control. Most employers keep lists of banned websites. What’s the use of tasking neutered lackeys with maintaining a list of banned websites if an employee can whip out an iPhone and browse at will? What’s the point of banning USB drives and locking down proprietary files if you can take a quick snapshot of your monitor and post it on Facebook?  IT has a personal cell phone problem and I can guarantee that whatever twisted solution their misguided minds fixate on it will have nothing to do with employee honesty and integrity.

The Real Problem with Enterprise Software

Only the gifted analytic minds of IT management and know it all programmers have the intelligence work ethic and superb taste required to select enterprise software.  Speaking as an ITite, (one who works in IT), I can report that we are so gifted, so far-seeing, so utterly and totally awesome in our views that only ignorant tuggles, (non technical types), would dare challenge our recommendations.   Even better, the same plodding sleep deprived determination that we use to code computers into submission can be applied to human adversaries.  We can wear you down with one technical objection after another until you finally give in and make the correct selection.

awesomeevil And what is the correct selection?  ITites assert that the correct solution is the one that always puts them in absolute control of clueless tuggles that seem determined to have their own way when we know their way is wrong wrong and wrong!  To paraphrase the leading reptilian philosopher of our age: control is key when talking about IT.

Because control is key enterprise software must extend and consolidate ITite empires or it will be rejected.  Rejections will take the form of complaints about, cost, performance, scalability, standards compliance, or my current favorite uncloudable: software that cannot run in the cloud.  Some of these arguments may have merits but usually the selection boils down to human prejudice and personal comfort zones.

There is one poisonous consequence of this madness that really pisses me off.  To kowtow to IT control freaks enterprise software vendors have made heroic efforts to prevent people from using and mastering their software.  We are used to downloading software and giving it a try. I challenge you to try this with Cognos/IBMMicrosoft BI, Oracle/Hyperion or, the worst of the lot, SAP software.  Not only will you not be able to download useful free trial versions but in many cases you won’t even be able to get your hands on manuals!  How lovely: a complex suite of software that you have to pay to read about!

Enterprise software vendors are rightly horrified by the prospect of their wares turning into commodities.  A commodity, in business speak, is something that you cannot mark way the fuck up!  Of course all this stuff is grossly overpriced with inane gouging support contracts piled on.  Do not despair enterprise software vendors are piling wood on their own funeral pyres. They are creating perfect conditions for low-cost, or open source providers, to knock them off and party on their graves.

To help set the cremation fires ablaze I abide by following sacred consulting principle.  Don’t waste your time on systems that you cannot take with you.  This is the real problem with enterprise software; you cannot take it anywhere!