Adventures in a disconnected world
Last few days before I start my new job and I think I am getting a little confused.
So I have an office document and I can save it as XML. If I print it, in the future, it will be converted into "Metro" format. In addition there is "XAML" which is a another way of serialising objects so why couldn't "XAML" have been used.. Why do I need so many different XML formats ?
If I send a document to a user on a different platform it seems that "Metro" would be the correct format to send it in as it is meant to be format that is readable on other platforms.
So if I am in office in the future what format will I save the document, at the moment it looks like a confusing set of options. Also as Wallace B. McClure points out in this posting http://weblogs.asp.net/wallym/archive/2005/04/27/404731.aspx it is vital that "Metro" is also implemented on legacy platforms otherwise there will be an almighty mess.
I am sure that this will become clearer soon but at the moment it does seem confusing and a lot of overlapping functionality
It is a long time since I have blogged and part of that is because I have been acting in a play but also because I decided to change jobs.
Well now a lot of things have been resolved and I will be joining Microsoft Switzerland as an Account Technology Specialist at the start of May 2005. Knowing that I was joining the company has led to me think twice before I put "finger to keyboard", that sounds weird compared to putting pen to paper, but hopefully I will be blogging more again in the future.
It is funny normally when you tell people you are joining a company they ask what does the company do. No one does that with Microsoft, everyone has an opinion. Some people think I have joined the dark side and other people are fascinated to know a little bit more about what life is like within Microsoft. As they say about a film or play, the worst film or play is one that proves no reaction be it good or bad. Joining Microsoft certainly provokes a reaction.
I had interview today, so reading Scott's set of .Net questions was rather topical.
I was thinking, if I was recruiting a developer, what weight would I give to the number of questions they could answer from the list compared to their knowledge or experience in other areas ? In other words what weight would I give to their in depth technical knowledge with one specifc technology and what weight would I give to a broader set of skills.
I think if I was recruiting a consultant/contractor for a short term contract and a defined work package then the number of questions they could answer correctly would be important. In that case I am looking for a worker bee and I want to be certain they have skills for the job from day 1.
However, for a permanent employee I would place a much lower weighting on the number of answers given. The reason is that I am much interested in a person who knows where to look for the answers, knows their limitations outside their specialist area but knows to ask the right people and has experience to determine what is the appropriate solution for a problem. It is much more important to me they way go about solving a problem than knowing everything in detail.
When you work in IT it is very simple to believe technology is the holy grail and can solve all problems and forget that sometimes the pen and paper will provide a better soluton for the customer.
Also, I would prefer to employ someone with wider range of experience, so that they would be more objective. For example, some one with Java experience or Oracle experience can bring an objective viewpoint to a project. Naturally, it is important that they don't have blinkered view of life. Also there knowledge of the industry where the company sell products and the business processes used in that industry are vital as well.
For the first time in my career I am having to look for a new job because of a change in the strategy of the company where I work means that my skills are no longer required. It is a scary situation as the IT market is still a difficult one.
One of things that you soon realise is how important your friends can be and how they provide you with information about jobs you would not otherwise hear about. So often people working in IT forget how important an active social life can be. I act in the amateur theatre which is great as it takes me away from the computer screen, proves I can work in a team with people from different backgrounds and temperaments. It also provides a strong social network and many leads for possible jobs.
I think in IT we often forget that while technology skills are important in the end the soft skills can be the deciding factor. Even if you are safe in a job always continue building that social network and of course, though, in some ways it obvious, make sure you keep your resume(cv) up to date and ready at hand. If the contents of your CV are still the same after a year, what have you being doing, are you still learning or have you stagnated ?
If anyone is looking for someone in Switzerland with strong .Net skills as well as consulting and team leadership skills, I think I have the skills you are looking for. Also I speak fluent German. Please contact me and I can send you my resume(cv). Just use the link on the weblog to contact me.
I really need to post a lot more. I have got it the habit of reading more than writing. 2004 was a strange year. It was a year where many people in IT serious started wondering whether they had a career that would take them through to retirement or even through the next few years. In terms of software development it was a time where projects where increasingly developed in lower cost countries and where business analysis and project managment skills became more and more important than being able to develop software.
I have been a very prolific blogger recently as I have been very busy working on a project. We all want to work on glamourous projects but this was one of those bread butter jobs which really wants to work on but it pays the bills.
A big company who has an application that that they distribute to each of the sites, then each of the sites enters their data for that quarter and then submits the results to headquarters. All the collected data is then imported into the main database. Guess what the whole application is written in Microsoft Access and the original application dates back to 1995. Naturally, after that period of time the initial design is looking shaky and there are lot of hacks in the code. We were about 3rd set of developers working on that code base.
So what did I learn, rather than patching on a old application you need to bite the bullet and rewrite the application. Sadly, that is not an easy sell to the customer, so you end up plastering over the cracks and hoping the whole thing does not fall to pieces.
Why, or why do some many companies build mission critical applications on Microsoft Access and Excel spreadsheets from hell. I like both products but they should be used for what they are designed. Sadly there comes a point when developing a Microsoft Access application where it just becomes unstable and impossible to maintain.
I also learnt the vital "/decompile" command switch when starting an Access application that is throwing a weird error for no apparent reason.
With companies being so risk adverse, I have fear that this application will still be running in another 10 years time. I have already seen a compiled Visual Basic 4 application where the source code has been lost in mists of time. Now all people can do is simply keep it running, even if that means a standalone pc.
.Net is great but how on earth are we going to be able to maintain all these islands of orphaned code and who will foot the bill for rewriting the applications ?
Where I work, we manage the outsourced IT services of a global company. Last Friday, I was helping out on the helpdesk and we received an email from a site in Brazil who could not print production orders on a printer located in Brazil. I took the call and openned a call to HP who manage their SAP servers. I had to talk to their call centre in Bratislava, Slowakia so that they oould detmine the cause of their problems in their data centre in Swizerland. I then rang Brazil to tell them that I had openned a call with HP, to be told they were all at lunch for the next hour. This was 17:00 on Friday afternoon in Switzerland. It got to 18:00 and so I told the HP call centre to talk directly to Brazil.
Not bad, I am in Switzerland, the problem is in Brazil, the Call centre in Slowakia and the computers are located in Swizerland.
Also I had to talk to Equant about a problem in Italy and spoke to their call centre in Cairo.
It is a weird world
I have been thinking about writing about this subject for a while. However, the posting by Jason Sales prompted me to actually write a blog entry.
When I started in computing there were no PCs, just mini computers and mainframes. The UI was mostly a green screen on a dumb terminal. As all the processing was actually being done on the main computer, you got very used to checking how many concurrent users were logged in to the system.
Eventually, the PCs came along and it was possible to build form based applications, some application processed data that was stored locally or on a mapped drive and some clients accessed data stored in a central database. However, now you no longer had to worry about how many users were logged in to the system as all the processing power was local. This meant you got used to providing the best interface for the user, all the power was local so you did not have to worry about other users. I got very used to building forms based applications and the design metaphor used by RAD tools such as VB made the task very simple, some people would say too simple especially if you look at some of the code produced.
This gave way to the Internet and the ability to build applications that ran on a server and provided an interface to the user within the browser. In some ways it was like going back to the world of the green screen dumb terminal apart from this time it was more colourful. Like the world of the mini computers you had to worry about how many concurrent users were using your web application. I remember having conversations around that time with people asking me what is a concurrent user and why it was important. If you came to computing during the windows form phase, you had no experience to look back on from the mini and mainframe phase of computing.
Interestingly enough, people who came to computing during the "Internet age", tend to have started computing by building web interfaces.They have no experience of building windows applications. However, I have also seen the down side of people not having experience of the mini/mainframe period as they do not always think of the number of concurrent users. However, in many ways they are programming mini/mainframe applications but without the security of owning the connection. However, I think with web applications we sacrifice ease of use and gain location independence.
I suppose it still find it much easier for me to sit down and put together a rich client app than it is to put together a web application. I feel that I have freedom with a rich client app and that I am restricted writing a web application. However, I tend to build my components first which means I can decide later stage which presentation layer to use.
In conclusion, I think whether you are happier building web applications or rich client application is largely influenced by when you entered the computing industry. However, what worries me is that some of the lessons of windows forms development have not been learned. There are still loads of web applicatons out there which have all there business and datalayer code built right into the web forms. That is certainly true of PHP, ASP and probably a lot of JSP.
The most expensive part of any project is maintaince. You think everything is working well and suddenly you get a phone call and you need to resolve a bug in the application. The trouble is the application was written with an earlier version of the .net framework, for example v1.0 but you using Visual Studio 2005. This means you can open the project but if you compile it using Visual Studio you can only compile against the latest version of the framework which in this case is version 2.0. Which means the small change in the code might end up meaning you also have to distribute the v2 framework. The same problem exists with Visual Studio 2003 which can only compile applications to run on top v1.1 of the .Net framework.
However, in a regulated enviroment such as the pharmaceutical industry a change of the underlying platform i.e from the v1 framework to the v2 framework could result in you having to revalidate and retest the complete application. Of course using the SDK you can use the command line switches to compile for the v1 framework but is this really practical ?
It seems to me that we are storing up problems for the future where in order to maintain old applications I will have to keep various different versions of the Visual Studio IDE and know which version of Visual Studio I need for each application.
Mission critical applications need to run for years and will need maintainence and I am worried that there are going to be problems. It seems if I read correctly that the Sharp Developer IDE can compile against different versions of the framework. Why can't Visual Studio do this ?
Maybe Visual Studio should be distributed in the form of Virtual PC images so it is simple to swap between different versions.
Over the weekend I had some spare time, so I thought I wonder if you can use the Mozilla rendering engine(Gecko) within a .Net application as easily as you can IE ? This could be important in areas where people have concerns about using IE. It turns out it is as simple as a download, add COM component to the toolbar and if required adding a reference to the project. Even the intereface has been modelled on the IE model to make it simple to use. It is of cause unmanaged code but it works.
Visit Adam Lock's website http://www.iol.ie/~locka/mozilla/mozilla.htm and download the Mozilla 1.71 Active X Control Installer.
Once you have downloaded run it and will install the files you need and register the control. Now all you have to do is add the control to the toolbar in Visual Studio, using the add/remove Items| COM Components. It is listed as the Mozilla Browser class.
You can now drag the control on to a form as you would any other control. You can use the navigate method on the control to display a given url. In fact the api of the control is the same as the IE api, which makes life very easy.