Premature end of file
Consuming a heavy resource on an external web server, we used an xml pull parser to integrate this data in our system.
After some time spent reading this resource, the program stopped with a java.io.IOException: Premature EOF. I presumed
this was because the remote server does not supports chunked http requests which the implementation of the parser use…
But I was not able to reproduced with a proper integration test. So, in order to get a solution “faster”, I unilaterally
decided to complexify my production code with a previous step to copy of the resource to a local file (with
java.io.File.createTempFile) with the help of Guava and then consume this local resource. The problem is not
reproduced.
A kind of “not achieved” feeling stayed with me after this poorly resolution of a problem… The problem is that I do not really figure out why this exception happened. If the problem shows up again, I will be stuck.
One card per day
Jean-Laurent distributed some cards card in the team to spread values and practices. Today, I suggest my colleagues to pick a card randomly and use it appropriately within the day work. The picked cards:
- Comment with care: used once in a discussion to comment with care someone else's proposition. That was a clever and funny outside-of-code use of the card.
- Dare to say no: used to say no to A LOT of unrelated work discussions within the day. Fun. The card has also been transfered to someone who clearly wanted to say no at one point and did not find the appropriate consensual words to say. The card kindly helped him.
- Your solution should not be more complicated than the problem (the card that I pick): invoked a lot today since we tried to design a solution to achieve a kind of genericity/anticipation of a feature.
Never forget your agile basics
Do not anticipate the next hypothetical feature. This is pure waste. We are using agile techniques such as TDD and continuous re-factoring in order to make our product the least resistant to changes, whatever the nature of the change that could possibly land on the backlog. So, we should spend more time implementing the simplest solution to the current problem than consuming precious time to discuss hypothetical features.
There are still different degrees of commitment to this principle toward the team members. Is this a problem ? Our project (short) history proved quite well that the respect of this agile rule brings small but constant successes.
Oral vs written discussion
We had a lot of informal discussions today. Oral is always fuzzy and shows poorly structured thoughts but very creative and inspirational. When someone has written some ideas on the board, we suddenly had a pragmatic basis to discuss upon. That brings the debate further.
This remind me of the “set-based” problem resolution method versus the “point-based”. Point-based is such like a conversation where the solution emerges after a laborious peoples expressions of ideas. Whereas set-based is more like: “express the constraints clearly and we will find later the obvious solution that satisfies it”. In oral form, I am obsessed on not loosing this factual state of mind when I listen to other people but when its my turn to speak, I always reproduce the same infinite loop of my thoughts…