Bosses, the Software Industry, and /dev/random

Subject: bosses, the software industry, and /dev/random
Hey boss. Without getting into too much detail, I was just doing some reflection on what it means to be a kick ass professional software engineer in this absolutely dehumanizing industry (read: field of charlatans).  I was reflecting on the characteristics of the better bosses I’ve had, and the thought of you just jumped right out at me. I hope this is still your email address and this gets through. So I was thinking of you, hoping your cancer battle is now 404 NOT FOUND, and hoping you’ll write back.  Best to the fam!

I got this email from an old co-worker today.  I was his “boss” for a couple of years. 

I’ve never considered myself much of a boss because my “style” seems so different from the people I’m around, so I figured I was one of those who didn’t “get it” and it sure hasn’t translated into much in the way of promotions.  But at least this fellow, who is apparently having to work with someone “less than desirable” now, appreciates it.  Given he is very talented software engineer and electrical engineer I really appreciate him taking the time to send this.  Also, we worked together more than 7 years ago and have only talked once or twice since he moved away.

It was a pick-me-up today.  I needed it.

Forensic Software Engineer

I’m not sure that’s an actual career, but it needs to be.  It’s what I spend at least half my time doing.

By that I mean I tend to get given “processes” that someone else used to have before they quit , were fired or made such a mess of it that it was taken away from them.  Then I’m told to “make them work”.  But the majority of the time neither the people who used to do it nor the people asking me to take it over actually understand how “it” works.

So, the biggest challenge in taking it over is to find out how the thing works, how it’s supposed to work, and therefore what to do to “fix” it.  That involves lots of digging through code and the rare small scrap of documentation (ha!) to figure out the inner workings of the process.  It’s a tedious process at best.  Sort of like trying to figure out what killed something long after it died….forensic pathology for software processes.

Along the way you tend to find some facinating choices for how to do things by the previous owners.  If you’re lucky and you still have access to the previous owner they might actually own up to the fact they didn’t really understand it but just plowed ahead with it never really knowing enough about what was happening to question the results.  More often, however, you have no access to the previous owner or they are less than forthcoming with the fact there are major aspects of that broken process they don’t really understand.

As I like to say, I could complain but it wouldn’t do any good….

X12 Standards and Segment/Loop Ordering

Why oh why did the X12 committee for health care define some standards that allow some of the segments and/or loops in an X12 document to appear in any order?  The doc specs define the order in which all these things must appear in an EDI file, but some rare segments/loops have the same relative position, meaning that those particular items can actually appear in any order relative to each other in an X12 file (e.g. in the 4010 837P see the 2420{C,D,E,F} loops).

Darn that makes it hard to parse into XML and validate.  I’m guessing (just a WAG here) that about 99% of the X12 standard definition for any given document defines a well structured order.  What was X12 thinking when they allowed so few of these things to be randomly ordered amongst themselves?  That is just nuts.

If there is a valid rationale for that I’d honestly like to hear it.  I’ve spent the last two days cursing it…..

I Hate Crystal Reports

The company I work for began using Crystal Reports some years back, and not being a “report writer” I didn’t care too much at the time.  Now, of course, that inattention is biting me in the backside because I have inherited the task of redesigning a couple of those reports.  That alone should be pretty humbling since I am a “software engineer”, not a danged “report writer”.  These reports have a fairly intricate amount of line drawing in them to create a “form” look for the generated report which undoubtedly causes some of the headaches with redesigning these.

I can proudly state that I am pretty inexperienced with Crystal Reports (or any other reporting software) so perhaps I am bringing some of this upon myself, but this has to be the most damnably frustrating piece of …. software …. I have ever used.  There are SO many things that can go wrong.  Fonts can get you (oh, it will “work”, but may not look ANYTHING like you designed).  Permissions can get you (sometimes to system folders).  Disk space free in unexpected places can get you.  Bad reporting fields can get you, which is okay but you think it would tell you which one!!!  HA!!!  If only!  And don’t you go changing any of the default behaviors for a report.  That’s a certain death wish.

You have to know something of redistributing the right runtime version of Crystal Reports on the client machine, and of course they have “upgraded” Crystal Reports like they were changing underwear.  Is it v8?  v9?  v10?  vX?  Visual Studio 2003?  Visual Studio 2005?  Dog crap?  (Yes, it IS the latter!).  Have you installed service packs?  Hotfixes?  The list goes on and on and on.

With all the bells and whistles this thing claims to have you think it would at least be WYSIWYG, but regrettably it is not.  Design to your hearts content, then see the deployment have not so subtle and catastrophic affects on the output.  It can easily make a report you spent weeks perfecting look like some piece of garbage somebody threw together in an afternoon.

I read a blog entry recently where some sap claimed the inclusion of Crystal Reports into Visual Studio had “made the programmers life so much simpler”….. I’ll bet the poor sucker has not tried to deploy that sumbuck to another computer!

By the way, did I mention I hate Crystal Reports?