Category: Tales from work

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.

Did you hear about the project that had more money than they could spend? Well, it isn’t quite as simple as that but close. The first phase of the project had problems, went over budget and was delayed but it made an amazing comeback. By the end of the first year, the new system was wildly successful despite some of its short comings, it was decided that there should be a second phase with more functionality.

This is where things get a bit sticky. It is quite reasonable to create some sort of a specification/road-map so we have a plan on what to work on, which is exactly what project Zinger did. Yet due insufficient internal sources and scheduling conflicts instead of getting this finished early in the year it wasn’t finished until the end of June.

The project cannot take this money and start until they have a plan and thus only 100k of the planned 550k was used by June. The project is behind and it is unlikely that they will be using much of the 700k that will be available for the second half of the year. Under normal circumstances you would think that not “pissing” away a lot of money when you are not prepared is a good idea. However, the normal budget rule will take precedence

“Use it or lose it”

Next year when the money is needed to finish up what was started it is almost certain that the budget committee will see that they needed considerably less than originally planned amount for this year and will cut accordingly.

Yup, computers are everywhere. It was the early nineties and personal computers were really taking off in offices. I felt so strongly that computers were the future that I helped a small insurance agency computerize. This small agency actually did most of the hard work by hand but they learned of a custom software package that filled this niche. I met with them and we looked at what the software would support, it was actually a nice little package which could support a number of different products, agents and payment structures. I thought it was a bit pricey but we agreed on terms and so both the accountant and I were to go back for another visit to teach her how to use the new software.

Dorthy and I drove there and again met with the developer at the agency. While she was learning about how to use the software I was discussing what hardware we would need and learned about the installation process. This wasn’t installing SAP or Oracle, we were only going to be there for two days.

Before we were sent, nobody had actually explained one of the tiny little detail. I only knew that we were staying at a local hotel. Between the driving and the workshops it was a full day but eventually it came time to check into the hotel. I simply walked up to the reception desk told them my name and company and they gave me a room key. I didn’t know any better so Dorthy and I went to the room, unpacked, had dinner and went to bed. Well, I am not entirely certain who was more surprised the next morning. I received a wake up call from my father, but it was Dorthy who answered the telephone. She clarified that he did indeed did get the correct room and handed the telephone over to me.

I cannot remember most of that conversation but my father, the boss, did explain that he did reserve two rooms one for each of us and that it was not necessary to share. Actually nothing did happen, but that could have been due to me being the boss’s son, and that the boss’s son wasn’t so experienced.

Yup, smart enough to set up the IT infrastructure single handed but not smart enough to know that the office doesn’t force the staff to sleep together on business trips.

Perhaps everyone who has ever heard about the budgeting process has heard examples of what could best be described as binge spending at the end of the year. The department was given a fixed budget and if it wasn’t used up by the end of the year then the common consensus from the big bosses is that they were given too much and next years budget should be smaller.

I always thought that getting new chairs, monitors or even a new coffee pot in the middle of December were probably not in the best interest of the company but I did like the coffee. Yet, I thought that expenditure was about as crazy as it could get.

Imagine my surprise when I was speaking with my brothers girlfriend. It turns out that the bigger you get the more complicated it gets. At her company all the same types of yearly budgetary magic was performed. The most typical questions is how much money do we have? How much is needed for which projects? Is this a project that is continuing from last year? I also suspect that projects for some people or departments are prioritized over over others – requests for sales vs requests by human resources.

None of what she said really surprised me too much, well, until the budget is approved. Once the budget is approved, the process is still not over. It seems that once the budget is approved they sometimes pick a number out of the air and then shrink budget by that amount. I guess it could be quite traumatizing for the department that received an approved budget for their small projects only to find out that money wasn’t actually forthcoming.

In her company this is a completely separate process so that budgets are approved first and then only some weeks later the departments find out if they really will receive the money. I would have thought that this entire task would have been done as part of a single comprehensive budgeting process.

Nope. Apparently the development department thinks differently than most of management types.

It was a long day and it was looking like it would be getting even longer. To release my program to production would require a number signatures before I could even begin. In a pure development environment I was used to having a list of changes as long as my arm that I was expected to work on as soon as possible but as a consultant things were a bit different. You cannot simply make changes to a production treasury system because you didn’t like the style of some of the code or because you would like to test out a new technique. The amount of paperwork that is required for even the smallest change is unbelievable but after enough people signed off on it, I was permitted to begin a change that the users wanted, nay, needed for future expansion.

It was late and I was hoping to get in some development done without any interruptions. It turned out that not everyone had left. It seems that Pitr was also on a mission and also enjoyed the quiet when most people had left. Just a bit of background, the production downtimes are the third Wednesday every two months. They are not guaranteed to occur but more often than not some fix does need to be released. The year is 2013 and the production downtime plan has been published for the remainder of this year and next but it seems that isn’t good enough for the accounting team. It seems that they wanted to know what the plan will be for 2015, yup two years in advance.

I can understand a bit of planning but perhaps it wasn’t quite clear that these downtimes are for only two hours and they are not even guaranteed. Well, Pitr had a solution. His idea was rather than answer these types of questions piecemeal he spent most of his working day writing a macro to generate the list of dates.

Well, I cannot say how much of his time it did indeed take to create the macro, but I can tell you how much of my time it took. I was in the middle of debugging my program when Pitr came to show off his programming prowess. He didn’t take any hints that he was preventing me from finishing my work. I spent a good 45 minutes listening to the rational behind creating a macro to generate a list of downtimes for the next 22 years.

It is not clear if the treasury will even continue to use the software for that entire period, but we now can find out when any downtime is on any environment from November 1st 2011 until December 28th 2033.

Even though I would have originally thought that this is the end of this story it is not. If there is any unexpected change to this plan for any of the seven environments over next 22 years, then the downtime list will need to be manually amended with either the unplanned cancellation or the unplanned downtime. The only thing that I was certain of was I was happy that Pitr wasn’t my employee.

I came to work and was speaking with Ezra, one of the other consultants at this project, who was regaling me with his weekend and climbing adventures. It was pretty normal stuff until he said that the consulting company that he was body-shopped to wanted him to reduce his hours. He dutifully passed this information on to his employer.

It is a very weird construction that came about because the project client demanded a single invoice so all consultants working for this project had to be ultimately billed through a single company. I was going through a different agency to this consultancy so the client did have a single invoice at the end of the month.

I was curious if Ezra would have to reduce his hours only to learn a few days later that he might be leaving the project at the end of the following week. This actually was for personal reasons but it all came to a head because of the difficult working conditions. The difficult working conditions were mainly brought about by the long chain of companies involved in his contract.

The main consultancy and his company both insisted that the actual client was not to know that Ezra might be leaving. This seemed a bit unfair in my opinion to the client but Ezra was told that they would be informed in due time. Every few days he would send mail to his handlers in Austria to be told that everything is going ok. Finally, Ezra told his handlers that if he didn’t hear that the client had been informed by Friday morning, otherwise known as his last day, he would have to tell the client.

The next morning came without any word, so Ezra had a coffee with the project manager and explained the situation. Of course a few hours later he was told that the project didn’t want him to reduce his hours and that they hoped he would be staying with for a long long time. Ezra was a pretty easy touch and did remain until the end of his contract. Unfortunately some months earlier the client had forced him to change to a three month contract which was expiring in ten days.

So Ezra stayed for a little over a week and left anyway.