DevOps

Nice post explaining what DevOps is:
http://blog.csanchez.org/2012/03/13/infrastructure-as-code/

Existing principles interestingly explained

Here's an interesting video from Gojko Adzic stating that software quality is everyone's problem. Nothing revolutionairy, but I especially like the way he talks about removing team bottlenecks and the importance of job titles.

http://gojko.net/2012/02/17/sleeping-with-the-enemy-video/

Work to the rule

I want to share a piece of text that fascinates me in the exellent book 'Pragmatic Thinking and Learning - Refactor Your Wetware'. It fascinates me because it is a general piece of text, which imo can be applied to a lot of big Agile teams on projects that take some years to finish.

[Start quote from the book]
In industries or situations where one is not allowed a fullblown strike, a work slowdown is often used as a means of demonstration. Often this is called work to rule or malicious obedience, and the idea is that the employees do exactly what their job description calls for —no more, no less— and follow the rule book to the letter. The result is massive delays and confusion—and an effective labor demonstration. No one with expertise in the real world follows the rules to the letter; doing so is demonstrably inefficient. According to Benner (in From Novice to Expert: Excellence and Power in Clinical Nursing Practice [Ben01]), “Practices can never be completely objectified or formalized because they must ever be worked out anew in particular relationships and in real time.”
[End quote from the book]

Often, when the velocity of big teams is not good, the teams itself propose a number of rules to improve their velocity. Sometimes these rules deal with check-in procedures, refactoring unfamiliar domains should be reviewed by persons familiar with that domain, adhering to certain conventions and so on... That's all needed and all fine. But if the project takes a few years to finish, it can happen that the number of rules can grow a lot, or that the people who invented certain rules, and more importantly, that knew WHY the rule was needed, are gone.

When your project has an entire wiki full of rules, and not all of these rules are clear for the whole team, there is a danger of overregulation. This can lead to 'malicious obedience'.

Testers being the fat kid up front

In the Certified ScrumMaster course, Jeff Sutherland said something that keeps running through my mind. The Agile principle is based on quick feedback cycles and quality of code (xP). A story is not finished until after a 'proxy customer' check. A 'mini acceptance' of the analist representing the customer, if you will. Later on, maybe after the sprint, the story is tested again in some form of integration environment.

To get that feedback in different phases early, he told us to treat the the proxy customers as fat boyscouts. If someone during a boyscout hiking trip can't keep up, it slows down the whole group. You should therefore walk beside them to motivate them. If they still can't follow, you take their backpack. If it's still going too fast, put them in front of the whole group. Make them determine the paste.

I think he's right. We should aid and guide our testers as much as we can. If during the daily scrum stand-up, you hear that someone is blocked from testing, this should deserve your immediate attention.

Proposal based

A month ago I followed the ScrumMaster (CSM) course of Jeff Sutherland and I'm an official ScrumMaster now. It was interesting to hear the guy that invented SCRUM - a former Phantom fighter jet pilot in Vietnam - expressing his vision on the IT industry. A couple of things stood out in the WAY he said them. He likes to formulate things differently. In the Passionate Programmer they talk about the transistion of being technology-centric to being solution-centric. You could tell that Jeff had an infinite respect for the developer (more than for management) but made an interesting statement: 'Developers are always whining and complaining about what's not right. In stead they should offer management clear choices'. For instance in stead of complaining 'we don't get the time to write tests' we as a community should say: 'Either we test and it will save (x-amount of) money in the long run or we don't and it will us cost money'. He's right. I've seen a lot of peers whining :)

Another thing a lot of developers don't do which I always try to, is the way we report issues. Before I communicate a problem to management or the customer, I try to have a list of possible solutions in my mind to propose to them. Not everyone does this, even if the answer to the report of a problem mostly is 'ok, what can we do about it?'.

Dual core processing

I'm reading one of the best books EVER right now (and I do mean EVER), called 'Pragmatic thinking and learning' by Andy Hunt. The reason I like it so much is because it links my interest in IT and in psychology/biology (I did one year of Psychology at the KUL but failed).

Andy talks about the brain as a dual core processor, where CPU1 is the L-mode (lineair or also called left mode, but this is less correct) of the brain and CPU2 is the R-mode (rich mode or right mode). There also is a contention at the message bus level that allows communication between the two, which implies that only 1 mode can dominate your brain at a certain moment in time. In this context he explains why in eXtreme Programming 'pairing' is so important. If you 'drive' you brain uses the L-mode to deal with the words, correct syntax. High level patterns and relations are made by the R-mode however. This is why sometimes your navigator says 'and if you refactor this bit here out, we can re-use it in that other place'. He also explains that this is the reason that when you're not pairing and you face a difficult problem it's important to step away from your desk, giving your R-mode a chance to kick in. I used to experience this in the past when I still smoked. Often the solution to a problem came during my sigarette break!

Fa-sci-na-ting stuff. To be continued no doubt...I'm off buying an Andy poster.

XML escaping

Did you ever want to define a constant in your code containing an XML string? For instance in a unit test to test if you can transform a piece of XML via XSLT into some desired format? You can do this the hard or the easy way: Either you take the chunk of XML, copy it in your IDE or some text editor and replace all double quotes with \" to escape them. Then you can start adding carriage returns in the String to have a somewhat readable piece of text. In case your XML contains all streets in Belgium, you will feel very, very useful doing this.

Or, you can have your IDE doing the work for you. In eclipse simply go to 'Window>Preference>Java>Editor>Typing' and check the “Escape text when pasting into a string literal“ option. As you can see it also adds the newlines and carriage returns:




I remember thinking 'Damn, I wish I knew about this before' when I first discovered this option. That might just be the criterium for any useful IDE feature I guess.