home

projects

travel plans

travel blog

blog history

travel pictures

Extreme/Agile Programming


This is not meant to be a definitions page for extreme/agile programming, merely my thoughts on each subject. If you don’t know what the subjects are, there are many official sites that will explain them, my aim is not to cut and paste other’s definitions into this page. Which leads nicely to the first point:


Code re-use

DO NOT CUT AND PASTE. What a waste of time! All you are doing is copying the same errors! Then if you need to change the code (remove bugs) you have to change x many copies of the SAME code! It takes marginally more time to refactor the code. However, if you don’t and the piece of cut ‘n’ paste code is wrong (or needs changing) then you have to change every occurrence! All you’ve done by cut ‘n’ pasting the code is increase the amount of code you’re maintaining. This will cripple your development time in the future!


Unit testing

The best solutions are always the obvious & simple ones. Unit testing, for me, fits into this category. When you develop code you have to test it, which usually means running the program over the new code or walking through the code with the debugger. So, after one or two runs over the code you can think that you now have fully working code. I can almost guarantee that you have not stepped through every ‘if’ statement. Just think about: to go into an ‘if else’ statement you have got to run the program through to that point twice to test each branch of the statement. That almost certainly never happens. But by writing unit tests it can often be quicker than running the whole program plus you then have that test for the future. So, if you change a bit of code that could possibly change the execution of your first method you can run the test and see that everything works.


Code review

This is a good way of making sure that your code is “correct” and the persons code your reviewing is “correct”. By “correct” I mean that the coding standards are obeyed, the code has implemented the design correctly (maybe after coding iterate back to the design to see if it was right), that the relevant tests are implemented, etc. It is also a good way of establishing communications in a project group, so you can get feedback about your work, how else are you going to learn!


Code review

Design patterns
If you don’t have a common language how can we talk about structure? Design patterns are a good way of getting around a lot of common design problems, when you can talk to someone else about a problem it help to be able to describe structure in a standard way.


Refactoring

Constant refactoring is good to keep the code up-to-date and relevant. With a customer that does not change there specification, a prefect design and a perfect implementation, refactoring would probably not be necessary. But for those of us in the real world, the specification is always a bit of a moving target, hence the design has to be ego so does the code. So refactor the code keep it free of clutter and easy to maintain and/or change.


Minimal Coding

Only code what you need to NOT what might be needed in the future. Like I said in the refactoring section, the spec and design will almost certainly change, when it does you or someone on the team will/should refactor the code. But what is the point of refactoring code that is not used, all you are doing is slowing down future development. Keep the code simple and to the point, frills that nobody uses are useless so the code might aswell be commented out!


Code Optimization

Optimize the code for speed or memory usage once the main bulk of work is completed or you risk wasting time optimizing code that is not your main problem only make percentage point improvements and not order of magnitude improvements! Once again with a change spec you will probably improve code that will be refactored destroying your improvements. The other bonus point is for business sell the client version one, then optimise for version two when you can explain to the client of the vast improvements.

Optimize at the end of coding not during when a real bottle neck is identified, don’t optimize code that probably doesn’t need it.


Code Ownership

Everybody owns the code. With everybody owning the code there are no issues with asking for someone to implement functionality and waiting for them to do so. Just do it yourself. The design should be good enough that you can see what, where and how to implement the code, so anybody can implement the code.


Pair programming

I haven’t done this much, but it seems to me that if something is difficult / complex then you haven’t broken down the problem enough in the design or implementation. I find that pair programming is generally used when a unit test is not working and the first person cannot find the answer. In a pair, review the code and pair program the solution.



Last updated 4th March 2009