Problems With And Without Honesty

Without honesty there are a tons of problems. It's easy to see why Beck (not again?!) advocates openness and transparency in software development: in short, if we talk about issues honestly we stand a much better cance to resolve them. It's easy to see, but very difficult to realise.
Difficult because of the only problem with honesty: our self-esteem.

More specifically the From and the To part of honesty. The difficulty with the From part is manners and custom. We have a hard time telling our colleague he screwed up badly or has not the first clue what he's talking about, because that's what we are all used to: the not-telling. And because we could be and many times have been at the To-end of honesty and we know first hand how it feels when our mistakes are pointed out. From or To: our self-esteem gets in the way.
In retrospectives mature teams have the strength to be honest about mistakes, as I mentioned before. But it's a lot easier to tell honestly and to be told honestly about problems, when you are team. This is not to underestimate the power of collective responsibility, actually this is to encourage teams to try. You will be susprised how much more honesty you can handle as a team.
However. A team's straightforwardness is not invincible either. At the end of the day the team is made up of individuals, and their willingness and inclanation for honesty ultimately will draw the limits of the team's honesty. Team-members will have to intentionally put aside their self-esteem and pride so that the team can go the distance with honesty, can find real issues, real solutions and once again the team can improve.

Read full post...

Your Choice

Here's the deal. The last post wasn't much of anything. I know. The reason was that there are a couple of things I want to write about, but couldn't decide which one to pick, so I wrote about something I didn't really want to. Anyways, now is your chance to decide what the next post should be about. Vote on the right, comment below, if and when.
Read full post...

"Perfect is a verb, not an adjective" [1]

Learning new stuff is paramount in our line of work. I know, I know Cobol coders might tell you otherwise, and yeah, cobol coders might be home free, but the rest of us mortals need to keep up with the pace technology dictates. Or at least not to fall behind irreversibly much. Because then you might become the subject of Murphy's law, saying "If a hammer is all you have, everything you see will appear to look like a nail". It seems trivial, yet many software companies' don't seem to be sporting any learning or improving. Employers and employees alike seem to be confident in and/or content with their current experience and skills. Obviously it's extra effort short term to spend time and energy to learn new things, but with newer and better tools and techniques you can deliver better sotfware in shorter time. In fact the benefits and the profit are so plain to see, that it doesn't need any further explanation or examples, but then again this post would be ridiculously short.

Once you start looking up new stuff, or rather - because it might be something old - stuff you don't know, it becomes second nature, and you don't even notice all the advantages it gives you, or the way programming becomes easier with recently acquired knowledge. So it's difficult to pick any one example from our past year but I settled for mocking frameworks.
When we got to know TDD we dived into writing lots and lots of incomprehensible unit and functional tests nobody understood or was able to maintain. Then we stumbled upon mocking frameworks, and how we could live without one, beats the hell out of me now. We started to use Rhino Mocks, but soon enough our unit tests once again started to look like a can of worms, so this time intentionally searching for a cure, we found out about the AAA-concept (it's short for arrange/act/assert, but I can't find the exact link anymore; go google it up!). Finally we learned that we can use the lambda-expression to make our code even cleaner and readable. We learned and learned till unit testing and object mocking is less and less of a technical problem, and we can concentrate more on what we are trying to express and accomplish with our tests.
Again this example it's not even about new stuff, it's just stuff we hadn't known before. Keep learning and remember there are other useful tools than just the hammer.

References:
[1] Kent Beck: Extreme Programming Explained 2nd Edition

Read full post...