The power of Death

http://bananasfk.wordpress.com/2009/04/07/hp-lovecraft/

A capsule note on H.P. Lovecraft, noted weird fiction writer and father of modern horror, which is more of a link between Lovecraft and Stross than any real comment on Lovecraft himself. 

Other than a forgettable note on the author, this post is notable for one reason anyway: The line “As Lovecraft is dead, his ‘horror’ is rather over wordy…”

I can only imagine what will happen to my own works, already quite wordy, after my death!  What a fascinating idea, words mingling free of their creator’s gaze, free to multiply and procreate and turning regular works into wordy ones!

The mind boggles.

Technical Debt, or: Doing the Work Properly

I read an interesting article recently about the idea of “Technical Debt”,

Technical Debt – 10x Software Development

This article raises several issues for me.  Firstly it is a sane and readable analysis of a problem that everyone working in the Software Development Industry has faced at some stage or another.  The idea that we should track our shortcuts, hacks and the “hey, I just noticed we screwed this up, but there’s no time to fix it” moments with an aim to paying them back is laudable.

Personally, I’ve always had a problem with this part of our industry.  No builder of houses would ever say “well, we promised it’d be ready tomorrow, they’ll pull the job if it’s not, so I’ll just wrap it up with duct tape and they’ll never know the difference in the inspection and fix it properly later.”

Actually I can’t actually -know- that this has never been done, it probably has, but I know if word got around that builder would be out of work before he could blink.  This, however, is exactly what we do when we get into the “There’s no time, I’ll just hack it up so it works for the demo” frame of mind, and it is not only accepted but seems to have become “Standard Working Practice” for the industry as a whole.

I’ve always felt this to be a betrayal of my integrity and have felt it keenly every time I have been forced to do so.  Even moreso by the fact, as everyone knows, that the later fixes Never Happen.

That, in my mind, is the big problem with this article.  An awful lot of software developers are working to fixed price contracts, and when the release is delivered with hacky code that is dangerous but satisfies the customer, there is very little incentive to go back and fix it.  It’s easy to say that “when things slow down we’ll fix it”, but in the current economic downturn many large software shops have to account for all of their developers time and work.  Try explaining to an account that “Yes, it worked, but it wasn’t good enough.”  For that matter, try explaining this to a client who wants to know why you want an extra couple of days to work on functionality that, as far as they can tell on the surface, already works fine.

That is the big problem we have as software developers.  Whilst people can immediately understand why a building held up with chicken-wire is a bad idea, it’s not so obvious why an application held together with hacky glue code is a bad idea. 

It’s also important to note that if you’re unwilling to go to the client and say “We need a few more days/weeks to work on this functionality”, then you’re probably not telling them that the code they’re looking at is hacky either.  Odds are good you’re hoping they wont notice and planning to fix it quietly in the background before too many more releases go by.  This means that at the end of the release cycle when the project is nearly done and you’ve still not found the time to fix these problems, you’re not going to be able to explain to the client why you need “just a few days or weeks more”.   You can’t tell them that you’ve been dishonest, and the functionality they think works fine is only a few coincidences short of crashing and burning horribly.

So you’ll deliver the final version with the hacky code still in it, you’ll console yourself that maybe you’ll have a chance to fix it during the support period though you know it’ll never happen so long as the hacks hold together.  In the end the company just holds it’s breath and hopes nothing goes wrong before the warranty period expires.

The techniques in this article might help a bit, by encouraging teams to pay back the instances where such hack work in unavoidable.  It also sounds as if it would work far better in cases where an application is being developed in-house, rather than to-contract.  I think the industry as a whole though needs to focus more on scaling back just how often these “Technical Debts” are incurred, and understand that the majority of them never get paid back, and the eventual cost may well be to your reputation.

The problem of “Salary + bonuses”

http://www.thewaythefutureblogs.com/2009/04/the-bonus-babies/

Frederick Pohl on the credit crunch.  This is the simplest explanation of why the banks made sub-prime mortgages that I’ve yet seen, finally the reason we’re in this mess makes some kind of sense.  The fact that people -fell- for this line just goes to show that the world is full of stupid people.  Or at least, somewhat naive and gullible people.

It did remind me of a story I heard at uni that seems to be an apt comparison here.  One of my lecturers was interested in graphics, machine learning and evolutionary computation, similar research interests as I have as a matter of fact. 

One day he set up a virtual robot environment with a straight line joining two points.  The robots, he decided, had to start at the first point and learn to travel along the line to the second.  In order to do this, rather than attempting to code some sort of routine to control it, he decided to run evolutionary algorithms to evolve robots who could perform this task.

Just to make it more interesting, he decided that physical appearance of the robot’s should be evolvable too, to see if the system could come up with a robot that could perform this task the fastest within the programmed environment physics.

The wonderful thing about evolutionary computing is that sometimes (read, often) the systems themselves can surprise you.  It did indeed evolve a robot capable of quickly following the straight line to the second point.  It was a large rectangle as tall as the distance between the two points, which, when the simulation was started, promptly fell over – reaching the second point in the process.

Give people (or evolution) a results-based reward and expect them to cut corners and find a short-cut to get there.  The problem is of course, capitalist propaganda aside, the process is generally as important as the result.