Tools

Most of the projects that I take on as a hobby normally involve the use of Vim on Linux, I don't have the money to invest in the latest IDE for my programming although when there is one and it provides me some benefit I am not adverse to using it will normally use it. I have used:

Borland C++ Builder

I really like this IDE and I found it fairly easy to use. I am looking for one to use on Linux although KDevelop seems to fit most of my needs at the moment.

NetBeans

I have used this and only touched on a little of its functionality. I found it fairly hard to get on with at first but I imagine this is just because I had not been using an IDE for a while. It had more functionality that I have ever come close to needing and I would like to use it again. It is currently what I am using for the HR-XML project.

KDevelop

I first used this about two years ago and I hated it then but I was forced into using it as its the only c++ IDE I had on my box at the time. I can now say that I really like it and have found it much easier to use than it was previously. It feels a lot slicker than before. It is currently what I am using for the search engine part of the project.

For any of the above IDE's I would be grateful if someone was to forward me a way to use Vim as the default text editor without switching to another window. This would be an absolute god-send.

Bash ie. the Shell

This is my favourite programming environement to date. It has all the tools one could possibly ask for. I use Vim as the text editor simply because I am used to it and have not found anything better, yet. I will try Emacs at some point in the future, promise.

Methodology

I have employed various methodologies to go about my daily programming and have noticed several traits that I have in each of them. This page is really meant to be an explanation to why I seem to do things the way I do. I am not saying that I always do things this way. I am as happy to use whatever method a company wants me to employ but, when left to my own devices on my Hobby Projects certain traits always seem to rise to the top. Please note that the projects I do at home are mainly as a hobby and I do not try and write production code every time I open Vim. Most of the things I do are not new either, for instance, iterative programming has been going on long before my time.

Getting Results

I am a believer in Pareto's Principle, more commonly known as the 80:20 rule, that most of the results come from the minority of effort. This may be because I am an ENTP, according to Myers Briggs, but I do not think so. When I start something I like to see results ASAP, this is something I have noticed in everything I do, not just programming. Considering the typical projects that I choose it may be why I use Perl rather than C++ or Java. Some examples of the 80:20 rule.

How I start a project

Most of the projects that I start I have been mulling over in my head for quite some time. I do not normally try to impliment flash in the pan ideas, I like to think them through, I also do a lot of reading during this stage because I normally pick projects that will tax me a lot. It's also a great way to find documentation that I can use as project documentation, or reference material. This is probably where I go through the requirements analysis stage of your typical Software Development Life Cycle (SDLC). The difference is that I do not document the majority of my hobby projects, I tend to adopt other peoples documentation and hack it to my needs.

Specification and Design

After sufficient mulling I then begin the specification stage. I basically write down a few things that I would like to achieve as soon as possible. These could be considered my test criteria for a successful project. It is also a method employed when using the Extreme Programming methodology ie to write the tests first and get a simple specification running as soon as possible. I do not write the tests first I just document what I consider an acceptable program and what I am testing it against. This is normally as far as I get before starting to write some code. Unfortunately "Pair Programming" is not something I have ever had the luxuary to try.

Iterative Programming

I am an iterative programmer. What I mean is, I employ the methods above when programming during each key stage of a project. This sounds horrendous but I have found it to be the most productive way for several reasons. There is only so much you can contain in a specification and design document, don't get me wrong, these are very important stages but I have on numerous occasions started one project and found that it changes into a much more elaborate one, Scope Creep, ring any bells.

Scope Creep occours for several reasons. The most interesting reason and probably the most important is due to Application Evolution during design. What I mean by this is that during the project people can see it evolve and become aware of its potential. They then start to see better uses or more interesting things that the application can be used for. This is perfectly normal and should be encouraged, this is an area where you may uncover a strategic gem you where not expecting and when found they should really be investigated. Eventually the application is no longer, just solving a problem. It is evolving and this should be taken advantage of, to this end I like to review what I do at each stage of a project. This means that I get to take a functional look at what I have acheived and from this point it is much easier to see what else I could acheive with the least effort. This is the point where I often spot much more interesting tasks or functional uses for my projects. It also needs careful management or it could cause no end of problems later on when deadlines are looming and the CFO is asking pertinent questions. Luckily for me my hobby projects start with zero budjet and remain so, all I have to do is watch my deadlines.

Perfectionism

After spending days coding I always look back and wonder if there would have been a better way to do it than the way that I have done it. Invariably, I see another method or technique I would like to try to make the program simpler or more efficent. This is a common trait and is similar to "Analysis Paralysis", as long as you are aware of it it is not normally a problem. I try and avoid rewritting code if it passes all the tests and suits the spec to which it was written. There are times when rewrting bits is just common sense but I am not a believer in getting bogged down trying to take a working program and making it better. Experience has shown me that it normally just introduces more bugs and headaches than it is worth. Sometime it is unavoidable but on the whole I avoid it where I can.

Not Finished Yet

I will get around to doing the rest of this eventually.