Bad experience: Reasons why the last project was a disaster.

Usually I try my best to work in an ordered manner.
This means:

1. Interview the project manager (the person responsible for the success of the project) for the story.
2. Convert this story to requirements.
3. Present the project manager with the requirements.
4. If approved go to the next level.
5. Do a High Level Design (HLD) 
6. Present this HLD sidelong the requirements and estimate roughly the solution time in human days labor.
7. If approved go to the next level.
8. Breakdown the HLD to low level design (LLD).
9. Estimate LLD and present estimated more accurately time  in human labor.
10. If approved go to the next level.
11. Implement the LLD and stick to it (no time for adventures).
12. Do unit test, system test as much as i can (depends, sometimes not possible).
13. Present a working machine.
14. Be happy and relax.

This time, everything went wrong! Why?

Here were the flow of things:

1. Pressure to implement as fast as possible (reasons: no time, no budget).
1. I broke and agreed to 'be fast'.
2. Skip HLD + LLD, start implement! ==> no thoughts of risks, everything looks easy when you don't think about it deeply.
3. Implementation got some problems I didn't see in advance (and frankly, none can think that deeply).
4. More and more problems arose ==> delivery time breaks ==> more pressure.
5. No one is happy, all is waiting for the delivery => more pressure ==> shorter code, less secure code, BAD CODE!
6. ... The test-bench is too complex to operate... Catastrophic :-)

Next time - Do it right! 

If the project manager don't want to do it right, ignore him :), take your time, design it, show him the design, say 'i thought about it and found some problems' (when doing the hiding HLD + LLD).

You only get an advantage in the start, when things get rough (and they do!) you will cross the break-point and start to be slow (because you can't load all the HLD into your head).

In the end the project worked, the code, barely, but did managed to work, the time for this project took much longer then 'fast and short' (twice if not more the time it should take), and a bad taste was in the mouths.

GUIDE: TDD unit testing tools for Tcl

As promised in http://shloemi.blogspot.com/2011/03/tdd-tools-for-tcl.html here is my experience with tcltest package and eclipse.


The story
Suppose we have a function called 'bits_serialize'.

This function should serialize a given data into bits_per_io bits per package (for examples see the tests below and what they return).

This function have the following signature:  bits_serialize {bits_per_io description}, where:

• bits_per_io
• How much bits each package have.
• description
• a pair of {data bits}, where:
• data 
• the data we want to serialize.
• bits
• the size, in bits, we want to serialize this data.

let's test this function using tcltest...

Test code

# Generated using http://pygments.org/

source unit-under-test.tcl ;# contains the definition of bits_serealize 

test base--always-ok {This is as simple as it gets.} -constraints {
} -setup {
} -body {
 return TRUE
} -cleanup {
} -result TRUE

test bits_serealize--partial-quanta {description here...} -constraints {
} -setup {
} -body {
 return [bits_serealize 32 " 0x01 16 "]
} -cleanup {
} -result [list 1]

test bits_serealize--full-quanta {description here...} -constraints {
} -setup {
} -body {
 return [bits_serealize 32 " 0xFFFFFFFF 32 "]
} -cleanup {
} -result [list [ format "%u" 0xFFFFFFFF ]]

test bits_serealize--over-quanta {description here...} -constraints {
} -setup {
} -body {
 return [bits_serealize 32 " 0x060504030201 64 "]
} -cleanup {
} -result [list [ format "%u" 0x04030201 ] [ format "%u" 0x0605 ]]

test bits_serealize--way-over-quanta {description here...} -constraints {
} -setup {
} -body {
 return [bits_serealize 32 " 0x060504030201 320 "]
} -cleanup {
} -result [list [ format "%u" 0x04030201 ] [ format "%u" 0x0605 ] 0 0 0 0 0 0 0 0]

test bits_serealize--cross-quanta {description here...} -constraints {
} -setup {
} -body {
 return [bits_serealize 32 "
  0xFF 1
  0xFF 2
  0xFF 3
  0xFF 4
  0xFF 6

  0x04030201 32
 "]
} -cleanup {
} -result [list [ format "%u" 0x201FFFF ] [ format "%u" 0x403 ]]

test bits_serealize--quanta-and-half {description here...} -constraints {
} -setup {
} -body {
 return [bits_serealize 32 "
  0xFFEEDDCCBBAA 48
 "]
} -cleanup {
} -result [list [ format "%u" 0xDDCCBBAA ] [ format "%u" 0xFFEE ]]

eclipse-unit-testing

Results

++++ base--always-ok PASSED

++++ bits_serealize--partial-quanta PASSED

++++ bits_serealize--full-quanta PASSED

++++ bits_serealize--over-quanta PASSED

++++ bits_serealize--way-over-quanta PASSED

++++ bits_serealize--cross-quanta PASSED

++++ bits_serealize--quanta-and-half PASSED

My impression 

I definitely recommend using this unit!! and to my surprise eclipse supports it built in (see picture ==>).

TDD unit testing tools for Tcl

After committing my first 'big' feature to my current employee, I got a feeling that something was left behind in the heat of the rush. That think was, of course, the new code test coverage.

That lead me to try and find tools / guidance for Tcl TDD.

Here are the things I've found for Tcl:

1. A very good TDD tutorials found
1. http://www.agiledata.org/essays/tdd.html
2. http://geosoft.no/development/unittesting.html
2. TDD tools for Tcl
1. Wiki comparison of available tools for Tcl -  http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#Tcl
2. tclunit - http://www.tcl.tk/man/tcl8.4/TclCmd/tcltest.htm
1. Download here - http://sourceforge.net/projects/tclunit/

Thats all, not much. I intend to check tclunit, experience with it and report back later on... see Y'a.

UPDATE
As promised - http://shloemi.blogspot.com/2011/04/guide-tdd-unit-testing-tools-for-tcl.html

Iron-Python first impressions

In my previous post 'IMDb search for a given trailer', I've showed some code in Python.

I'd like to say that I'm really impressed by the easy, fast and clear code I can now manufactured with Python.

I see it as a beautiful, humanoid, cross platform, code experimental, scripting language, fast POC tool and a great development phase language.

It should be the holy grail, but....

I've compared the performance between same code in C# and Python, and not to my surprise - it's also slower, much slower, 10x times slower than a static language like C# (which is also slower compared to C++).

So, it's a 'development phase' language, where you want to deliver fast, but if we combine it with C#, like Iron-Python does, write the skeleton in python than in the 'performance phase' we move the slowest parts to C#, we have a winning combination. Almost...

'Maintenance phase'

In this phase we need a programmer familiar with python OR is willing to mess his hands with python, this can be harder to find than the horde of C# programmers.
The advantage, on the other hand, is that the code is: cleaner, more redable, less code lines ==> Easy to maintain!! ==> less time to maintain ==> Faster stable version ==> we can port the stable code to C# and have time for another coffee.

'Bug/Debug phase'

I found it very easy to debug Iron-Python, while playing it with C#-Express. But still when you put your hands in the dirt and start debuging, you can feel it's not that mature for debugging, not yet.
Still, the time i spent on curving my knowladge on python + debugging it was still less than if i had to code it in C# and debugging the same bugs.

Conclusion and personal opinion

My guts telling me - 'It's worth it'.

Go for it, but start with small projects, not important ones, not risky ones.
Try to automate monotonic stuff you do in your daily work ('Manual monitoring network drive to see if a folder changed, if it changed copy it to my personal backup folder, so i can work from home...' stuff like that...)