Give Me That Old Time Tech Policy

Do you like beer? I do. How do you like the amount of selection on the market now? It’s awesome isn’t it? It wasn’t always like this because the screws were tightened down on small and home brewers for years and years. Small timers, in my opinion, simply weren’t trusted with making beer; and in America these laws dated back to the 1920’s and Prohibition. Once the regulations were dropped (over many years) we entered this golden age which has made all of our lives better. Here in Wisconsin and over in Minnesota is an unbelievable cornucopia of great new local beers and a remarkable increase in quality of life because we became free to pursue brewing, distilling and wine making. Myself, I’m just a beer acceptance tester. But a good one.

These days in development we are starting to see a tool prohibition start again, and the power of innovation taken out of ours hands. We aren’t allowed to be admins on our machines, to be trusted to freely search the internet for information — and in some cases cut off all together. We can’t use the tools or improve the tools we need and all of this is hurting the industry and stopping innovation. All in the name of security.

There has been a huge bleed over of reactionism from the Target and Home Depot security breaches. And it is my opinion that the manner that security is being addressed is in part incorrect. Stopping innovation, throwing up a Berlin Wall for developers will not, in any way, help your company.  Security is important, oh yes.  As someone who has had a lot of HIPAA training, and in my beliefs system, I am well well aware of this. But some things are inconsequential and wasteful.

We had Tech Prohibition in the 1990’s before the big breakout of last decade. For instance, I remember  working  on a retail site (in a very large company) that needed a lot of graphics work done, and that task fell on my shoulders to do it in addition to the java/css/html. I had to use Microsoft Paint to do the image work — that’s right — because the company would not give me a proper image editor, let me install my own, or even bring a notebook in with my own Photoshop, do the edits, and transfer them to the project. I cannot tell you the amount of time was wasted using that crappy tool for such a task. It took years and years for many companies to *trust* developers to do their work with the tools they wished. The result was the productivity increases we saw, to some extenxt, with developer initiated XP, Lean, Agile movements and the development of CI and extensive developer testing tools, among other things. An explosion.

I can’t use any of these on one of my gigs . . . .

Now to be fair — I can’t say that some developers aren’t at fault. I remember when I first started running into the dynamic languages in the mid-2000’s: Python, JavaScript, Ruby, PHP, Groovy etc.  a lot of the sentiment started rolling towards doing work directly out in production.   The languages, especially one’s like JavaScript and PHP, lent themselves to doing quick fixes without doing a big build/rollout process like Java.  But even now the JavaScript people are learning that maybe a compile process isn’t such a bad idea for many reasons besides a dev/production buffer.

Maybe the movement was to get the stodgy old processes out of the way and make way for “Agile.”  Man are there a lot of different interpretations of that word and that was one of the worst ones; the other being “change business requirements in the middle of sprints.”  I guess we could talk about that in depth.

Anyway — having to call the help desk to install a Tortoise upgrade?  Or to get IntelliJ?  Or having them question my choice of a screenshot tool . . . or even a text editor?  It’s coming to this.  We have our Jenkins server logging us out after two minutes, and if I set up a tray monitor it breaks my Active directory/LDAP login and I get locked out.  Is this really the way to conduct a development shop?

Blocking any of these tool choices won’t solve a thing.

What can be done is:

  • Isolate the development environment completely from production.
  • Keep your production data safe as heck.
  • As a developer, do not get production access unless you absolutely need it.
  • As an organization, separate your development people and your support people; they aren’t the same anyway.
  • There are tools that do security checks and software licensing checks and everything else — use these.
  • Why not just have a reasonable guest network in house?  If McDonald’s can have internet, can’t a tech department?
  • As a developer, behave in a professional manner so that there can be no “trust” issues/incidents.  For instance, don’t hook your phone to your computer, don’t bring in USB keys, etc.

What I am doing now is lugging in a separate computer for my stuff now, using tethering from my phone access  — for PM management stuff, Dropbox stuff.  My Fossil and Kanboard and Google Drive things.  I have no choice.

But it’s all too bad now isn’t it.  Such a waste of time.


Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>