In this Wiki, you can learn a lot about XP, but if you're a non-professional programmer who just writes small programs all by yourself, you can't do XP at all. I think in XP it is essential that you work with a group of people and every day you do your pair programming with somebody else. This way people do inspire each other all the time. And you correct each other's mistakes all the time. All by yourself, you have to do a different type of programming and you can copy only a few ideas.

Now I write what way I think about Solo programming in VB6
	* Probably, you're the only one who will ever look at the code. Just write the code you understand, your way. Don't care what others think about it. Program the way you like.
	* VisualBasicTeachesGoodHabits. I started with no knowledge at all, and I learnt a lot within VB6. As I run into my own code again later, and with my memory as a huge sieve to help me, I have to learn to write as well and simply as I can, so it does teach me good habits.
	* Write all code in modules (*.bas), in a structured way
	* DoSimpleThings
	* CrapCode that does exactly what it is supposed to do is good code.
	* Do not refactor anything unless you have good tools to help you. Try to write good code right away, don't try to re-edit it later. When you work with a bunch of people, refactoring will be a different process, but all by yourself you have to do all, all and everything, overlooking a lot of tiny mistakes all by yourself, and this can be most tiring.
	* Mark clearly all the stupid bugs you wrote
	* '''Never write a line of code without a backup.'''
	* Keep lots of backups.

----

The way I did program lately really wasn't fun, because I did more experimenting than progress. I felt as if I never knew this little before. This was caused by reading about XP:
Some ideas not good for crap programmers:


1. '''Refactoring:'''
	* Don't start the day refactoring some code, start to write some code instead and as you write good code, you won't have to refactor anything in the first place, and only when you get into the feel you can refactor some pieces of code that you wrote before. This is the way to do it.

DoSimpleThings instead of refactoring. You have crap code, but it works and now you want spent time to refactor, so eventually you end up with code that doesn't work at all. Well, if that's simple then I'm simple too! (At least I don't work either.) First, I need to get a good tool to remove all the superfluous subs and functions and to remove all constants and variables that aren't used. This would clean up my code a lot more.

You may read about OnceAndOnlyOnce, but instead you should make a backup over and over. Don't delete lumps of code with a happy smile, you'll be crying afterwards.

 refactoring
 sub something
 call SecondDoThat
 call FirstDoThis
 end sub

refactoring I will change the order to

 sub something
 call FirstDoThis
 call SecondDoThat
 end sub

and next spent a few hours (or days!) to find the bug and next restore the code again. I don't think this fun.

better code is:

 sub something
 'this order!
 call SecondDoThat
 call FirstDoThis
 end sub

(Note: at times, this code is most sensible; first you write a procedure: enter_the_house; later you write a procedure leave_the_house, and next some code may seem to be in the wrong order, but actually isn't, and no matter what way you rename the code, in some places it will seem to be in the wrong order.)

Changing the name of a sub, variable or constant can be a lot of fun: (change all thisName>>betterName) save all, have no good recent backups and just find out that you already had a sub, or something called betterName.

Some code will be useful only in extraordinary cases, this code may look most ugly and superfluous, because I felt fed up when I wrote the code, or I thought that exceptional case very clear at the moment when I wrote the code. When I refactor, I may think this code really bad code and not remember this extraordinary case clearly. Later, when I run the program again and again it seems all right, so I think the refactoring was all right, but some days or weeks later I run into the extraordinary case. You may think I should have written good tests, but I didn't in the first place, so I shouldn't refactor. Lessons to learn: Keep lots of backups, with a clear note about the state of the program when you made the backup.

2. '''Classes'''

Reading about UnitTest''''''ing and all these discussions on inheritance in VB6 made me think it would be wise to write my code much more ObjectOriented: Lesson learnt: don't!, unless you know all the ins and outs of classes. The debugging proved to be hell. The program didn't stop at the error but at the sub that makes a call to the class. All subs and functions within a class should be very simple. Of course, if you are used to OOP it's all right, but VB6 is a good procedural language so you should do procedural programming.

''You change change this behavior using the "Error Trapping" setting in Tool|Options|General...''

It's not hard to write a simple Class, but a more complex Class, with lots of private subs and functions and crammed with errors is hard to debug. The program doesn't stop at the error but at the sub that makes a call to the class. All subs and functions within a class should be very simple. I think the best way to create a complex Class by first writing a *.bas module. After, when this module proves to be all right you can turn it into a Class. You should also understand the Set statement before you ever create a class

3. '''Testing'''

I didn't do that much testing until now. I don't see clearly what way to write any tests that will really be useful. See also: RefactoringUnitTestsIsExpensive, and you can find a lot of other discussions also. ''(Somewhere I also read that the UnitTest''''''s are mainly a design thing; first you write a test, to get a clear picture what class you should write.)''

In this WikiWiki, they speak about AcceptanceTest''''''s and UnitTest''''''s, but I somehow only need crap programming tests, CrapTests. A simple development tester, to see if the program does what it is supposed to do.

4. '''Errors and bugs'''

They say "One thing at a time - when you run into a bug, you first fix that bug then you move on." If you work with other people, they will see what you overlook, but all by yourself this is not the way to do it.

At times, I can't find the bug at all, and looking for the bug makes me create even more. This can be most frustrating and makes me feel as if I'm hitting my head against a wall. Looking for an error and just creating more makes me feel as if I understand nothing and makes me feel empty...

'''So I think it better not to fix errors one at a time, but just fix the errors that are easy to fix.''' (DoSimpleThings, remember:) Along the way, you might fix the other errors too, without much problem, success makes you feel good and makes you understand the program. Much later, you may learn what way to fix those errors, and if you can't fix them, at all, you may even remove some functionality from the program.

I figure it's also a very good idea to start the day with some easy coding. Do something that you can do, next you will feel fine. In the end, when you are in a good mood, you may even fix some huge errors, or you may feel like changing a huge lump of code. First a little backup and you can play a final match with the computer. This is the way to do it.

When you think "I don't feel like doing this or that", don't. Just program to amuse yourself, you're not paid for it, those testers only test because they are paid for it, not because they like it; they all dream about wasting time and a bicycle, instead of respect and a car. -- GerardBuisman