I have always been a bit blasé about thunderstorms. It is not my fault! I grew up in an area prone to them and as such have become desensitised to their awesome fury. I know the dangers are real, I have respect for their power, but at the same time I look forward to the light-show more than fear the possibility of damage and destruction. A resident of Los Angeles probably feels the same way about minor earth tremors – whereas I would be scared witless by them.
A while back I replaced my aging ADSL modem/router in an attempt to fix drop-outs in service that I was experiencing. The replacement did not really fare any better and eventually I traced the fault back to an under-spec line filter. I kept the new modem/router as it had features useful for VOIP, but I was slightly annoyed at myself.
Recently, we experienced a heavy electrical storm. Remember how I said I was blasé about storms? Well, when the lightning is so close that there is no distinguishable gap between lightning and thunder, and you here arcing on the power lines, even I tend to duck and utter expletives in shock! The roly-poly-cat took fright too, and wouldn’t be comforted by someone who was visibly shaken. It has been my experience that electrical equipment doesn’t get damaged in storms as often as you may believe. Most equipment just keeps on keeping on! YMMV!
Of course, this time was different. The new modem/router lost the Internet connection. I could still “see” the device, it could still report line attenuation and signal to noise ratios, but using it to access the Internet was beyond its post lightning strike capabilities. So, it was time to drag out the old modem, which was now reserved for “emergency backup duties”. Sure enough – it worked and so did I. (I had been working from home at the time)
The silver lining to my grey thundercloud turned out to be that the purchase of the newer modem had been necessary after-all. Whilst the new modem had not cured the dropouts until I upgraded the line-filter, the old modem still suffered from them – even with the new line filter. So, I declared that the new modem was a “worthwhile” (if somewhat short-lived) purchase. That night, having soldiered on through numerous drop-outs, I decided to have a closer look at the new modem. It was worth the effort! It turned out that the lightning strike had simply erased the settings of the new modem. Having re-established these, I performed my lucky escape! And everyone lived happily ever after!
Living without surge protectors in an area prone to thunderstoms may seem risky or careless to some people. I do not know much about high-voltage, but do know that the close proximity of unprotected and protected wires on most “domestic” surge protector boards is likely to be insufficient to prevent arcing between them. Still, when a horse points at an open gate and says “next time I’m bolting” I pay attention. I have since bought myself an eight point surge protector, complete with phone line and coaxial cable shielding. I will let you know, if lightning strikes twice. 
22 February, 2010
Tales of a lucky escape and a worthwhile purchase
15 February, 2010
Engines – Part Two.
Previously I described an engine as having pistons that travel up and down inside a cylinder. The piston is attached to the engine’s crankshaft via a conrod. Each piston in a four stroke engine has four distinct phases through which it travels. For two of these “strokes”, the piston travels downwards. The other two strokes, the piston travels upwards.
 |
The first downward stroke is referred to as the Intake stroke. At the top of the cylinder head, there are valves that open and close at different points in time. The inlet valve (or valves) open during the intake stoke, allowing a fuel and air mixture to enter the cylinder. Because the piston seals the cylinder when it travels downwards, it creates an area of low pressure above it. This helps draw the fuel-air mixture in. |
 |
At around the time the piston reaches bottom dead centre (BDC) the inlet valve closes, sealing the gasses in the cylinder. The piston then starts its second stroke: the compression stroke. The piston travels back up, compressing the fuel-air mixture at the top of the cylinder. The difference in volume between when the piston is at the bottom of its stroke and the top of its stroke, is commonly referred to as the engine’s compression ratio. |
 |
Compressing a flammable gas in the presence of oxygen is somewhat fraught with problems. Compressed gas gets hot. Hot flammable gas can combust! The octane rating of a fuel denotes how stable it is. Engines with high compression ratios need high-octane fuel to prevent uncontrolled detonation during the compression stroke. |
 |
Once the piston reaches top dead centre (TDC) the compressed fuel-air mixture is ignited by the spark plug. This causes the gas to ignite and expand rapidly. |
 |
The valves in the cylinder head remain closed at this stage, so the only way the gas can expand is by forcing the piston back down the cylinder. This is referred to as the Power stroke. |
 |
All things going well, by the time the cylinder reaches BDC again, all the gasses have been burnt. |
 |
No further kinetic energy is to be gained from them and they need to be removed from the cylinder, ready for the next cycle. The outlet valve (or valves) open and the now rising piston forces the exhaust gasses out through them. This is known as the exhaust stroke. At the completion of the exhaust stroke, the exhaust valve has closed and we are ready to repeat the entire process. |
Two stroke engines work in a similar manner, but combine the intake /power strokes together and the compression / exhaust strokes. How this is done, is a story for another time.
3 February, 2010
Does Technical Debt Matter?
I have some strong views on code quality. One of my professional goals is to always attempt to improve my coding with the aim of producing better code. In this day and age, making software “less broken” is about the most I can hope for. I cannot foresee a time when written software becomes “perfect” / “bug free”. Maybe it will – I have learnt: never say never…
Anyway, this is an article akin to playing devil’s advocate. I am not particularly comfortable with what I suggest below. I have written it purely to get people thinking about the time and effort expended writing software. As always, I encourage your comments – positive or negative.
One of the odd things about the software industry, is that code “rots”. This is somewhat strange. Source code, written in text files does not “degrade”. Unlike organic reproduction, copying a file leads to a perfect reproduction. If you kept a copy of code written say twenty years ago, it would still be the same today as it was then. Things change rapidly in the computing industry. As a result, it is extremely unlikely that you could use that twenty-year old code on a modern computer. A different form of “rotting code” exists precisely because the code does change. Over time, countless little hacks or quirks can be added to an active code base that leads to obfuscation and “unhealthy” code.
The common technique to reducing code-rot is refactoring. By having comprehensive unit tests, refactoring exercises help keep a code base current and ensure that changes made do not lead to regression bugs. Working on a well-maintained code-base is a more pleasant experience for a developer. Well-maintained code is easier to extend and developers have less fear of making mistakes.
“Technical debt” is a term coined by Ward Cunningham and refers to the “price paid” for releasing code for the first time. He argued that a small debt was useful to incur, as it helped speed up the development process. It was okay to incur some debt as long as it was “paid back quickly” by refactoring the code.
“The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation…”
Productivity graphs show how progress drops away on poorly maintained projects. The longer the project runs, the harder it becomes to add features or fix bugs without causing other regressions. The solution to the problem is to avoid as much technical debt as possible. Following best practices will help achieve this goal. But is this done at too high a cost? Following best practices adds extra work and thus does slow down development early in the life-cycle of the project.
Not repaying technical debt will grind a software project to a halt. If you use an analogy of credtit card debt equating to technical debt, having the software project grind to a halt is the equivalent of declaring bankruptcy. Obviously, this is not a great outcome, but it is not the end of the world either.
What if your software has run the term of its natural life? Your software will have been written to meet a specific need. Maybe that need is no longer there. Maybe that need is now perfectly met, or the market has been saturated and sales have evaporated. Maybe every feature that could be added, has been added (including reading mail). If the project gets “sun-setted” does it really matter how much technical debt is left in the code base?
Not “doing things the best I can” is something I struggle with. “Doing the best I can” and “doing things well” do not necessarily mean the same thing. Obviously, the process of software development happens on a linear scale. Software tends not to be written “the best way” or “the worst way” but rather somewhere in the middle. If the process your team uses is close enough to “the best way” end of the scale to not be crippled by technical debt, then maybe that is good enough.