Delays for Gesture Magic 1.1/Vampire Castle 1.0

Rather annoyingly my main development laptop died on Friday, and I've got a heavy cold so no work is getting done. The laptop is going into HP for repair and I'll document the procedure and how I got an extension to my 1 year warranty when I get the machine back (I don't want to curse it!)

In the meantime I'm setting up my old XP machine to do development work, this is a long haul measure since I'm anticipating HP may take some time to get back to me.

Gesture Magic's Criticism

Whilst software I give away on this site usually has praise (Aerofoil being a good example, LocateMe for its educational value, Optimizer for having been a best seller when it was sold) I've recently come across (my first piece!) some criticism of Gesture Magic. Bear in mind Gesture Magic was stated on here (due to time constraints) to be released with a limited feature set because it was better than sitting on my machine not getting used or not getting improved by third party developers, so I did expect some criticism.

What irks me is that the criticism was not constructive, it was left on a third party site and no feedback left for me here.

Even if the user cannot program, lack of simple etiquette to provide some useful feedback of the software on this site shows the lack of understanding of the open source process and how developers rely on feedback to improve the product. This is the cost of the product. You pay Microsoft with money, for open source for whom people who give their own time writing software for others, it's good practice to provide help or feedback. It's all about community, sharing and importantly goodwill.

To summarise my feedback on this issue, based on the intentional simplistic design of Gesture Magic, once I've finished the Nintendo DS game I'm working on, I intend to
- Improve accessor/modifier keys on Gesture Magic (find some other way to start the gesture drawing)
- Improve application starting (add start in directory option)
- Provide integrated default functions, such as minimise/maximise window, close Window, and search.
- Better help support
- Fix or improve some of the issues raised by users.

At least the user said Gesture Magic makes your desktop look like a video game, which was an intention all along :)

Aerofoil receives more high praise, Vampire Castle on the way

Two news items today - reviewingit.com have done a full page review of my tiny Aerofoil application - more praise! Thanks guys!

I'm also working on my first free Nintendo DS game, the first part in the series goes by the name "Vampire Castle". It's not moving as fast as I'd like because it's the second time I have ever used C++ since leaving university in 2000(!), and the graphics and sound are very time consuming for one person whose main tools are a pencil, scanner and GIMP!

I'm keeping this one under tight wraps for now, but it is progressing (first builds should be out in a couple of months - a realistic timescale) and hopefully it will be an award winner too.

Gesture Magic Source Code Release

Sorry for the delay... I started writing a Nintendo DS game and forgot I was releasing the Gesture Magic C# source!

Gesture Magic 1.0 Source

Gesture Magic 1.0 Installer

And the obligatory "what the hell is it?" video (NOTE BETA VERSION VIDEO):

Pragmatic Software Development for Outsourcers

So your work has been outsourced and you no longer have a job? The new developers spout Bullshit Bingo like they actually know how what they're talking about and "network" with management?
Well don't worry, a colleague of mine recently found a badly translated copy of their Pragmatic Software Development Tips!!!

• DRY - Do Repeat Yourself
  Copy as much code as possible, CTRL-C and CTRL-V are your friend (don't use CTRL-X)


• Never Use Source control
  Why have complex code control systems when comments will suffice?


• Don't test your software, your users will
  As the users will test the software, testing can be cut from the development cycle to save time


• Use Blackboards to coordinate workflow
  Then erase them, the only documentation necessary is the code, if you can't work that out you ain't smart enough.


• Don't care about your craft
  There is more to life than programming.


• Don't be a catalyst for change
  Ensure the code is as complex as possible and therefore cannot be changed (job security)


• Program close to the computer not the problem domain
  Call variables x and y, don't use a meaningful name like "customer"


• Iterate the schedule with the code
  As the code gets worse and worse from one iteration to the next this will require even more iterations (and profit)


• Finish What you Start.
  Badly, so rework will be required.


• Assume It, don't prove it
  We don't have time to prove it, not with all the complex code, just assume it works (it will be tested by the users when live anyway)


• Never design for concurrency
  This is too complex and can be handled by the client once the project is over.


• Use Exceptions
  To swallow the cause of the problem, without the call stack they will never figure out what you did wrong or even if it went wrong


• Don't refactor
  The code is brittle and will almost certainly break, remember we don't have time for unit tests.


• Don't gather requirements, bury them
  Hide business rules deep within the system where no-one will find them (or better in the view layer)


• Some Things Are Better Done than Described
  Don’t fall into the specification spiral, code what you like, no-one will ever know.


• Abstractions live longer than details
  Make sure you get the interface wrong it will be really difficult to change later


• Don't think outside the box
  Think lunch box, it's time for lunch forget the code problems.


• Don't use manual procedures.
  In fact, don't use procedures at all it will only slow you down


• Coding ain't done till all the tests run
  Luckily we don't have any tests, that's the users' job.


• English is just a programming language.
  But if you don't speak it you can leave it out right?


• Estimate to avoid surprises.
  But they will be surprised by our estimates.


• You can't write perfect software.
  So we don't try - this is our excuse for the 10^6 bugs in the system


• Don't fix it, blame somebody else
  This always works, nobody will know you got it wrong.


• Find bugs once
  And then leave them, somebody else can fix it.


• Sign your work
  Leave lots of comments such as // Change 10-10-2007, but don't add anything meaningful so they can figure it out, why make it easy?