Beacon Technology Part 1

June 16, 2013

Beacon Technology Part 1

After deciding to leave Rio Tinto in 2000 my job search was initially half-hearted. It was late in the year and not many jobs were being advertised in the run-up to Christmas. My plan at this stage was just to see what was around before starting a proper job search in the new year. However, the recruitment agent that put me in Electrolley happened to cold-call. With a fortnight I accepted the first job offered. I never regretted the fast move to the small independent consulting shop Beacon Technology (now they are part of a larger group).

The interview was not particularly onerous. I got all ready and went to meet a co-founder of the small 30-person company. It turned out in a previous job he worked with the founders of Electrolley and had already checked up on me. Since my references were good, the interview was more a friendly chat. The closest to a hard question came when the co-founder said he couldn’t pay me what I was on at Rio Tinto and offered a slightly lower sum. I suggested I would be happy to accept the lower amount now if after six months it was reviewed. We were both happy with that compromise and I started the new year at Beacon.

Beacon Technology was started by two workmates as a consulting shop, I believe after they were made redundant. The company soon acquired a key client by developing a large system for an insurance consortium. By the time I joined the steady money from this work paid for around 30 employees. Half worked on the steady, but “unsexy” insurance product; about a quarter worked on short-term development consulting projects; a couple of people worked as systems admins for a managed hosting business (the main clients were insurance companies); and, the rest were support (managers, assistants). I joined the smaller consultant developers team. Considering the time (early 2000) much of our work was for dotcom companies who had problems finding developers. The more senior people (mainly the founders) did some software development process consulting.

Beacon was a strong proponent of the Rational Unified Process (RUP). The company was even the authorized Rational reseller for Western Australia. Not much marketing was done, but there was a steady stream of interest. Some of this resulted in consulting work, some in development work and every few months a course was held. All developers needed to know and use the RUP (and most of us went on the training course too). Although the managers took a very practical approach towards the very extensive and detailed process (an important point often missed by clients and others using the RUP). Use of the Rational Rose modeling system and UML diagrams was effectively mandatory, but then it was mad not to use them as the company had developed such an impressive set of tools and plugins around them. Their tool to generate code from Rose models was particularly good and better then the inbuilt version (I suggested Beacon could sell it, but the owners weren’t keen on that idea). The core ideas (iteration) and documents (use cases) were always kept. Apart from that it was all optional as long as you had justification for the decision. Parts of the process were happily dropped as deemed necessary on a project-by-project basis. Beacon was also the first placed I worked with proper testing. The testers had to be happy with anything the developers produced and they definitely tested well.

The company’s focus was on practicality and a “get it done” attitude. This was something I learnt starting from my first project. At the time the dotcom boom was reaching its peak and there was a good pipeline of development work for various “ideas” people and bricks’n’mortar firms desperate not to miss the boat (and prove they did “get the Internet”). Interestingly while the boom started turning to bust just a few months after joining Beacon (March 2000), the dotcom work didn’t start drying up until the end of the year. I first worked on a B2B ecommerce site. I think it was specifically for hotels. Another relatively new hire acted as project leader with me being the only other person on the team. He was seen as an old hand, having done consulting development work for over 15 years. Beacon had no age discrimination - they also hired an over 40+ guy who had just graduated with a Computer Science degree after a first career as an itinerant English teacher and surfer in South America.

I was a little arrogant after getting Electrolley’s website running largely by myself and then working among the PhDs at Rio Tinto R&TD. I went from being one of the least educated in the workplace, to being one of the most educated. I thought I knew exactly what I was doing, but got a rude awakening. My new project leader taught me the benefit of experience with a practical outlook. If I complained about some poor code someone else had written, he would ask if it worked. If there was a problem with it he would ask how I planned to fix it. At one point I had a plan to create a monumental generic data-driven bootstrapping config system. The project leader said it sounded ambitious but let me try writing it on my own time. A fortnight later I came to tell him the technical reasons it wouldn’t work without making the situation worse. I got the impression he knew how it would end before it started and just wanted me to see the hard way that simple solutions often work best. From him, I learnt that the main job was fulfilling the customer’s needs and after that had been achieved we should focus on architectural purity and beautiful code. Both are important, but complete and correct functionality is foremost. We could also (and often did) refactor after knowing what was required.

There was some quite awful external code to complain about in the B2B project. It had been mandated that we use a B2B system sold by a large US firm. The client had purchased this system before working out what they needed and so hired us to add all the functionality that the system did not provide. I saw this “buy first, then work out what to do with it” attitude twice among Beacon’s clients and once elsewhere - I can only assume some salespeople are incredibly persuasive because I just don’t understand it. Some of the functionality requested required us to hook deeply into the purchased system’s code and we worked out a way replace the system’s code with ours (by playing around with the classpath). To do this properly and legally we needed the system’s source code, but the US firm was reluctant to give it to us. While negotiations for the source continued, we decompiled it so we could get started. We mightly cursed the decompiler. The result was an awful mess of spaghetti code, long rambling methods with no comments and meaningless names - just bad code. After battling through and completing the project the US firm finally gave us access to their source. Then we did mightly praise the decompiler. The decompiled code matched perfectly the code supplied to us - even down to the “x1”, “x2” variable naming scheme.

After the B2B site, I worked on a website selling alcoholic drinks. My task was creating the payment gateway. It took the credit card details and communicated with the bank to ensure correct payment. The difficulty was that the client wanted to be able to handle thousands of transactions per hour and the gateway had a little bug that caused sporadic slowdowns. A set of multithreaded payment queues solved the issues and we successfully tested the system well past the desired throughput. When the site went live, one of Beacon’s owners was the first person to put an order through (and on his personal card). I was very nervous, but it worked fine. There were also no payment problems for the next 100 or so orders that occurred before the site went bust 3 months later.

After that I worked on adding functionality to an existing system for a bloodstock auctioneer. I never even knew such a business existed until starting work on the project. Bloodstock auctioneers arrange the sale of thoroughbred racehorses, usually through a few large auctions held annually. The value of such a horse is determined largely by its genetic potential as demonstrated by its results and its ancestors results. In fact a horse is bordering on unsalable if it is not possible to show its lineage back to the original three thoroughbred stallions brought to England from Arabia in the 18th century. Thus it is vitally important when selling to have a large database of thoroughbred family trees and racing results. The auction catalogue would detail the horses’ results (which the seller usually knew) and the notable results of ancestors (which the seller usually did not know). Beacon had produced a system the previous year that given a set of horse to be auctioned, looked up their details and ancestors in a database and then produced the auction catalogue in both PDF and HTML for publication. For a few months I adjusted the rules determining what counted as “notable” and prettied up the output according to the client’s wishes. It was easy work as the existing code was beautifully written and easy to modify.

When I had been at Beacon about 8 months I reminded the owners our agreement to review my salary. They apologised for forgetting and arranged a date to discuss it. To prepare I looked around the other developers at the firm. I explained the situation to one who I thought was equivalent in skill to me, and asked if he would let me know the rough range of his salary as I would ask for about the same. He stated a range where the top end was just below my current salary. I was shocked, but had no reason to disbelieve him. I suggested he might be able to earn a bit more elsewhere. He replied that Beacon was the best placed he had worked and he didn’t want to go elsewhere. When it came time to meet with the owners, I said any amount they suggested would be fine - and meant it. They offered a 33% pay raise. I accepted feeling a little guilty. Luckily the questioned workmate never asked the result of the meeting and I never talked about salary again at Beacon.

Thus ended my first year at Beacon. The company was nearing 50 employees and had expanded onto a second office floor. There was always work to do - no bench time at this consulting shop. I was quite confident and happy about my time there and ambitious to do better. The second year was not so happy.

Part 2 is available here

Full Archives

Recent Posts:

Top Tags: