The video of the interview is here.
First you get the UI, behind that there is code that gives benefit to the UI, and behind that there’s code that gives benefit to that piece of code, is smaller and more specific bits until the feature works. The Domain Language is used all the way through. Dan North tells a story… While the developers were struggling with how to handle credit derivatives, a domain expert (a former trader) came by. Because the developers were talking in the Domain language, the expert didn’t know they were even talking about code. He thought they were talking about derivatives themselves and explained exactly how they work, giving them the algorithm.
Scenario (and example) are words that the customer has a natural understanding for (unlike use case), that flesh out behaviors: given this situation, what to you want the software to do – what is the outcome?
This eliminates misunderstanding between the stakeholder and the developers as to what “done” actually means.
Using “should” has two benefits. Firstly, it forces you to focus on the class under test, because behaviors that don’t belong to that unit will not fit the “should” format. Also, it allows the space to continually question “should it actually do this?” This will have the documentation (the tests) naturally evolve with your understanding of the domain.
North describes different methodologies as:
He concludes by suggesting that developers who are ingrained in the domain language can actually become part of the process of discovering business value, as they bring their level of understanding to the domain.
Why are we writing software? People are doing things that matter to them. Software supports and enables them to fulfill on what really matters. Nobody is born and says “I love bytes. What really matters to me is sitting in front of a screen all day.” The user of the software has real dreams and desires. Software, at it’s best, can magnify their ability to achieve those dreams.
How do we create software that has the maximum impact on what matters to our users? Assuming that their business process is effective (who knows how much business value could be derived from the question “what is important to us and how do we fulfill on that?”), the question becomes “what will this software do to produce outcomes that matter to the customer?”
Ultimately, it’s the outcome that matters. The customer cares about the behavior of the software, but as a means to their ends. The metaphor that most completely captures and illustrates puts this outcome at the forefront, as the driver of the process. How would we communicate this?
???? Driven Development:
The question that the customer needs to answer for themselves is “what’s most important? Maybe an access is “why do you do this?” This would be an ongoing question. The process is then to continually declare and implement behaviors (what it does) to fulfill on these (why it does it). Obviously a domain language would be invented and agreed upon so what matters can be faithfully translated – to outcomes, then behaviors, and finally into code – without losing any of the juice.
It could look something like this:
What would this achieve?
As I read the design patterns in Agile Software Development, I constantly have to remind myself to avoid Needless Complexity.
It’s so perfect that a clue to poor design is applying design techniques themselves, if they are unnecessary. It completes the circle and keeps you honest. And, it’s so hard to live that it’s mentioned 8 times in the book – p. 86, 88, 136…
“if… the application is not changing in ways that cause the… change… separating them would smell… An axis of change is… only if the changes actually occur” (p. 97)
“we initially write our code especting it not to change. When a change occurs, we implement abstractions that protect us from future changes of that kind… we take the first bullet… get the bullets flying early and frequently… stimulate changes… [by writing] tests first… using very short cycles – days,” prioritizing features – getting frequent feedback, and releasing the software early and often (p. 105), “defer all but the most obvious LSP violations until” you smell fragility (p. 116)
“global variables are not intrinsically evil… situation is an ideal choice for a global… only ever one instance… known by a very wide audience… a singleton or monostate would smell… it’s easier to simply keep the database instance in a global” (p. 213), & “don’t be offended by the… public data members. This is not an object… just a container for data… no interesting behavior to be encapsulated… private [data with] getters and setters would just be a needless complication” (p. 339).
My Behavior Driven Development research has turned me onto Domain Driven Development, as explained inDomain-Driven Design: Tackling Complexity in the Heart of Software.
Ok, enough for today. Very good focus on sound design.
Did you ever use a product and want to find the person responsible and… give them a hug. Probably not often if you have the experience of corporations that I do!
For the past few months, I’ve been deciding how best to access my programming reference books while program from multiple locations (home, office, client’s office). I accidentally found Safari Books Online (http://www.safaribooksonline.com). They have almost every significant programming reference (at least for C++) written in the last 10 years. Here’s a list of some of my favorite, available online at the site:
Are you kidding! No more lugging 6 textbook sized books everywhere I go!? The service is about $45 a month and the best money I’ve ever spent on a programming tool.
By the way, I have no business connection with the company, just wanted to share!
My adventure continues. Today I’m exploring Behavior Driven Development, which seems to address my “lost in the jungle” relationship to TDD by starting with user requirements:
First reference, from the man himself – Dan North, the creator of BDD @ http://dannorth.net/introducing-bdd:
I remember thinking “If only someone had told me that!” far more often than I thought “Wow, a door has opened.” I decided it must be possible to present TDD in a way that gets straight to the good stuff and avoids all the pitfalls.
Damn, sounds good so far!
The details:
Impressions: whhhewww. I’m relieved that this isn’t yet another approach that must be learned from scratch. It’s really just a metaphor (to quote Bob Martin) shift. The techniques are identical to TDD, just looked at from the perspective of the users of the system. What is the behavoir that the user wants in this stiuation – nothing to do with implementation! This is great because that’s what the software is all about anyway! It seems like TDD focused on the needs of the customer – perfect!
Bob Martin suggests that BDD really describes a finite state machine that could tell you all the possible combinations of behavior, and thus what tests to write and when you are finished (http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd).
If you do any work with hidden files on your mac (like local web development .htaccess files), this script will save your behind.
http://forums.macworld.com/thread/72863
Just set a shortcut to it with FastScripts – one of my favorite Mac apps – and your ready to rock!
p.s. I edited the script by moving the “Finder” quit line to the start of the script changing the delay to .02 (after a bit of experimentation) – so far so good!
I’ve been wanting to keep a CGI script outside my web root (for security), but still serve it on my site.
The problem:
After days of mailing list and forum posts, always seeming right on the edge of success… Arrrggghhhh!!!!
The solution?
And, voila: script outside web root served!
I hope this saves someone else the frustration!
p.s. the minimum permissions to make this setup work are:
I’ve been writing code for a C++ CGI application that drives a website. I love Test Driven Development, yet I can finally see that it’s just one technique – albeit a very effective one. I can’t wait to integrate the other Agile practices and see what shakes out. Right now, driving with unit tests, I feel like I’m in the middle of a jungle with the sharpest, lightest machete available – now if I can only figure out which way is out, I can start chopping, lol
Acceptance Testing! Duh. Something I’ve always heard about, but never investigated. It makes perfect sense: sure the objects work, but are they even the right objects?! Start with what success looks like from the customer’s point of view. I just found FitNesse, an Acceptance Testing tool by the legendary Robert “Uncle Bob” Martin. Looks promising…
Recent Comments