Marius de Beer is crazy for even trying to do this, but it is such a horribly misunderstood space that it deserves an outrageous attempt to nail it. I’m talking about the really adventurous deep dive session that will be hosted by Marius at the Scrum Gathering in Cape Town. If you currently think that continuous integration is a tool, then my advice is simple. Pay the full fee for the event, sign-up for Marius’ deep dive and sacrifice the second day of the event by going back to your desk and just start doing what you learnt.
Modeling out Loud
July 13th, 2010 Comments Off
I will be running a 6 hour long session at the Scrum Gathering in Cape Town in September titled Modeling Out Loud. I’m now convinced that the Scrum tribe are weird. They call these sessions Deep Dives. Presumably, you need to carry enough oxygen to survive the session.
I think I’m going out on limb here because I will be challenging the value of Product Owners writing stories. I’m also suggesting that when Product Owners write stories riddled with behavior then developers are disconnected from domain experts and you regress into a waterfall mode of execution fronted by a Scrum Board. So be prepared to experiment with me and turn up your self-reflection to maximum level because we will challenge many assumptions.
Architecture in an Agile World
July 13th, 2010 § 1
Next week, I will give a talk at the JCSE Architecture Forum entitled Architecture in an Agile World (or maybe it’s the other way around). It’s not a new topic but since I visited it at a MagmaTec conference late last year, I have updated my thoughts a bit. The angle is also different because I want to explore what it means to be agile in process, and agile in practice and how that relates to understanding a problem and carving out solutions. Often, it is actually a choice to find a solution that is just and that is able to balance the various tensions.
But, I think I am equally excited at the possibility of seeing some familiar faces again in Johannesburg.
Coding for Enlightenment
June 28th, 2010 § 2
Jimmy Nilsson asked me in an email a few days ago “How’s life?”. I’m sure it was just a regular, friendly question, but I gave him a “life” answer. It was not spontaneous but something that has been brooding in me for a while. It is about things that I have been trying to do for a long time.
Here’s a few splintered thoughts from my email exchange.
- Enlightened, for me, is about happiness that comes from being content; unenlightened is just trying to be happy.
- There are many solutions for every problem, whether I am aware of them or not; and the problem has already chosen the best solution, but I have not found it yet.
- Code from my heart because I should trust myself first.
- Be part of the exploration, not just an observer.
- This moment is more important than trying to figure out how it impacts the future, because I can deal with the future in that future moment.
- Passion is constant whether I succeed or fail.
- Let the project plan me, by bending to suit the situation not and not bending the situation to suit me.
- The code I write knows everything, because every line of code has an impact on someone else or some other piece of code.
Now I’ve decided to actively explore why I write code, or why I wish to continue doing what I am doing. I am not sure what I will uncover in this exploration, but I know that it will be very personal. I don’t even know if it will be worth sharing, that’s why I am sharing so early. It just felt right.
I think it will be really tough, but I take solace from my 9 year old son who told his 6 year old sister “Getting hurt is part of playing”.
PS: I don’t think Jimmy will ever ask me a “How’s life?” question again 
Testing is just a laborious pain in the rear
May 10th, 2010 § 3
No collaboration, no heroes!
I thoroughly enjoyed Karen Greave’s talk on Agile Testing. She had just about 100% coverage (pun intended, groan). Yet, testing is really a pain in the rear. Testing is execution, and Karen was dead-on right, that automation is the path to follow. Computers are very good at testing. A computer does what it is programmed to do, and it can test the way it was programmed to test. It’s simple: if testing is your constraint, move that constraint away from testing by automating.
Now, you have to deal with the constraint that shifted to the next point: test authoring. While testing (i.e. execution) is just a passive, laborious effort, test authoring is a very creative, active exercise. It is actually an exercise in confirming a shared, common understanding. Kristin Nygard said “To program is to understand” and test authoring is a programming exercise. That’s why outside-in, behavior driven development style scenarios are actually tests, coded in a human language. The act of authoring a scenario proves your understanding and the expected working of the software.
This is why I separate test execution (passive) from test authoring (active). And Karen said that early feedback is good (right again), which is why I author my tests very early. I’m extreme about this. I test first.
Automation creates time for collaboration
