Today is my last day at work for 2 weeks – hooray.
We are off visiting family for most of that time. I will be taking the laptop so may well be writing some musing, but as family seem to live anywhere where there isn’t a hot-spot and I can’t stand the thought of using dial-up they will all get posted on my return.
Stu makes a load of really good comments on the way that technical people move further and further away from the end-user experience as they move through there career – the the detriment of the end-user:
What I see from my position as a Lotus collaboration specialist is the way enterprise support, design and engineering teams are structured. Everyone clammers for technical progression up the career ladder and to get away from 1st and 2nd line helpdesk calls (“I’ve forgotten my password”, “I’ve deleted all my emails” etc.)
But what I also see is that once up that technical career ladder there is then little attention paid to the end user tools but much attention paid to the back end server performance and functionality.
This has started to worry me somewhat as the main impact we have with our users is through the software on their desktop, they don’t care what the server is at the back end as long as it delivers what they want. I’m not putting the argument that back end engineering is trivial and unecessary but I am saying that more attention needs to be paid to the user.
Personally I’m on a journey back to the end-user experience. I’m trying to get to a position where I expect the server infrastructure to do what it should do and enable certain user experiences in a way that is usable and intuitive. Getting people to change the way they work is so much harder than changing the technology.
Just to provide that I’m not the only nerd in my family:
Consideration of the formal semantics of APL particularised to consideration of the unusual properties of the null expression. It was something of a surprise to discover that these properties had already been fully documented 100 years ago by Lewis Carroll (Cal). Since that opus is not normally a part of the lore of APL, this paper attempts to re-interpret the original findings in 20th century terminology. APL has a number of objects which are, in some sense, null or empty – two empty vectors, multitudinous other empty arrays, undefined objects and local variables with names but no values. There is at least one other null entity. It has no name, and it has no value. Worse yet, it is denoted by the empty string, and is therefore not easily seen.
Philip R Chastney
Philip is my uncle…
silicon.com has a report today on the situation with Europe’s IT resources titled “IT skills crisis looms – and outsourcing won’t help”, based on a Forrester Research report. For me the most telling statements are:
Forrester senior analyst Richard Peynot said: “All the evidence indicates that Europe faces a serious risk of a shortage of IT skills and Forrester believes that companies need to take action now to support long-term IT competency needs and to pay close attention to the implications of renewed competition for the best talents.”
For what I see though the IT industry is actually heading in completely the opposite direction and reducing training. the logic seems to go something like this “we don’t need to give someone technical training because those jobs are going abroad and all of these IT people already have some business experience”. In my experience most IT people struggle to relate to business issues. Most IT people are in the job for the technology, not for the business benefit that it delivers. The ones who get a buzz from seeing a business change are the minority, and it’s those skills that the IT industry is going to need in increasing numbers over the coming years.
The technical jobs are inevitably going off-shore because they really can be done remotely. The jobs that need to be done intimately with the customer can’t be done remotely (yet).
Joe Wilcox posed an interesting question today over at Microsoft Monitor.
After stating that he had suffered from a number of problems he stated this:
There is a strange lesson here. Nearly every week, I talk to technology managers resistant to change. They would rather run that aging Windows NT 4 server until it breaks, because computing changes, they say, create unforeseen problems and so more work. I didn’t realize that my Comcast broadband account was broken, because I had service. The attempt to fix the problem, so that I could upgrade to a higher-level service, eventually really broke the account. Suddenly, some IT manager’s “no changes” policies make lots more sense.
In my many years experience of running complex corporate systems I have some sympathies with this point-of-view, but it would not be my preferred way of doing it.
The ‘no change’ policy works for simple single instance systems with few dependencies, it most certainly does not for systems which have dependencies. And there in lies a bit of a dilemma, because it’s actually the simple systems which are easy to update, it’s the complicated ones which aren’t.
I have regularly been in a situation where people have left a system without any maintenance (on the basis stated above) and then they have run into a problem. resolving that problem takes an incredible amount of time because you get into loops and cycles with the vendors.
This cycle sometimes due to the situation requiring an upgrade to something like the driver on a card in a server in order to fix one problem, resulting in a chain reaction of events requiring us to upgrade everything. All of the upgrades that chained on from the initial upgrade were already known about, they just hadn’t been done. So rather than trying to assess the impact of one change you are left assessing the impact of 20, 40, 60, 80 changes. I’m actually in the middle of one now where in order to update the firmware on one piece of equipment we need to update the drivers on more than 30 servers.
More regularly the support cycle is severely elongated because vendors who provide the ‘expert’ support work on single tracks. Once they find a problem they insist on that problem being fixed before they will go any further. Often this problem isn’t even related to the problem that is being experienced. Of course as soon as that one is fixed there is another problem found, and on it goes. This iterative cycle just takes forever. And of course the greater the number of changes the less confidence you have that you haven’t actually caused the problem by making the change. The longer the system has been running, the longer it takes to resolve the problem.
I much prefer the situation where a system is maintained to a reasonable level in a consistent incremental way. This way, when a problem does occur, it can be fixed in a reasonable time-frame.
The Register highlights the ongoing debate started (this time) by Jesper Johansson about writing passwords down. Apparently we are all supposed to be used to controlling access to bits of paper.
Jesper was at Tech-Ed and he made some comment about this there. One of his arguments was about single-sign-on solutions. His point was that these systems drive to the lowest common denominator and hence are bad. He’d rather people write different, complicated passwords down.
I have mixed feelings about writing passwords down.
Firstly, if users write passwords down on the same piece of paper, they may as well just have the same password for every system. If they loose the piece of paper, they have lost all of their access and all of the systems are compromised. This is the same as having the same password for everything.
Secondly, organisations need to start differentiating systems on the basis of the importance of the information. Some businesses do this, but many don’t. For these systems it should never be acceptable to write your password down. Single sign-on solutions should be used to simplify the general purpose systems, but not the important systems.
Thirdly, I’m not sure the assertion that people are used to protecting bits of paper is true. Just look at how much credit card fraud goes on after people have thrown credit card statements, etc. away, in an in controlled way.
The biggest issue, as always, is user experience and education. People need to realise the potential consequences of their actions. This type of education is sadly lacking, it’s also not easy to give. The technology does not provide a clear indication of impact or consequences. If someone were to drop a carton outside my house containing nuclear material, I would know immediately that what it contains is very dangerous. I also know that there are certain handling rules. I know all of this from a couple of pictures on the side of the carton. If I start an application, how do I know what the handling rules are for the data held within it. Even if it was communicated within the application it wouldn’t be in anything like as intuitive a way as the one on the side of the carton of nuclear material. If people are going to have a piece of paper with their passwords on it, they need handling rules, and those handling rules need to be different for each password.
Uwe Hermann makes a similar point.
Tuesday in our church is prayer day. That doesn’t mean we pray all day, but it does mean that we set times aside throughout the day to pray. Personally I’m a morning prayer and join with a number of others at about 7:00 on some weeks. I say ‘about’ because this morning I slept in so didn’t make it until about 7:15.
Prayer for a Christian isn’t about sitting down and going through a ritual. It’s about a conversation between us and God. It’s about communing with God. As such I don’t just pray on Tuesday at 7:00, I pray at all sorts of times, most days.
I also try to dedicate times specifically to prayer during week. There is a catch-phrase for these times in Christian circles – “the quiet time”. When I first became a Christian (when I was 17) I soon got into the routine of ‘quiet times’. I’m not sure who suggested that they were a good idea but someone did and it worked – for a while. But over time they became stale and dry and definitely a ritual rather than a conversation. Rather than being a time of communing they became I time of guilt and regret. I soldiered on for a while, but eventually they became so dry that even the ritual fell away.
From time to time I would listen to preachers who would say that I should be making time for God. In a sense they were right, and I knew it, but I didn’t want to go back to the stale ritual. All those preachers managed to do was to build guilt. But God is much greater than any regret or guilt.
Over the last 12 months or so God has been showing me that I don’t need to feel any guilt and that the ritual of a ‘quiet time’ is as deadly as no ‘quiet time’ at all. What God wants is relationship and I am free to find that relationship in any way. The key message in this being ‘free’. There wasn’t a formula or a process; it was about relationship in freedom.
Since God has written that on my heart I don’t have ‘quiet times’; I have times of intimacy. I may be quiet, but I may not. What I don’t have it ritual; I am learning to find freedom. Since starting to move in freedom I have discovered that prayer is a blessing.
A little geograph league table for you:
The funny thing is, Dave lives on the canal so took a great picture of the area around the back of his house. Unfortunately, Martin had got there before him. Anyway they both have pictures against square SD5230.
And I have managed to complete a nice neat little square around my house. It stands out on it’s own at the moment so I think I’ll have to try and expand it a little.
Had some fun today with my blogs. When going through them every other entry was corrupted in some way so that it didn’t display. All of the information was still there, I just needed to re-publish the posts – very strange.
So if you see any other funnies please let me know. (And they don’t just need to be technical funnies)
I tried to get some progress on the McAfee issue from the other day today, so thought it might be fun to have a live support chat with them. The transcript below is the result, and not the most helpful of discussions I have ever had:
Please wait while we find a technician to assist you…
You are currently at position number 1 in the queue.
You have been connected to Support.
Support: Graham, thank you for contacting McAfee Online Support Center. How can I assist you with your McAfee software today?
Graham Chastney: The person who normally uses the PC is defined as a standard user and the update process insists on them needing to be an administrator to update.
Support:: Graham, I would be happy to clarify this.
Support: Have you previously contacted McAfee Technical support regarding this issue?
Graham Chastney: No
Support: Graham, you must be the Administrator user to update McAfee programs.
Support: This is a security feature. All users can not update McAfee.
Graham Chastney: But that’s ridiculous – especially for DAT files. Why would I want to log-on as the administrator every day.
Graham Chastney: Can’ I configure the update service to run as an administrator
Support: If all users are granted access to update McAfee, they will get access to all McAfee data and it can be a breach of security.
Graham Chastney: But it’s a breach of security for me to log-on as an administrator every day?
I completely fail to see how it can be a security feature to stop users updating their virus software. So Ian looks like you were wrong…perhaps it’s time for a bit of DIY.
Anyway, it shows how many people are running in least privilege – and it’s not many.
I’m working from home today, which is nice because it means I get to sit here in my shorts and enjoy the sunny weather. Working from home on a Tuesday can come with a little bit of a challenge as well and that’s our Window Cleaner. He’s a nice guy, but doesn’t seem to understand that I am working from home not here to keep him company.
Anyway, today he came to the door (wanting his money) so I did my usual thing which was to go downstairs and to explain to him that I didn’t have any cash on me and he would (as usual) have to wait until this evening when the cash holder of the family would indeed have some money. And then he started; “Oh dear” I thought, “what’s today’s tale”.
Well it turns out that it’s warm work cleaning windows today, so he had decided to cool himself down by showering himself with the hose pipe in my back garden. Unfortunately the plastic hose pipe had been sat in full sun all day and rather than cooling him down it sprayed boiling water all down the back of his neck. It looked really sore. I must admit to a quiet little chuckle though.
On of the most interesting sessions for me at Tech-Ed in Amsterdam this year was one given by Gianpaolo Carraro in the 5 Pillars of Connected Systems:
I’ll let you read his site for more details on what he means by this and the move to a Service Oriented way of looking at things. I might even comments on whether I think he is right (or not). For me, though, it set off a whole load of thoughts about the Infrastructure/Platform v Application split. If something is a pillar then surely it is Infrastructure and at least part of the Platform, but I don’t know any businesses who regard work-flow as an Infrastructure Service available to all to consume, likewise for Identity and the other pillars.
This is a huge mind-set change that our industry needs to go through if it is to come to fruition. In most of the businesses that I know and deal with there is a huge divide between Application and Infrastructure and the thought of the Infrastructure organisation handling services which directly relate to the end delivery of an application would make most Application Architects go into a right old tis (as we say in these parts). That kind of interdependency on organisation is a real problem. Many of the challenges we face are not technology ones – they are people ones.
Graham Chastney 