April 17th, 2009 §
I have received a lot of positive feedback from many new faces for the SPIN talk I did this week. Thank you.
But I am worried. In the 45 minute talk, I did 5 minutes with Ruby code and cucumber. Now so many people want to use cucumber. Good for cucumber.
I think I should have stressed my point a lot more.
Take-Home #1: Find a way to make the life cycle of requirements part of your workflow. Should it be a hard dependency? If the requirements change, then do you want the build to break? When requirements have a life cycle independent of the code’s life cycle, then you are opening yourself to waterfall-ish problems.
Take-Home #2: Agile in name and process can only take you so far. You have to live it in your head and in your life. For me, agile has a very Zen-like characteristic. You need to live in the moment, absorb the feedback in that moment and adjust your next action in response to all this stimuli. We are just like an amoeba that reacts to changes in pH. But the difference is that we are capable of controlling our re-action or subsequent action. An amoeba is agile by process only.
Take-Home #3: BDD can help you to change your coding and architecture attitude for the better. It is subtle in its intrusion, but profound in its impact. The subtley makes it dangerous. It is not about the clever use of words, it is about the way those words impacts on your code and your resulting architecture. So find your own cucumber and that does not mean you should go looking for another gherkin.
Perhaps I was not responsible enough. My actions and words have affected people in a way that I did not intend.
April 14th, 2009 §
At the 45th SPIN meeting in Cape Town tomorrow, I will be sharing the “stage” with Karen Greaves. Karen will be talking about the lessons she has learned in rolling out Scrum to a large enterprise. I have a feeling that it is about scaling Scrum out to more than 10 people. Karen has done this for 80+ people and I am certain that her experiences will reach an audience outside of Scrum circles as well.
I will also be giving a talk about Agile Requirements. It’s about behavior driven stories that go beyond traditional, fully dressed used cases. However, I will focus a lot more about the process and thinking behind this approach as opposed to the code behind the stories.
I always meet very interesting people at SPIN. Please take 2 hours from your evening and join us for some great geek chat at the Bandwidth Barnyard at 6.30pm on 15 April.
Update. You can get the presentation here. The size is optimized for iPOD and is quite viewable on your desktop as well. The tiny bit of ruby code is included in the zip as well.
March 13th, 2009 §
The last two geeky conversations I had, stumbled upon the same thing – how do you measure the effectiveness of requirements in describing the business to the business and describing the specification to the developer?
So, I posed the question “How far away are you from executing your requirements?”. If you are going to go through various steps and stages to get to compilation and then execution, then every step is an opportunity for valuable information being lost in translation. If you can compile your requirements immediately then nothing will be lost.
Each additional step between requirements description and compilation and execution is an opportunity to confuse the user and the developer and everyone in between. That’s why fully dressed use cases are not so effective as fully dressed behavior driven stories. And that’s why BDD is very agile and a great asset in DDD and use cases just don’t cut it anymore.
Right now, my favorite tool is Cucumber. I can execute the requirements and that raises the clarity ranking of my requirements super high.
March 2nd, 2009 Comments Off
I’ve been doing some internal DSL coaching recently, and my coaching-partner and I have been working BDD/TDD style. It turned out to be quite a nice experience overall. We started with a Cucumber based feature that described the behavior of a typical DSL script and we drove it down into rpsec where we tested each little part of the script. In the end, I achieved what I set out: the person I was coaching grokked the whole “code is data” idea behind DSLs.
Then I started thinking about what it takes to coach external DSLs. I got really scared – parsers, generators, abstract syntax trees. Those were things that most people wanted to forget about the day after they wrote the exam for that horrible semester course in university. What makes it worse is that I never did that in university – I did Electronic Engineering and we spent our coding time figuring out how to do Fast Fourier Transforms on digital signals.
But when I look at the progress that is being made in language workbenches to help us create DSLs, then I reckon we should dust off those books and start paying attention again. Some of these language workbenches still leverage a host language such as Java or C#, but the act of using a structural editor that edits the AST directly is strangely weird. But, some refactorings are just not a problem anymore. For example, if you are changing the node on a tree, then all the references to that node are automatically aware of it. Compare that to a text editor where you need refactoring wizardry in the tools to make sure all references are updated neatly.
I think that language workbenches may be a great tool for coaching DSLs because the things that made your head spin during that lex and yacc week, are made a whole lot simpler. You can focus on designing the language and walk into ASTs with less fear. But, be warned — language design is not easy, and you still need to know about ASTs and parsers and generators. In fact, just write a parser and a generator and it will be a learning experience that goes beyond DSLs. Better still, do it BDD/TDD style.
The relevancy of language oriented programming is just going to continually increase. Those previously “irrelevant” courses are important again. Watch out, the gap just got wider.
November 25th, 2008 §
My presentations from Oredev are finally available. After working through almost all the export options on Keynote, I have settled on QuickTime as the distro format. The “flying code” in the aspects presentation worked out best with QuickTime. Note that it’s not a continuous playback and you have to click-through each frame.
). This one has the flying code, as