Office Politics

When you work with other people, “office politics” will always be a factor.  I have heard people say that they did not like office politics as if it were something that they could avoid.  I am not talking about the sort of “Office politics” resulting in the metaphorical stabbing of fellow co-workers in the back. It is true that office psychopaths definitely attempt to manipulate co-workers for their own purposes, but a lot of daily interactions can also be seen as a form of “office politics”.

Internal restructuring has seen my role change recently.  I was working on a framework team, providing code (and various other infrastructure) to various teams in my company.  My “customers” were the teams that wrote the applications that sold to the real customers…  That is, the ones that paid money!
Since the restructure, I have been moved onto one of these teams as a senior developer.  Former “customers” are now team-mates.  When I was working on the framework, I had a certain perception of how our code was being used to create the end-product.  Now that I have become exposed to their code base, I have discovered the truth behind how they use the framework code!  The fact that there are differences indicates some degree of a breakdown in communications.  There is nothing catastrophic about what they have done, but it shows a disparity between the directions the framework and end-products were heading.  This difference was due largely to the difference in motivations between the two teams.

The framework was responsible for the core of twelve different applications.  As such, consistency and flexibility in the architecture were highly valuable commodities.  I would not be presumptuous enough to claim that we succeeded in providing the perfect architecture every time, but those were primary goals of the code we wrote.

The end-products have a far more tangible goal: To make money.  I am not in product management, but having developed commercial software for a long time now, “making money” tends to be about writing software that adds features that customers want and alleviates the worst of the bugs that have been reported.  In terms of priority, “adding wanted features” are more important.  Trade shows never focus on showing customers how the software no longer crashes when you do steps X,Y and Z!

In terms of how this affects code in the long-run, there is a natural tendency to leave “good enough” code alone.  Short term deadlines enforce short-term thinking.  Commercial reality allows code to deteriorate in rather the same way that an untended garden becomes an overgrown jungle.  Active pruning and weeding would avoid the problem, if only it were seen as an important goal.
Given that the software still sells and still provides real value to the customers, it can be seen as an unimportant goal.  The fact that new features become difficult to shoe-horn in to the existing code base is seldom given consideration when writing code.  Which brings me back to my original point on office politics.

Now that I am on a new team, I see the “weeds in the garden”.  No individual issue is worthy of much attention, and so the existing team members simply ignore such issues for more important work.  I would highly doubt there is a piece of commercial software being sold that did not have some degree of this occurring in their own code base.  I have worked alongside my new team members for many years.  They know how important code quality is to me and I know that they will expect me to try and improve their code’s overall quality.  Here is where the “office politics” lie.  I could just blunder in and make changes which I believe are for the better.  I have known programmers who would.  Different cultures in different parts of the world would probably react differently to such an “intrusion”.  In Australian culture, this would not go down well and so it will not be the approach I will take!  I’m also someone who is only too painfully aware of their own short-comings as a programmer. So, tact and and a measured approach, remembering one’s own shortcomings will definitely be the order of the day.   See, even in the most ordinary of jobs, “office politics” will play a role!

Who needs a battery anyway?

Having built my “under-seat” tray to hold the CDI and SAPC units, all that was left to do, was to place the battery somewhere.  Part of the problem of owning a track bike, is that it is unlikely to see regular enough usage to keep a standard battery charged.  Standard lead-acid batteries are heavy too.  If you are used to seeing a car battery, motorcycle batteries do look miniature by comparison, but my new tray did not allow room for the standard RGV battery.

The VJ21 and VJ22 model RGVs were fitted with a kick-start system.  Given that there is no electric start on this bike and that is devoid of lights and indicators, the only real function of the battery is to power the CDI and SAPC units and spark plug coils.  Like most engines, an “electrical generator” of sorts uses the spinning of the crankshaft to recharge the battery.

Some racing bikes run a total-loss system.  The charging system causes a drag on the engine.  The more current you try and draw from it, the more the drag and the bigger the performance hit will be on the engine.  A total-loss system will not recharge your battery as the engine runs. By doing so, less load is put on the engine, leaving more power to actually propel the bike.  Unless you are at the elite level of the sport, it is unlikely that having a total-loss electrical system is worth the trouble of recharging the battery after every race.

Given that the generator provides electrical power, the battery becomes superfluous to requirements. The regulator/rectifier and AC generator of the RGV is sufficient to power the electrics of the bike while it is running, and your leg (and kick-start) is enough to provide the initial power to start the bike.  A “battery eliminator” can be built and substituted for the regular battery, saving weight, space and the “oh-no” moment, caused by a battery that has gone flat through lack of use.
Although commercially available “battery eliminators” can be purchased, “Mick” on the currently out of action Yamaha-rd forum  wrote a succinct post on how to build one:

You need;
3 x 4700µF 25V electrolytic capacitors
1 x 500ohm resistor
some solder
a soldering iron
source of power for the soldering iron
cup of tea
decent music

OK, solder all of the components together in parallel; that is +ve terminal to +ve terminal. This is important. The resistor can go in any way round, but they must all be connected in parallel with each other.

Remove the battery from your bike.
Connect the eliminator up the right way round (+ve end to +ve connection on the loom)
Switch the bike on (note: the PVs won’t move until the engine’s running)
Start ‘er up.
Ride the bike, and enjoy the feeling of having lost 2.5kg of ugly fat.

Mick.

How hard could it be?  There was a discrepancy between the commercially available, and Mick’s battery eliminator.  Mick suggested a total of 14100 micro-farads, whilst the Zeeltronic schematic had 30000 micro-farads. (and a different amount of resistance).  From my limited understanding, the capacitance allows a good way to smooth out the voltage provided across the unit, whilst the resistance provides the regulator/rectifier with a workload.  Without this load, the regulator/rectifier would overheat.  (Feel free to correct me here)

Battery Eliminator PartsI bought the components from Futurlec.  Shortly after I ordered the parts, I read the horror stories from “customer review” websites.  Put simply, they grossly understate shipping times and I am not convinced they ship your order when they claim to.  They also allow normal mail shipping of their products and hence they cannot be tracked on-line.  This further reduced the transparency of their operation.  The parts did arrive after four weeks.  Their website made me believe it should have only taken two…  In days before Internet shopping and on-line tracking of parcels, I would not have thought twice about the length of time it took for my order to arrive.  These days though, it is a different story.

Once I knew how large the capacitors were, I purchased some cabling and a zippy box of sufficient size from the local Dick Smith Electronics shop.  Then all I was missing was the cup of tea and some decent music!

Battery Eliminator Circuit BoardRather than use a breadboard, I drilled holes in a piece of Perspex to hold the wiring in place and rubber mounted the board inside the zippy-box in an attempt to shield the components from solder loosening vibrations.  Once I had finished construction and fitted it to the bike, I tried to start the bike… At 30,000 micro-farads, I could not generate a spark.  In the end, I removed one of the capacitors (reducing the overall capacitance to 20,000 µF) and had instant success!  (Yay!)

Given that my de-soldering technique is even rougher than my soldering technique, I didn’t bother providing photographs of the final product.
For those of you tempted to try building your own battery eliminator, I have ended up with the following configuration:

  • 2 x 10,000 µF 25V electrolytic capacitors
  • 1 x 1000ohm resistor (5W)

So now you have three different sets of figures to guess at!  Good luck!

Battery Eliminator wired up.Battery Eliminator in boxBattery Eliminator vs. Battery
(Edit: Pictures added)