Author: funatwork

The IT specification has been written and was passed on to my manager two weeks ago. Next week we will sit down and do an internal review prior to passing this to the support organization. In some sense there is no urgency as the data extract is only part of the overall project. The data will be extracted from our system and the main project will create a database and import it and enrich it, create various reports for yet other divisions.

Why isn’t there a rush to get this IT specification into the hands of the support group? It turns out the requesting department does have budget for their end of the project but no resources to begin. The actual problem preventing them from starting is they are missing a project leader. Further, company policy prevents the hiring of external consultants for certain roles – one of which would be project leader.

I was working on a much larger project but my boss wanted me to take a small break. There was a small data export project that was required by another division. The support group said it was trying to find the best solution but they were really stringing the business group along. First analyzing one technology and making promises of delivery, then starting all over with another technology a few months later. The process had been going on for more than two years with no solution in sight. The business department, with managements approval went directly to IT with a few questions.

Is this possible?

What is the estimate?

The IT department did a small proof of concept over a few weeks to check the feasibility of such an interface. Well, despite being in the middle of summer vacations it was possible to rally enough of the business people and the IT people to have a successful test. It was suggested with a very modest budget and 4 – 6 months of developer time it was possible to deliver all of the business departments requested functionality.

Of course the business group rushed back to their boss two levels above everyone else to insist that this was the path to success for the future. Thus it was ordered from the big boss himself to the support team that IT should do the data export for the business department.

In order to continue, we would need the same expert resource who did the proof of concept. All this was made more complicated by the fact that management had just told the bosses to reduce the number of external consultants, and so each boss had passed this golden nugget of wisdom to his subordinate until it hit our bosses boss. Well, it was more of a historical anomaly that we had three guys working in one group from two different companies who were supporting the financial interfaces.

In the same way that most fairy tales start, a long time ago in the deepest unlit corner of the building was an interface team and they were staffed by a single company. This company shall remain nameless as it offers no addition insight on how things happen (or don’t happen).

Over the years the technical support group was slowly being whittled down due to attrition as well as design. One of the remaining project people, Paul, was tempted to go work for a small insurance company that was starting to get into banking and so he jumped at the opportunity. But Paul was a good guy and was familiar with the interfaces that he had supported all those long years, so rather than a nice clean formal handover of the interfaces his new company stepped up and offered their services to fill Paul’s spot with, well, Paul.

Then came the dark time, when financial ruin cast clouds over all horizon and the support contracts were made more and more restrictive for less and less cash. This strange constellation was accepted due to the current budgetary strains. Eventually Paul gave way to Martin, Andreas, and finally Zachary. Zachary was a very quick study and learned his tasks and became indispensable

in his own area.

Yet, Zachary was no match for Boss Finley who had a real penchant for following dictates from above despite how unrealistic they were. The handover was never formally made but according to all the contracts Martin and Juergen who were officially supporting all activities related to Zachary’s interfaces.

Thus a plan was hatched by my boss. We would try and get approval for Zachary to create the new extract program. If we could do this we would have Zach back at his desk and all the “know how” for his interfaces would be once again under our control. However, if Zach was supporting his old interfaces then who would create the data extract program. We will have Zach supporting the interfaces that Juergen and Martin should be supporting so then Juergen and Martin would write the extract. Actually, as bizarre as it sounds, it could just work.

It was the end of the year and there was the usual end of year budget fiddling, but we managed to get our resource. Zach would start a bit later than expected but he was back at his desk before the end of January. The project team was not ready for him so he did general support and ad hoc tasks.

The project itself should be starting in February or March but Zach, or well, Juergen could start immediately.

Well, work did not start immediately, but use of the budget did and for that reason it was actually lucky that Zach didn’t start until the end of January. However, work on the data extract was indeed well underway by the first of March. It would have been great style to begin with a specification describing which systems reports would be required, which fields would be extracted, and what the format the output would look like. Yet most of these questions had been answered during the proof of concept, the format was decided in the interim to be simply a comma separate file as the project group still didn’t really exist yet. Most everything was clear.

It was not so clear cut to the support group who owned the system and who did not want the export to take place. There were two reasons for this. The good and the petty. The good reason was that any new data extract processes that should be installed on their system could impact them and thus must be thoroughly vetted. The petty reason was that if indeed this new data export was successful, then a portion of their kingdom (and budget) would be going to another department, and they just couldn’t have that.

This meant we had to write a specification including testing and performance. It is not that these are unreasonable requests but typically this was the type of request that should have been done after the proof of concept seven months before, or perhaps even at the analysis for a budget 4 months prior. Shucks, it could have been requested at the beginning of the year prior to the external resource being contracted.

It seems to be a bit of gamesmanship between different groups especially when the IT department gave an estimate that was perhaps 20% of the time and cost of the support groups estimate for purchasing and configuring some additional software.

I like a cup of coffee but my favorite cup is white and starts to have a nasty look after a few cups of coffee. There is simple a solution, simply take the cup, add dishsoap, hot water and do a bit of scrubbing. It pretty much always works. The client actually must truly think that cleanliness is next to godliness as in every kitchen is a really big bottle of cleaner. It is generic cleaner and can be used to clean floors, sinks, dishes, pretty much anything. The bottle has a label with fifteen different languages describing the contents.

The bottle is fairly horrible looking which makes you think of cleaning toilets and such – who wants that image in their head when cleaning their coffee cup. That’s why I actually purchase a popular dish soap and bring it to work. I am not Rockefeller so I usually purchase a generic dish soap. It only has one language and it is supposed to do a real bang up job according to the commercials.

I had started bringing in dish soap some years ago when I discovered it is a cheap effective way to have a clean cup for my coffee. I was the only one who purchased it but not too many other people used it and those who did used it sparingly.

Imagine my surprise one day when I came into the kitchen to use some soap to discover that the new bottle from yesterday was now half full. The only thing that I can imagine is that somebody else also had a bottle of dish soap and one day while wandering the halls (instead of increasing shareholder equity) they found what looked to be a new source of free soap.

Is embarrassing the right word when the people at work “borrow” soap like this? Almost assuredly everybody at the client makes a very comfortable wage and should be able to purchase their own 0.79 cent bottle of soap, well, a few days later my cleaning sponges started to disappear as well.

A long time ago an optimistic software developer wrote a program to process confirmations forms for the back office of a fortune 2000 company. The task itself was quite simple. The forms were already created as PDF’s and each form had file with the same base name that contained sending information. The program was run every five minutes and as an added bonus if an error occurred, it would send an email to the support group.

One of the requirements was that if for some reason the confirmation form could not be processed, it should be processed on the next run. The reason for this was that the only failure that we was really being planned for was that the Lotus Notes server may be down. Perhaps I was a bit too simplistic in my solution as it was also a tacit assumption that the data would be setup in the database correctly. I had believed if there were any confirmation forms that somehow could not be processed we could get them corrected or deleted.

When this new bit of functionality went live on production it disproved most all of my assumptions. The data in the database was poorly setup and it was impossible to get IT do assist in the correction or deletion of bad confirmations. In the morning there were a couple of poorly setup confirmations, but by the end of the day there were in the low twenties. It was embarrassing enough that the forms were not being sent out as designed, but there was one additional problem. Because this was the big go live, I had added my email address to the mailing list that should be contacted each time there was an error.

Every five minutes I would receive between two and twenty error emails. This was not a very positive beginning but it was actually worse than that – today was Friday. If this was not corrected I could expect hundreds or thousands of error emails in my account by Monday morning. It wasn’t corrected and I did have thousands of emails to delete.

The good news was on monday my account wasn’t receiving any new emails as IT had frozen my account after they saw how many emails it was receiving. I felt that it was somewhat ironic that my program would eventually lock my email account. Eventually we got most of the bugs ironed out but it did take IT almost a week to re-activate my email account.

The toughest pill to swallow was that my email account was essentially spammed by my program.

Most adults spend 1/3 or more of their working lives well, at work. Because of this you should try and pick a career that you enjoy or at least one that you don’t detest. There is one more part to the equation which is the people you work with. You can’t always get awesome colleagues or bosses but if for some reason it all goes badly, you can always change companies or depending on the firm, change position.

Albert is a responsible guy who has been with the company for years and for the last decade or so he has been supporting the payment system. During his tenure at the company he has seen a number of people cycle through the position as his boss. It is inevitable because to increase your chances to advance within the firm you need to have shown that you have a wide breadth of knowledge of different departments.

You don’t know what you have until you loose it. The “bosses” who have been in this position up until now have been really good but now we have Frederic and he is pretty much a disaster. His background is not IT and nor does he seem to have much interest. His interest is to manage or perhaps better put would be to say his interest is to micro-manage. This may make your skin crawl, but if he at least understood the issues and kept up to date with what is going on it might be tolerable.

In any large company does have its share of political intrigues but it is really saying something that Albert cannot take any more of this. He did some hunting around within the company and has found three possible alternate positions. So without any apparent malice he has simply informed his team leader Frederic that he will be leaving. I was expecting a lot of things, perhaps some promises to keep this support star in the group or perhaps trying to organize a longer than normal handover with some really experienced new comer.

The official reaction was thanks for working with us and good luck. The behind the scenes reaction was, “Wow, this is great. We can actually try and re-engineer this team. Our best bet is to get somebody fresh out of school. Our department will save money and the process will continue”.

Don’t believe the hype, there isn’t anyone who cannot be replaced. Yet in this case it might not be exactly true. Arnold works with Oscar to ensure that the payment system, or more accurately put The Global Payment System, is always up and running.

Oscar has been working with Arnold for the last ten years and there are still things about the payment system that he still doesn’t completely understand. When Arnold went on vacation no new changes were ever implemented on the payment system. I would even be hesitant to say that he even has a true vacation as he must always be reachable. Things will be tough without Arnold but the worst is probably still to come. Oscar is just as dissatisfied with his team leader as Arnold and is also looking internally for a new position.

The spotlight will be on Frederic if anything happens, because it is just as true now as when it was first said by Harry S. Truman

“The buck stops here”

I don’t know how high his visibility in the company is now but if the employee and vendor paychecks fail to go out on time Frederic will get a much higher visibility in the company than he ever anticipated.

We have been installing software, having meetings, and customizing software. The unit testing and integration testing is now complete. The final task is that we need to schedule the go live date.

Uh, nope. That project was canceled about three months ago, didn’t they tell you?

Apparently this exact scenario happened to a colleague of mine when he worked for another company. I thought that was only the type of thing that happened in a Dilbert cartoon.

With the rise of internet, people have more and more passwords. Well, if you are a typical user, you have a list of passwords. It is usually considered bad style to reuse the same password at multiple sites. This is becoming especially important as the user’s login id is usually the email address. Thus if you know one, you know it for a lot of sites. Of course, the IT department either gives you some “intuitive” rules to follow ever time you change your password.

Your new password should …

• • • never reuse a old password
    • Not be a name or a word
    • be longer than 8 characters
    • contains letters and numbers
    • contain one upper and lowercase letter
    • contain at least one symbol
    • never be written down
    • be almost impossible to remember

Well, perhaps not the last one. None of these are terribly difficult to follow, yet as the number of passwords start to get large changing your password every 30 days is more than just a pain but actually to be creative each time gets harder and harder.

Going through this exercise is especially important for important systems, but perhaps such harsh rules are excessive for unimportant systems. While working with one of these rather unimportant systems I did discover a small work around. This bug tracking system actually had all of the rules so you did need a strong password, but it actually did not implement the check for the first rule. Every 30 days you needed to reset your password to a new password but you could reset it to the same value each time.

Thus the password is always the same, easy to remember but perhaps not so secure. I suspect that Harvey forgot to test that prior to putting this system into production. Oddly enough, I never did mention this fact to him.