Update on the example source code packages for UXD Legos:
I’m almost there! I could not resist the temptation to refactor the code from my presentation to handle weaknesses I was hoping no one would notice at the conference. The design for Accessible/Dismissable components didn’t really address the components which are accessed and dismissed by a combination of hovering and clicking on accessor and dismisser WebElements. That was my secret plan all along — present far too much content and speed through slides full of complicated Java source code to prevent anyone from comprehending it enough to notice that my abstract interaction model for these components was lacking something.
Putting together this example package really highlights just how much I overshot the bounds of a reasonable amount of content for a 45 minute presentation. Not only is the amount of source code way too much, there were too many different design concepts to cover. I think I could have easily broken this up into three 45 minute presentations. Sorry again, conference-goers who sat through my presentation. We’ve all had those college professors who did this to us, right? Start nice and slow with something simple and digestible for the first 10 minutes, then jam a semester’s worth of content in the next 30 minutes. The good news is that there’s no final exam at the end of this.
The task of providing example source code in other languages is going to be a longer term effort. Some of the design tricks I used are reliant on concepts and features that are really Java-centric, and more specifically, Java 8-centric. It will be an interesting exercise in figuring out how to translate it to C#, Python and Ruby.
Now on to the actual subject of this post.
I am grumpy today. I work for a large, multinational technology company. I came here after working a couple of start-up gigs at small companies with less than 25 employees. When I took this job, I was SOOOOOO glad to be joining an organization that I was sure would have resources I could only dream about at the cash-strapped employers I had been working for. It hasn’t been anything like that. In my last job, where the CEO regularly cursed out creditors over the phone for not realizing just _who_ he was when they dared to call him and ask for repayment of funds they should be glad to not be getting from someone as important as he was, I had three monitors. I could have my test plan open on one screen, a JIRA screen open on another and my Eclipse IDE open on a third. All I had to to was ask the IT guy (and there was only one of them, so I knew who to talk to), and it happened. When I wanted a VM, I asked the same IT guy and it was done within a day.
At my current employer, I have been trying to get a second monitor since I started working here 3 years ago. Every time I go through official channels, I am told that it is not company policy to provide a second monitor. Apparently, increasing employee productivity via inexpensive and trivial perks like additional computer monitors is just not one of those things they want to concern themselves with. I am now reduced to thieving the second monitor one of my former team members somehow finagled through unofficial channels. It’s just sitting there at his now-empty desk, left behind when he transferred to another team a few weeks ago. If I were feeling bold, I could take both his monitors and hide one in my file cabinet as a backup in case one of mine died.
When I want a VM, I have to enter a ticket in an impossible-to-navigate system, fill out a long questionnaire and…. wait. For a really long time in particular if I want a Windows VM. I requested some VMs before the conference because I had these big ambitions of building this amazing selenium grid with TWO WHOLE NODES during the Selenium Grid workshop on the first day of the conference. I couldn’t install anything on them because the process to grant me sudo privileges failed to work for my VMs. Before the conference, I entered a ticket about this problem in the vain and naive hopes that it would be resolved before the conference started.
When the ticket sat untouched for over a week, I resorted to looking for people who might tangentially be related to this part of the IT support staff to pester via email about solving this problem. As the conference grew near, I finally got a response from someone who said that it wasn’t their job to deal with this even though his name is listed on the web page for requesting sudo permissions on lab machines. He forwarded the email to someone else, who solved one problem for me, but not the remaining issue I had with adding a repository to apt-get so I could install Java on my hub VM. It worked perfectly on my two node VMs. My subsequent emails inquiries failed to generate a response. Today, I got an email from the help desk system, almost a month after I entered my original ticket complaining that I had no sudo privileges on my VMs. Apparently, the ticket was finally assigned to someone today.
So, this first edition of Why You Don’t Have Good Automation has to do with the demoralizing effect of tedious and silly barriers to the acquisition of reasonable resources to do a good job. If you make your employees feel like they are extras on the set of Candid Camera, Kafka Edition as they engage in seemingly futile efforts to achieve small gains in the face of an absurd and meaningless bureaucracy, you will not have good automation. You probably won’t have any at all.