Category: Tales from work

I remember the first “big” database system that I programmed. It used the paradox database engine and was used by insurance agencies as a convenient way to look at, print out and generally track their policy holders. It was reasonably lightweight program, the output was displayed in text windows, think MS DOS, and was pretty fast.

Not only fast but it was possible to setup commission structures and load the agencies renewals from disks, make a lot of calculations and print out who should be paid, and how much – pretty nifty actually.

Well, it did have some drawbacks, such as being tied to a specific printer model as well as being more prone to failure when it was run on any of the newer flavors of windows. I knew this would be a fairly risky platform to depend on in the future so in my free time I wrote a new one, a better one. It used Microsoft Sql server as the database, it had a very nice graphical user interface it was beautiful.

There was just one little problem. It would be necessary to import the data from the old system into the new system and to bring the user up to speed with the software. I can appreciate you need to get your job done and learning a new system may not be the highest priority, but Lydia seemed to bring up new reasons why it couldn’t be used rather than how it would help her. In that sense, I guess time was on my side as Lydia did eventually leave and Marta was really quite eager to get the new system implemented.

Ok, ok, the new software was complex but it did seamlessly support all of the insurance company’s policy holders. The old system was a bit hard coded as only one company could even provide the data electronically but that was the mid eighties. In the new millennium, it turns out that only one of all the companies could electronically provide the policy holder information. Just like 20 years ago only one company could provide the renewal information electronically which didn’t seem to be an improvement.

That isn’t to say with the computer revolution that the other companies couldn’t provide their information electronically but they all chose a different path. The information was available but it was only available online. If you needed to look up information about one of your policy holders you went to that companies online portal to check. To be honest, I cannot say that I blame them a bit. This gives the insurance companies full control over their customer data, which given the recent data security laws is quite reasonable.

The thing that I find unique was that in the intervening 20 years it was still not possible to receive the client renewal information in a machine processable file. Yup, this information was available to be downloaded and printed out but nothing straight forward where the data can be simply processed.

The agency that used my software was going through reams of paper each month and making entries in excel spreadsheet. This file was loaded separately by my program as a list of exceptions.

My system was really neat. It kept an account balance for each agent and did automatically load the data files that could be fed to it. It was a reasonably complex piece of software for a small company and 95% of the companies couldn’t provide any input files to support this level of complexity. The software solution was too complex so the only reasonable solution was to re-write the software yet again but this time with the goal of simplicity.

The new solution was that all the renewal information was entered into an excel spreadsheet and exported as a text file. The text file was processed by a simple program which read the text file and output a PDF file for possible printing. I can understand how this very simple almost fool proof solution would appeal to a small company. It is a disappointing counter point for the 21^st century. The final solution was to manually enter and calculate all the information and then print out reams of paper.

I was having lunch with someone from a large company and we were discussing various problems when he mentioned that his boss offered him to work from home 100% of the time. I was amazed as from what I had previously heard this company was not very flexible on that particular type of work style.

I found out the reason actually came down to money. There are actually very legitimate reasons to cross charge between different departments. It ensures that the resources are used as productively as possible. However, I think that the group that manages the property took this as opportunity to try and become a profit center internally.

I didn’t know how much to expect but I was told that his office space would cost his department 1200 EUR per month, which considering that their single room was beyond the edge of town seemed a bit excessive. I thought with a price tag like that it must also be “all inclusive” for some of those other little things like phone and network infrastructure, but sadly no, that costs extra. As a matter of fact, each phone cost extra excluding actually calling people. He didn’t say how much this charge was but it must have also been fairly high as his department was simply renting a office with a single phone and lot of desks. He was instructed that if he needed to make phone calls he should use his company cell phone.

Our lunch was delivered about this time so I never heard about the other costs that were associated with his having a laptop, cell phone and software. It is possible that they were a bit more reasonable, but I wouldn’t count on it.

I guess not every software product is beloved by the people who actually use it – ask around. It turned out that after a reorganization our office was now going to provide support for the Nordic countries. This meant that one of our “new” customers was a large government institution in Finland.

This is not a problem but it seems that since we sold them <redacted> they have not had exactly the best experience. Part of this was not our fault nor was it really the fault of our colleagues from the prior group in the UK, the client choose a supported version but the client picked an unpopular version of our software running on rather niche hardware. There was nothing wrong with the hardware but running on AIX over a fairly slow network to the data center using X windows. The machine was slow, the network was slow and the overall result was that of sluggishness.

We visited the client, the sales person and I, in order to introduce ourselves and to try and keep this somewhat dissatisfied customer happy. Before we left we were warned that the Finnish people were a bit reserved and that we should keep that in mind. It was true although nobody was scowling at us, I don’t really remember many smiles.

The software, while not perfect, had made quite a few strides since it was installed at the client and had even been ported to the PC. In one of our meetings we did an impromptu demonstration using my laptop. A fast new laptop running its own sql server and our software. It looked good, it performed well and was a very effective demo.

The thing that I will always remember was one of the quietest people in these meetings was very interested in what the new software would do. He became excited and animated and was asking about how they could get this software.

It was a breakthrough, there was a lot less tension and a lot more smiles after that. Yet, I don’t know if he broke some sort of written or unwritten rule. After such a large showing of animation and enthusiasm we did not see this particular person at any more of our meetings over the next two days.

One of the really convenient things about working on a large international project is that typically the common language is English. It might be possible to have an all German project in parts of Europe, an all Spanish project in parts of North or South America or even all French project in Africa or some parts of Europe.

Yet when you have a project that covers the globe, you usually end up with English as the common language. My German was limited but the good news was that all meetings and project documentation would be in English.

To ensure we were adding quality to the project, the documents where reviewed by no less than three different groups. The first being other developers within the group, the second group was the project IT department and the last was an auditing firm.

English being my native language may have helped with the writing but getting the documents approved was a different matter. The other developers wanted more details on what my work did and the auditors wanted more information explaining about finance. Try as I might, I was never quite able to explain that I should only be explaining my program and financial terms should be learned elsewhere. If you were looking for sheer length then my documents were doing the job, well, except as far as the auditing group was concerned.

It was slightly above my pay grade but my manager was interfacing with IT and there was a problem with the quality of the documentation, well, specifically my documentation. Freddy, the person who was in charge of that department had the comment that these documents where written using “English for run aways”.

If the company is large enough, it should be possible to get a couple of impartial people to review and report on the content. The project hired a special person who had an understanding of both finance and English to report on the documentation.

In the end, the review showed that although the documents may not have been timeless literature, but they were not written by run aways.

Everyone knows that computers are really fast, unless you are checking in at the airport, and they know everything except the one fact you want. It should also be no surprise that they tend to be expensive, not just the purchase but also the maintenance.

I was pleasantly surprised to hear that on my latest project the client had decided to use an automated test tool to ensure each time we install a new patch from the vendor we can verify that the existing functionality still works. To write such software on site to track every mouse move and click is more than we could handle so the project started looking for an existing out of the box solution.

I guess it wasn’t that much of a contest as the package that was found would fulfill all of our requirements – all, not just some, but it cost six figures. Ouch. Not only that, the software license was tied to a single project and for a single PC. In general the most restrictive licensing that I had heard of, then or since.

It turned out that the IT department actually had a couple of unused license keys, so we don’t even have to go very far to get it. There is just one catch, IT wants 50% more for the software than to purchase it directly from the vendor.

It is not clear to me what additional benefit the IT department could add in this situation and the project management felt the same way. The project purchased the software directly from the vendor. I guess the project saved 50% but I guess the company spent a lot on software they already owned.

We work in a multinational consultancy and do software development for companies all over Europe. We are located in Slovakia and our current client was in Germany. Although some of our developers could speak German none of them were native speakers but most of our developers could speak some degree of English. The client wasn’t going to learn Slovak but were content with the German and English support that we could offer.

Ladislav actually had a lessor grasp on English than the rest of us but he had a lot of self confidence. Even though he knew that he was not native, he felt himself to be quite advanced. When Ladislav was at a loss for a word, he would resort to an online translation tool. The thing with translations is that there is no single perfect word that can be used in all situations. The words that come back are usually ranked as most common first and then moving to more esoteric translations.

What made Ladislav’s emails interesting was because when ever he needed an English word he would do the translation and then take the last translation in the list – well because the others are just so common. I am not a big fan of most of the things that end up in my inbox but I always loved receiving something from Ladislav.

At the end of every year some things need to be done, some are because we are a public company while others are just planning for the future. We need to calculate what our profit is for our stock holders, we need to calculate how much in taxes to pay for the government and we want to make ours a lean organization.

One way to do that is try and consolidate as much as possible, get rid of things we don’t need and while we are at it why don’t we limit the number of vendors we do business with. This should mean we have fewer companies to negotiate contracts with, and we have fewer groups to discuss about pay increases with. The thought sounds pretty good, but does this really make sense?

This probably makes sense for those firms that have dozens or hundreds of people working for our company, but what about the HR group? Some of the custom HR systems are being managed by three guys, one from a small firm and the other two from a large consultancy. He has been here so long, it isn’t easy to simply replace the one guy, so we will force his company to go through the larger consultancy.

This is actually a double edged sword, now the consultancy has all three people which is a combined total of 23 man years experience on those systems. To make things even more interesting, they added a few extra clauses to this years contract. The contact now essentially says that these guys can work remotely unless there is a specific reason to work locally.

This sounds great for the consultancy, and even better should the client ever change their mind. I can pretty much imagine what is going to happen in about six months.

Client               Well, actually we do get better service when your guys are on site

Consultancy Yup, not a problem the new rate for our guys on site is X.

Client               Uh, wow, that seems like a bit much

Consultancy Well, the old rate was for mostly remote support

Client                (under breath) who’s idea was it to change the contract to move all the externs off-site?

Client2            (whispered) uh, that was Finley’s idea.

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.