Comparing Dictionaries

[Martin P. Hellwig]

Kenneth Love wrote:
<cut>
> That should teach me not to change working code at the same time I am
> writing unit tests.  Even so, I realize it won't be the last time I
> do something so silly.  Yes, I know about TDD's "write the test first",
> but I'm not comfortable with the philosophy of these new fangled unit
> tests yet.
> 
<cut>
I've been using python for about 3 years now, it was the first 
programming language I learned and I haven't done any other since (well 
that is if you dismiss sql and shell scripting on various platforms).

Though in my daily job I have some coding tasks, I do not see my self as 
a programmer since in my perspective a programmer is someone who can 
write good code regardless of the language. My code isn't any good, it 
is barely functional (so I really needed unit-test way of coding, for my 
own protection and not even because it gives more maintenance security 
for the project).

But the funny thing that I have seen in the development scene is that 
writing tests first and code later is a lot easier when you have a 
technical specification to base it on. A technical specification is of 
course based on a functional design. A functional design is written on 
the base of the assignment and the scope definition.

The scope and design can change in the course of the project but good 
practice is usually to do changes in another release. And that is what 
software change management and release management is for.

Still there are tons of reasons why you shouldn't follow blindly the 
best practice, since best practice is founded on theory molded around 
the most occurring reality. And the only thing that I am absolutely sure 
of is that reality differs enough from person to person and situation to 
situation, that forcing the same practice to every person/situation is a 
guarantee for wasting time and energy.

IMHO there are two extreme basic types of programmers, on the left are 
the ones that have a problem them self, solve it while happily hacking 
along the way, leaving the design part for a later stage, on the right 
are people that know beforehand on an almost bit level what a program is 
supposed to do, already have a design and aren't really that interested 
in the problem that their code should solve in the first place.

Me I am a bit schizophrenic, I move in between of them, on a hourly 
base. So for me the reality is that I have a certain 'problem' I write 
some code with the built-in IDLE mostly following functional coding 
practice (since I still have to figure out how some stuff works in 
python).

Then when I have a an idea what I am doing, I create a new project tree 
in subversion and write my technical specification (still having IDLE 
open to test some of the wild ideas that pop-up along the way).

After that I open Eclipse/PyDEV and start working on the unit-test and 
follow from there, when the code is finished I check it in and branch it 
as 0.0.1. Sleep over it and probably refactor it later on because I 
didn't like some variables names and want to add some comments in the 
code or move out some code to other classes, etc. etc.

The only problem is that I wish I was a bit more stable, because several 
times it has happend that I thought that the problem is a one-liner, so 
skipped the whole part after the figure-out-the-problem-code and used 
that what I have already written. Sometimes that works out well, but if 
it doesn't it always bites me hard.

But all these are just experiences from my side, I have no idea whether 
I am right or not, but for me it seems to work, so don't take it as 
advice (I am not really the person to take advice from) but as a little 
'story' along the way :-)

-- 
mph