Author Archives: Aslam Khan

Great Quotes for Domain Driven Design

Posted on by

I am revisiting the material for the factor10 Domain Driven Design course as part of a “freshen up” for the when I give it to a development team on July 1, 2009.  So I started hunting for some quotes to liven it up a bit.
Here are some choice bites for ubiquitous language.

“They have been at a great feast of languages and stolen the scraps” — William Shakespear

and

“Thought is the blossom; language the bud; action the fruit behind it” — Ralph Waldo Emerson

And on the need for simplicity, I really liked this one.

“There is never any justification for things being complex when they could be simple” — Edward de Bono

Robert Bravery commented on an old blog post of mine and I re-discovered this one

“Don’t indulge in any unnecessary, sophisticated moves.  You’ll get clobbered if you do” — Bruce Lee

Lastly, and the one I’m definitely going to use to stress the importance of working directly with the domain expert.

“Never hold discussions with the monkey when the organ grinder is in the room” — Winston Churchill

What a diverse group of people but such collective value.  Do you have any classic quotes?  Obscure quotes?

My Event Horizon

Posted on by

It’s already halfway through the year, so let’s see what events are is in store for the rest of the year.
June: Next week is SPIN week.  Join us after the June 16 public holiday.  Same time, same place.  Last month we had 40 people attend and we just about ran out of chairs.  Lots of new faces.  Please come along.  The talks are normally good and the conversations are great.

July: Really need to get my act together and get to the next SA Developer‘s talk.  Hilton Giesenow tells me it’s a great local event.  And On July 27, Lia turns 5!  Simply amazing!

August: Hmmm, seems quiet?  I think I’m going to submit a tutorial proposal for the ICSE conference happening in Cape Town in May 2010.

September: Looking forward to the Scrum User Group‘s conference in early September.  I may be giving a talk on the techie track.  I think it’s going to be a great event.  Carlo and Peter tell me so.  But on September 3, Fiona turns … older 😉

October: My tutorial on using DDD and AOP to create clean, rich domain models has been accepted by OOPSLA.  So, October is OOPSLA time for me.

November: I will miss Oredev.  The competition to get in was so much tougher.  That just means it’s going to be better than last year.  If you’re a S.African developer, you should make a plan to get there.  It’s a great event that is very high on value for money.  But my November highlight is Khaleel turning 9 on the 22nd!  Boy, how did that happen so fast?

December: Crazy season again.  I really hope it’s a quiet, relaxing one this year.

If you’re not on Afrigator, you’re not on the Continent

Posted on by

Take a bow Justin Hartman and the rest of the Afrigator crew!  Great site, great feel, constantly improving. Superb.
A few weeks back I got invited to Gatorpeeps by Stii via a tweet dialog that we had.  Didn’t know much about it but dived right in.  What a great surprise.  Although I only have 10 followers and less than 100 peeps, I found the community  humble, friendly and relaxed.  What a pleasure.

It reminded me of the pre-Internet days when everyone on a BBS at the slow end of a 9600Baud Hayes (in)compatible modem was just there to help each other out.  No showboating, no egos, just people interacting with people.  It felt good then.  And it feels good again.

So what’s wrong with twitter?  Nothing.  But these are local folk with local perspectives which makes it easier to relate to and quicker to build relationships.  Hey, I’m certainly not a big mate of any of my followers but it feels comfortable and that says a lot about what Afrigator is doing right.

I’ve met some remarkable people in the last few weeks.  Here’s just a few of them.

@ashraf runs a super cool football fanzine.  Why go hunting for footie gossip when I get a peep feed .

@aegjung is an interesting combination of Afrikaner philosphy and culture and alternative views of things.

@cntombela has a another great footie blog with local flavor too.

@justinhartman is the open face behind Afrigator but his blog is a lot wider than his job

@robertbravery gives me a quick daily dose of web content/tech knowledge.  Short and sweet.

@stii is a developer supreme at Afrigator and his blog is a mixture of developer experiences and observations.

Go on, get your blog onto Afrigator and start peeping.  You’ll be surprised how many people like you are out there.

Like I said … if you ain’t on the gator, you ain’t in africa.

Writing Specs is Writing Code is Designing

Posted on by

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.

Domain Specific Reference Architectures

Posted on by

Many big vendors have invested a lot on blue print or reference architectures.  I came across another in recent months.  I witnessed a vendor team moving from client to client implementing this reference architecture as part of their SOA solution.
What were they actually doing? They were mapping the client’s domain to the reference architecture domain and thereby identified reference architecture services that supported the client’s needs.  This most probably works for some people.   But I feel uncomfortable with it because…

  • It means translating from one domain to another and back again.  It’s like having one massive bounded context around the reference architecture with a gigantic set of adaptors and transformers.
  • There is a very real possibility of semantic impedance on the boundary of the two domains.
  • There is likely to be two domain vocabularies or one large polluted vocabulary with synonyms, etc.

There are other reasons but these few are just old problems and habits coming back again.  Things that we accepted as dangerous and limits success in creating good software.

So, are reference architectures bad? Yes and no.  Maybe you should consider adopting its domain vocabulary as a first step.  A reference architecture with a rich metamodel is more likely to be more valuable than one without a metamodel.

And the moment you start thinking at a meta level, then you’re moving into a higher level of abstraction.  In this higher level, you will have a greater opportunity to describe your intentions agnostic of the reference architecture and the vendor’s technology stack.

The way I see it, services are defined at a meta level.  They describe your intentions and are independent of a reference architecture.  However, if you chose a reference architecture up front, then describe your intentions in the vocabulary of the reference architecture.

Does this make sense?  Because I’m just hypothesising here.

Wanted: Muse. No experience needed.

Posted on by

Artists have muses.  Muses are their creative inspiration.  The Greeks also called it a daemon – that mythical thing that gave magical creativity.  It’s actually their genius spirit that helps them when they’re stuck in a metaphorical tight corner.  Same thing, I think.  So when did we stop having geniuses and became geniuses?
I think I am actually searching for a muse.  Something that will be my creative genius.  I gave up trying to be a genius a long time ago.  Now I just want to learn from those that are better than me, whatever the context.  Maybe my muse is the sum of every engagement with the genius in each person with whom I work and live.

Searching for miracles

Posted on by

I never liked the words pilot nor proof of concept.   I have been through many pilot projects and proof of concept as projects or in projects.  Although the intention is well understood by everyone at the very beginning, by the time we reached the end, there almost always seems to be confusion about the purpose and next step.  Now I don’t even seem to know the differences and intentions anymore.  Even though everyone seems to know that they are different, they receive the same miracle software expectation.  It’s an execution confusion issue.
But I think the main reason for pilots and proof of concepts is to get feedback.  Spikes do the same thing too.  You know you’re seeking enlightenment when you start saying “I don’t know … enough…” or “It depends…” or “What if.” Whenever we work with a new domain or a tricky part of an application, we are searching for feedback, not miracles.  If you practice TDD and do exploratory testing of concepts that are not 100% clear in design and even understanding, then you know what I mean.  Perhaps we must just drop the grand classification labels and our response should be something like “Well, let’s explore this tiny bit and see what happens” or “Why don’t we try out this idea by doing …”.

So we do proof of concepts and pilots all the time.  It’s just that I hate searching for miracles but I like feedback which helps me change the probabilities of certain of things happening.  And I like it to be part of my workflow.  Exploration gives me feedback and increased understanding that leads to more exploration.  I hate it being a milestone on a Gantt chart and when that milestone is a common point in critical execution paths for the project, then I know, for sure, someone was actually looking for a miracle.

If you are somewhere on the agile adoption curve, then drop the Gantt chart.  Now you’ve just removed the shrine for miracle worship.  There are no shortcuts to enlightenment, just feedback with every step.  Success depends on how you absorb and react to that feedback.

Continental Shifts

Posted on by

I see many people freak out at the mention of any change.  I often do that too.  Why?  Because it forces me out of my comfortable existing neural wiring.  Now I try to view change as a contextual adjustments and a little bit of re-wiring for comfort sake.
Hmmm, as I age, I think the slight contextual shifts that I go through now feels less like the massive catastrophic continental shifts.  Much nicer.

Ambler, Hundermark and now my Two Cents

Posted on by

Peter Hundermark has a nice summary of the talk on Agility at Scale that Scott Ambler did in Cape Town a few weeks ago.  And Scott had the courtesy of straightening out some thoughts on Peter’s blog as well.

Padding End Dates. End dates exist because of our immense desire for closure.  We cannot tolerate the thought of not knowing when something comes to an end.  So we would rather stick in a fake end date than no end date.  Are you prepared to stick an end date on your life, just so that you can create a finite sense for someone else?

Optimizing the whole. For me “whole” means everything, your workflow, your thinking, your architecture, your code, your communication, … everything.  But just drop into the code bit for a moment.  The reason TDD works is because it gives you feedback quicker.  It is not about the red-green-refactor process alone.  You have to be agile in your code and design too.  And linear problem solving results in linear code styles and mindless red-green-refactor results is not agile unless you are 100% immersed in the moment of exploration and discovery.  Overall, I think optimizing the whole, getting rid of wastage, lean, etc is all about finding the right balance – at that point in time, in that context.

BDUF. How much of upfront design is big design up front?  It depends on the context and the principles on which your software development is based and also who is affected by the software that is produced.  I like the phrase “little too much design up front” and “little too little design up front” which I picked up in this post by Kent Beck. (Please don’t acronymize that!).  That particular post was simple and extremely profound view, for me at least.

Just when I thought that I am making progress, I feel like a noob again.

Learning Rules for Noobs

Posted on by

The unfortunate human characteristic in all of us is that we like rules when we’re in a new and unfamiliar situation, and hate them the moment we think we are experts.  The problem is that rules are great for creating concrete things.  If you want to build this then: do a, then b, if you have a c then do d otherwise do e.  But it does not work with creating abstract things.  And software development is all about building abstractions.
In the past few weeks, I’ve had a few instances where I realized that some people were,  basically, asking me for DDD rules – steps for building an aggregate, when and how to use the specification pattern, etc.  There are no rules for the noobs for these things.  But I think I can constrain the environment so that the noobs can focus a bit more intimately with these aggregates and specifications.    One rule I put down was “When working with the following … don’t work outside of this Java package”

Essentially, my proposition is that rules for noobs should constrain the learning environment, not the subject being studied.