f3yourmind

The other night I was driving home quite late from the airport.  For that hour, the roads are quiet and it’s a relaxing drive home that gives me a chance to think back on the the day’s events.  At a red traffic light, I stopped, but some idiot in the lane next to me rushed straight through.  You know what happened in the next 5 minutes.  Lots of honking, screeching tires and near crashes.  Fortunately, there were not accidents and nobody got hurt.

Really?

No!  Even though there wasn’t this big crash, someone did get a fright of their life, even I as an observer got a fright. And someone else did continue their journey quite shaken and certainly not in their same frame of mind.  The only person that seemed to be least affected was the person who jumped the red light.  But I am speculating, maybe he was under pressure and really needed to get to the end on time, and so he rushed ahead and saw in his rear view the potential destruction he left behind.  And maybe he regrets his decision.  But he certainly did not see how his actions affected the other people that were close by, myself included.

Driving through a red light can kill you and you can kill other people too.  The same thing happens when ignore the red light from your tests.  You can hurt yourself and you can hurt other people too.

Just think about that red light at the traffic light and in your code.  It’s telling you so much.

• It’s telling you to slow down a bit.
• To look around.
• To think about the moment.
• Don’t focus on the end, you will get there in good time.
• If you ignore the red light, other things will break and other people will get hurt.
• Maybe you don’t know why you must stop, but you need to stop first, before you can find out why.
• It’s telling you to do the right thing, not the rushed thing.

Driving through a red light is another suicide pattern that I will add to my growing list.

And TDD is also part of ubuntu coding.  I am not telling you anything new.  I’m just telling you the same thing from another perspective.

I finally got out of neutral and pulled together the first public offering our Domain Driven Design courses in Cape Town, South Africa.  Normally we give these courses on-site with people on the same development team but I thought it may be fun and inspiring to open it up to everyone for a change.  Now I’m all excited again and really looking forward to a diverse mixture of people. Hopefully, I will see some old faces and lots of new people.

The one thing I can tell you is that the course is a very immersive experience.  I really hate lecturing but I enjoy probing conversations and that’s how I give the course. I don’t have answers to the practical work and concerns are addressed as we go along.  As a result, the day takes unexpected turns and routes.  But in the end I get you to the right destination.  Come along; you will leave exhausted, but inspired!

Take the Fast Track to Domain Driven Design

about the course /  course contents / should you attend? / register for the course

factor10 has expanded its services in South Africa to include our advanced and
expert level courses aimed for the software professional.  On September 8-9, 2009,
we will be offering a fast track to DDD for Architects at the BMW Pavilion in
Cape Town.

Who should attend?

This course is for software professionals that want to take the right steps towards
advanced and expert levels in their careers.  Register for this course if you want to …

• learn more than just another syntax and set of tools
• write software for large, long living systems
• increase the quality and maintainability of your design
• design high quality models and use code to represent those models effectively
• develop applications with a good APIs
• add a design edge to your skill set

Why should you learn DDD?

More and more developers and architects realise that learning every detail of a new
API just isn’t the way to deliver the best business value. It’s such a tough balancing
act; focus on the solving the business problem and focus on building working software
with your frameworks.

One way of taking a big leap in the right direction is to learn and apply domain driven
design. It is definitely not abstract and fluffy; it deals a lot with the code also. DDD
leads us to focus on understanding and to communicate that understanding very well;
in language, in design and in code. You will shift your focus away from designing for a
technology, and you will learn to design for the business domain; to the core of the
problems and solutions. Those are the most interesting parts and what your users
and customers really care about.

about the course /  course contents / should you attend? / register for the course

A team that I am coaching has settled on using BDD stories and scenarios for describing their requirements and specifications.  They’ve also chosen cucumber as their acceptance testing tool.  All well and good, but they are making very slow progress and seem to be really struggling with the change in workstyle.  I think I’ve spotted the reason for this.

The feedback loop is missing.  They view the stories as a spec that has been handed down.  And they have not made the connection that spec writing is design work that is intended to clearly illustrates concepts in a domain.  It is a form of writing code.  But it’s just that this code is, maybe, non-executable.

Here’s my workflow and how I close the loop.

• write story and scenario
• Sketch a design if needed – helps when pairing to be on the same page.
• Start writing test for scenario
• ooops … test is getting complicated? stuck?
• maybe the domain is not understood enough? Dig deeper, improve scenario, design (as needed) and continue writing test
• or maybe the scenario was badly written? Ignore scenario structure, continue writing test.  Refactor scenario later.  We’re in deep discovery mode here.
• get test to pass
• refactor code
• refactor scenario
• … cycle the red-green-refactor until happy.

Acknowledging when you’re in discovery mode and knowing that you are allowed to refactor requirements is the trick.  Nothing is cast in concrete.  That’s why I like frequent feedback loops with tight turning circles.

No feedback loop, no progress.

BTW, I really don’t like explaining such things as flow-charts and sequences.  You got to find your own style.  It’s not a recipe or rules thing.  The above is something that is about as close to what I do but it changes when the need arises.  That’s also another key feature of being agile – adapt or die in the waterfall.

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.

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.