6 Technologies From My First Job

I was sitting around on New Year’s Eve playing Zork, and I got to reminiscing about technologies I have used which either no longer exist or have passed into no usage. Thinking back to my first summer job where I actually got paid to program (actually, I was paid to do physics, but programming was a big part of it), here are six tools I used…


First, we used a KIM-1 microcomputer. This 6502-powered beast had a whole 1024 bytes of memory, and no persistent storage. We used this to control a Perturbed Angular Correlation Gamma Ray Spectroscopy experiment.

After the experiment ran for a while (collecting data in scalar registers), the KIM-1 would dump these registers out to a more “permanent” storage – in this case paper tape. This was great stuff to work with, frequently breaking, sometimes absorbing moisture and swelling.

The experiment would generally run for a couple of days, after which we would have to process the data – which meant uploading it to the mainframe. For the upload, I used a very old (even then) teletype machine, connected to a screaming 300 baud acoustic coupler.

Using this, we uploaded the data to the university mainframe, where I got to analyze it in one of my favourite languages of all time, APL!

Computing was different then!


Danger! Do not implement SharePoint in your Organization! REDUX

This is a re-post of a column I wrote over on Legal IT Professionals a couple of years ago. Just posting it here so that I have a local version.

This column I want to deliver a warning to all of you out there – do not implement SharePoint in your organization! If you ignore this warning, and implement SharePoint anyway, beware. You run the risk of any number of problems, including:

  • User dissatisfaction
  • Maintainability and support issues
  • Data silos, making information hard to find, hard to share, and hard to maintain
  • Lots of rework
  • General chaos
  • Projects that take 10 times longer than you had planned, if they finish at all.

I do a lot of work helping organizations build solutions using SharePoint – is that all a lie?

Not at all. The problem here is the way you think about your projects. If you are consistently talking about “implementing SharePoint” you are going in the wrong direction. If you are talking about implementing any platform, you are setting up for failure. Many of the problems we run into with SharePoint and other platforms arise from focusing on the technologies.

SharePoint is a technology. It is a platform. It is a pretty good platform, in my opinion. Not without its problems, but a pretty good platform.

So what should you be focused on? The answer is obvious, isn’t it? The focus should be on implementing solutions to real business problems, bringing real business value. That was obvious to everyone, wasn’t it? If this is obvious, then why do I still have conversations with potential clients who come to me saying “Help us implement SharePoint”, when they cannot clearly articulate why they want to implement it? Sure, they can spout a lot of vague statements about documents, collaboration, communication, workflow, etc. but where are the clear statements about how this is all going to help their firm?

I think there are a number of reasons this happens. Firstly, maybe I am just talking to the wrong people (too many techies!). However, I have these discussions with many business people as well. Microsoft’s marketing is also a problem (though it is not Microsoft’s fault). People see Microsoft’s SharePoint marketing information, but they typically only pay very superficial attention. They see all these demos of interesting solutions that seem like they must be useful in their world. Then they go to their IT department (or decision makers) and say “Hey we need to implement SharePoint!”

Even worse, they go rogue and implement SharePoint on a small scale within their groups or departments. Then the IT group has to manage all of these emergent SharePoint deployments, so there is a decision to “implement SharePoint” firm wide.

Finally, there are those firms (hopefully very few these days) who really do not understand that they should not be thinking in terms of the technology.

So when is SharePoint not dangerous? Well, that is driven by how you got to “SharePoint” in the first place. I am not going to go into much detail here, because most of this should be pretty well engrained process (if not, call me – I can help ), but here are the big steps:

  • Identify clear business objectives/problems to be solved
  • Is SharePoint the right technology choice to solve them?
  • Don’t try to do everything at once – build a foundation and grow from there
  • Pick initial projects with high impact/visibility
  • Determine specific ROI goals, success metrics, etc. so that you know if you are meeting your goals
  • Make sure to consider the “human” side of things – introducing a platform that touches business processes and how people work requires detailed planning as to how to introduce it.
  • Get help! Hire it, rent it, grow it – whatever you have to do, get help. SharePoint is a big platform that does a lot of things, and if you do not know the platform well, you will end up building things that already exist. Also, as with most platforms, there are 6 different ways to do almost anything – some of them are better than others.

The first step, though – change your thinking and your terminology – and stop talking about “implementing SharePoint”!