Technical Debt, the real costs of corner cutting

Found on Martin Fowlers Bliki yesterday:

http://martinfowler.com/bliki/TechnicalDebt.html

Technical Debt, a term invented by Ward Cunningham to describe the effects of having code being badly designed for current circumstances (my paraphrasing) due to a variety of circumstances.

In our case this debt is incurred by not re-working our software for new situations or platforms. The system as a whole isn't bad, but we have a few cranky old parts to our system that need a bit of TLC (Tender Love and Care). Whenever we need to look at those screens, we see how much work it would be to rewrite them the way we all know we want to but every time we have a project effect them we 'um' and 'ah' and finally decide that the project can't afford the rewrite, or schedules don't allow for it or there is no testing resource for the rewrite.

Forever minus a day Copyright, splutter splutter!

I came across a breath of fresh-air today, courtesy of Groklaw latest news picks .

Rufus Pollock has written a paper analyzing the optimal level for copyright in the current technological environment to balance the financial incentives to the author/publisher and the public, Forever Minus a Day? Some Theory and Empirics of Optimal Copyright.

This gives a bit more ammunition to offset the power of the entertainment lobby which constrains culture with their need to control their content mercilessly.

This control of culture and our more broadly our physical lives by corporations is one of the worst evils in the world today, not that I can do anything about it of course ;)

The corporations are somewhat forced into it by the imperative to maximise their profits at the expense of culture, environment, customers, employees, ethics and government. It is a fundamental weakness of the checks and balances in our capitalist/democratic/consumerist society.

More later.

Google Earth Integration Story: The Data

OK, So I had the GIS location of some of my companies properties, I thought it was latitude and longitude, but I was wrong.
I could program in Java and I could extract the data into this KML xml structure, that was to be my first project.
I created the KML OK, but the x and y co-ordinates didn't work.
After a lot of fluffing around the internet I realised that the projection was wrong, I was using NZMG projections, not wgs84 latitude and longitude.
It was a world of hurt to convert it, so I finally imported it into postgis and converted it using the standard postgis functions.
I now know that Oracle has the GIS locator class, which would be an easy way to do this complex function, but this was the first mechanism I found to do it myself.
So, I suceeded in getting all the properties into a postgres database so I could use java to extract the kml; hooray!.
I had placemarks all over my Google Earth, although it was a bit slow with so many in the one file.

Google Earth Integration Story: The Vision

It all started with a decision I made.
I was reading about all these cool technologies and not really understanding them at a level I felt satisfaction about, I was never actually using them to solve real problems.
I needed to get my feet wet in a non-trivial way and actually make something.
Then I saw Google Earth for the first time, I was smitten.
I loved how the earth looked and the awesome level of technical talent put into making it all work smoothly.
So, I decided to try to put some of the data at my disposal into Google Earth. This was in November 2005.

Optimisation, afterthought or not

It is funny how placing your ideas on an open stage makes one re-consider ones position.

I mentioned in this post on How Google Earth Really Works about how optimisation at my workplace is an afterthought.

Ahhhh, no!

I started to realise that optimisation of our applications has such a solid foundation that it 'blends into the woodwork' of my daily existence. It was enlightening looking at another problem domain's optimisations.

We develop business software in Oracle, SQL, PL/SQL, Forms and Java with all sorts of other things like Perl, PHP and Shell scripting, even some old PRO*C code.

So what has blended into the background:

• SQL statements over networks are course grained calls, which work well.
  
• Indexes are always used for primary keys and foreign keys.
  
• Oracle Forms uses those indexes and have reasonable optimisation defaults.
  
• We tend to design using denormalised large tables, normalisation can have a drastic effect on performance, even in todays crazy supercomputers.
  
• Probably a lot more that I can't see for the trees at the moment.
  

p.s. My spellchecker makes me aware that I am not writing US English, I am writing in UK/NZ English. For those who don't know, the words above do not end in 'ize' :).

The Tyranny of Subscription Living

In the beginning we lived from the land, with calluses and broken bodies to prove it.
These days companies are trying to nickel and dime us to death with the rise of the tyrannical Subscription Model. You pay $29/ month for telecom service, you pay $1 per day for your power service, you pay $78 per month for internet service, you pay the same way for Mobile phones and Cable TV and software is also being converted to subscriptions.

This is a terrible thing to do to the poor Citizen Consumers of the world, to tie us to products that we cannot purchase and must keep on paying for till we die, and probably beyond.

Besides the raw cost of living in such a model which is demonstrably more expensive than purchase living, there is the brittleness of living with dependencies on all these services. This brittleness is hidden until there is a disaster, but it should be uncovered and removed if possible.

A great example here in New Zealand (and elsewhere) is the preferred way to create a Photo Voltaic/Solar powered house. The preferred method is to hook the house to the grid and use the grid as a big battery. Thus perpetuating the dependency cycle. For an extra investment the home owner could use batteries to entirely disconnect themselves from the grid, and eliminate the per deim cost of the grid.

Similarly the Energy efficient Hybrid cars also tie the consumer to buying petrol, without the inbuilt ability to re-charge overnight. This is a little larger issue as it is a cross industry effort to retain consumers sucking at the petrol teat. If an equivalent teat could be constructed the corporations would jump on it.

One of the underlying issues seems to be the lack of a democratic force in the absence of a corporation to buy the politicians favour. Just in the case of Open Source software, there are very few people willing to go in to bat in the political arena for the right solutions if it doesn’t have a money spigot attached. I see the problem is world-wide and it is a fundamental weakness in the political system of democratic countries.

The Matrix says it best: You are just a battery for the soulless machines.

How Google Earth Really Works

One of the key original developers of Google Earth (nee Keyhole) explains how Google Earth works.

A fascinating romp through the ins and outs of one of my favorite toys.

How Google Earth [Really] Works, on realityprime.com

It is funny how as a developer I sometimes consider optimisation as an afterthought and unimportant, but deep thinking about it can develop radically new ways of looking at the world.

I will post in the future about some of my projects integrating dynamic KML into Google Earth, shout out to Andrew Hallam at Digital Earth for giving me a serious leg-up for these projects.