Google Chrome Auto Updates

Google Chrome is awesome, but in a seemingly controversial decision Google has chosen to auto update without the user's consent. There isn't even an option to turn updating off.

Rob Mensching has more on this and a very interesting selection of comments to his post.

I think Google has made a good decision in doing this, but as a power user I would like to know when this happens and what has changed when it does. The only reason why I am ok with this is because Google Chrome is a self contained platform and not a symbiotic piece of software like iTunes. Plus I recognise the security benefits and the benefits for Google in only having to support a single current version

Two Software Development Methodologies That Everybody Can Use

There are many different kinds of development methods from waterfall to circular, but in the past few months I have found-out about two which I wasn't taught at school, yet everybody can use. From large development teams to lone developers working on personal projects, both of these methodologies work and are very effective.

• Test Driven Development
  The core of this methodology is to create an automated test method that will actually give you a green light telling you wither your application works or not. This is very useful when you are writing an application that needs to conform to an input specification or automates a task that is difficult to check by human means. Large teams can use software on their build server to run use-cases against their codebase that provides feedback, but lone developers can use test driven development just as effectively.
  
  As an easy exsample, when I wrote my table compression algorithms for my Compilers Class I needed to know wither the data stored in the compressed table matched what was inputed from the source table. Obviously if the data retreived from my compressed table did not match the source table then there was something wrong with my algorithems. I tried checking by using my own eyes, but I was dealing with tables 1024x1024 in size so I soon rearlised that I needed to automate the task.
  
  I created a button on my form called 'Test'. This button called a method which in turn methodecally called every cell in both the compressed and uncompressed tables and looked to see wither what was returned from both matched. Obviously there was nothing wrong with the sorce table so any mismatches where the result of a bug in one of my algorithems. Thought creating this I was forced to spend an extra two weeks trying to get all the bugs out, but that is because I could find bugs quickly simply by the press of a button (I also had t create a lot of different test data, but that is a another talk).
  
  When I wrote my last Tic Tac Toe game I also added a test button which took the place of a player and played random moves against my AI for 100,000 games a time. Because of this I know that my AI is unbeatable.
  
  The trick is to have your test method provide useful feedback. In the case of my Tic Tac Toe game when the test method which is making random moves wins against my AI, the test method will append every move made in that game to a text file so I can easily replicate the game and see where the AI made a mistake.
  
  
• Burn Down Graphs
  In order to create a burn down graph you must first create a list of features that you want to include in yourr application. This should include all necessary and desirable features. Then each feature should be broken down into tasks and a time alloted to each task. This will give you a list of features, how long it will take to implement each one and indeed the entire application.
  
  With a burn down graph you don't need to choose how long you want to work on your application each day like with a gant cheart, but it is important to update the graph regularly otherwise it won't track progress. Update the graph daily, weekly or however often you feel is appropriate. This will form the time scale that runs along the bottom of the graph.
  
  
  
  So along the bottom of the Burn Down Graph you have a time sale running from when the project was started to your desired deadline. And up the left side you have hours until completion. As features are completed, added or removed the graph will reflect how many hours you have left to work on your application against your progression to your deadline. And over time you will see a nice line appear that will give a very good indication as to wither you need to put more hours in to complete the project on time, move the deadline or cut features to meet the deadline.
  
  In the picture above you see a nice smooth line, but real burn down graphs aren't like that. There will probably be a few occasions when the time needed to complete the project will increase as difficulties are encountered, that is ok because the graph will always communicates clearly where you are, where your deadline is and by looking at the line you can clearly judge wither you will meet your deadline or not by the work you have been doing.

So there you have it, two methodologies that even a lone developer making an application for themselves can find useful.

To Delay or Not To Delay Windows Vista

Robert McLaws over at LonghornBlogs.com has an interesting post titled Vista Needs More Time: The Entry I Didn't Want To Write. Which talks about how Vista needs to be delayed just a few more weeks to make it right for launch.

This is an interesting problem in most kinds of development because the product is already delayed, but there is call for a further delay. The problem with a decision to delay it further is that some projects never get launched because there is always something that could be done better with a bit more development time. One of the first things anybody should realise is that the most important feature of any commercial project, is that it must ship. So the choice to delay by even just a few weeks will be a difficult one to make. As in Vista's case there are probably other companies that are going to suffer further because further delays. It is not uncommon for some to go under because of such things.

Microsoft has a reputation of releasing new versions of it's OS unfinished. This always plagues early adopters and the reputation of the OS throughout it's life. I am not sure wither first impressions are the most lasting impressions, but certainly a good out-of-the-box experience helps all products. So in my view Vista is already late so they might as well make it worth waiting for. It's like being late to an important interview. You can either be five minuets late and be unprepared, or be twenty minuets late and have all your shit together. You are already noted as being late so wither that is ten minuets or half an hour might not make that much of a difference.