Joel and Eckel on XP
It is Friday morning at 6:30AM. I'm still jet-lagged, even though I've been at SDWest for four days now. My jet-lag has to do with the exhaustion of attending this conference. It's been quite a ride.
SDWest is growing and thriving. The level of energy is impressive. This is not the frenetic pseudo-energy of the dot-bomb era; where people were running about helter-skelter to learn how to spend more money in a fruitless grab for the gold ring. This is the more determined, pragmatic, and permanent energy of people who are raising their personal and corporate level of professionalism.
Of course there were quite a few presentations on XP and Agile concepts such as TDD, Acceptance Testing, Unit Testing, etc. And, as always, these talks are very well attended, by enthusiastic audiences. My own talks on the topic were attended more by people who were curious about Agile/XP, than by people who already knew it. It seems to me that more and more people are interested in Agile/XP concepts every year; and they come to conferences like SDWest to learn about them.
Bruce Eckel reported in his blog that this conference has given him the impression that Agile/XP has "moved to the next phase". He suggests that perhaps Agile/XP has left the early adopter phase, and has begun to attract the more conservative market. Here's a brief excerpt:
Although I've been following the printed literature, the last time I had seen any agile talks was at least a couple of years ago. What most impressed me by these two talks is the focus and the level of polish, in particular the shift to more evidence-based presentations.
He and Alexa were talking about his 12 steps to better code. Step number 7 is "Do you have a spec." He made the point that you can't write good code without a spec. That if you try to write code without a spec you'll get confused and muddled because you don't know for sure what you are writing.
No problem so far, I quite agree. It is utterly essential to be coding to some kind of well thought through spec. But then he went on to say that he was in a kind of private war with XP (He mentioned something about trying to schedule a jello wrestling competition with Kent Beck - Actually, though Jello is not my preferred medium, I wouldn't mind having this debate with him.) because XP suggests that you code without a spec. And then he waved his hands around and said something to the effect that XP thinks that the "code is the spec". Joel made several other similar remarks about XP/Agile ("whatever that is") before the talk finally wound down.
What's amazing about this is that a significant number of the XP/Agile talks at SDWest were focussed on writing and managing formal specs. Indeed, I presented no less than three talks and one workshop on this topic; and I was only one of many. These talks and workshops proposed that QA be brought to the front of the process into a specification role. Business Analysts and QA Test designers become specifiers of the system, because they write the customer acceptance tests that define the true requirements of the system. These talks stressed the need that these tests be automated, and that they be readable. In other words, the customer acceptance tests are so formal that they execute, and yet so transparent that non-technical business people can read them just like requirements. These tests are the requirements. (See below for an example)
On XP/Agile teams, programmers don't just have a spec. They have a spec that executes. They have a spec that is unambiguous and cannot get out of sync with the application. They have a spec that is run against the system on a daily, or even hourly basis. On an XP team it is against the rules to check in code that breaks the spec.
I wonder if Joel is really listening. Perhaps he made a summary judgement of XP four years ago and has simply stopped following what's going on. It has never been a principle of XP that "the code is the spec" or that you should write code without a spec. Indeed it has always been a fundamental part of XP that you must write code to the customer's acceptance tests as the spec.
So, although I agree with Joel's step 7, it is vital to have a spec - I don't agree with his view that XP views the "code as the spec".
Anyway, I don't mean to suggest that the whole fireside chat was destroyed by Joel's il-informed comment. The chat was quite good, and I enjoyed and agreed with almost all of it. It was just that one little comment that got under my skin.
Add a comment[?]
Add Valid Salespeople
The salesperson record consists of just three fields: id, firstName, and lastName.Each of these fields are non-blank strings with no other constraints.
An attempt to add a salesperson with an invalid field should fail.
For example: If we try to add these nine salespeople to the system, the first three should succeed, and the last six should fail because they have blank or null fields.
| Add Salespeople | ||||
| id | firstName | lastName | valid? | |
| U999999 | Robert | Martin | true | |
| U840818 | Mitzi | Schofield | true | |
| 7734 | Jason | Billings | true | |
| Add Salespeople | ||||
| id | firstName | lastName | valid? | |
| blank | Bill | Jacobs | false | ''blank id'' |
| 1111 | blank | Johnson | false | ''blank first name'' |
| 2222 | Joe | blank | false | ''blank last name'' |
| null | Bob | Fitzwater | false | ''null id'' |
| 3333 | null | Fravitz | false | ''null first name'' |
| 4444 | Pete | null | false | ''null last name'' |
If we fetch the salespeople from the database, only the first three from above should be present.
| Get Salespeople | ||
| id | firstName | lastName |
| U999999 | Robert | Martin |
| 7734 | Jason | Billings |
| U840818 | Mitzi | Schofield |
!commentForm
Then, what object will be handling these requests in application?
get/set methods and using this object throughout your application?
I run into these kinds of issues such that an object (such as Person)
requires many fields and making the object bloated. And also, as you
mentioned in your writings, seems more data structure than object.
Is it more reasonable to make the above class as PersonData[?] and using a
new Person class in calculation of pays?
PersonData[?] field validation problem still stays aside. If it is a data
structure without set methods, when is it appropriate to validate the fields.
- That's a good question. It's gratifying that the test does not tell you this. The test just tells you what behaviors are expected. I presume that the there will be some kind of AddSalesPersonInteractor[?] or AddSalesPersonServlet[?] that will call the same methods that the FitNesse fixtures will call.
get/set methods and using this object throughout your application?
I run into these kinds of issues such that an object (such as Person)
requires many fields and making the object bloated. And also, as you
mentioned in your writings, seems more data structure than object.
- Certainly it is a valid approach. SalesPerson[?] can be a dumb data object (Fowler calls them Data Transfer Objects or DTOs). Some other object can be responsible for managing these DTOs
Is it more reasonable to make the above class as PersonData[?] and using a
new Person class in calculation of pays?
PersonData[?] field validation problem still stays aside. If it is a data
structure without set methods, when is it appropriate to validate the fields.
- Interesting question. I wonder if we might create a PayEmployeesTransaction[?] object that knows how to invoke the methods of Employee to create a paycheck.
PersonData personData = new PersonData();
Person person = new Person(personData);
- I've seen this done before. Herb Sutter used to call this the pimple pattern. Most of the time it was for isolating C++ headers from implementation variables. It could be done in this case too, but I don't care for it too much. I think if you are going to have a DTO, you should use it externally, not hide it.
This makes a lot of sense. I love the idea of an unambiguous, *executable* spec.
One detail I'm not too sure about: I'm currently working on a project where we're developing a framework that will be used internally by another team, and possibly other teams in the future (so it must be flexible and extensible). I'm using TDD to develop it, and from time-to-time I realize that I need to tweak and re-factor the API of the framework a bit. Now, what should acceptance tests/spec look like? If they define and exercise the API, that means the API must be designed up front. So is it OK for the acceptance tests/spec to also be changeable? It seems that Joel would suggest the API must be nailed down before coding can commence - but this conflicts with emergent design. Unfortunately, my boss is very anti-TDD and he is using this as ammunition (convincing him of the benefits of TDD and emergent design is proving to be an impossible task - but that's another conversation).
I hope I've explained the situation adequately - I look forward to hearing your thoughts,
Thanks,
Kent
One detail I'm not too sure about: I'm currently working on a project where we're developing a framework that will be used internally by another team, and possibly other teams in the future (so it must be flexible and extensible). I'm using TDD to develop it, and from time-to-time I realize that I need to tweak and re-factor the API of the framework a bit. Now, what should acceptance tests/spec look like? If they define and exercise the API, that means the API must be designed up front. So is it OK for the acceptance tests/spec to also be changeable? It seems that Joel would suggest the API must be nailed down before coding can commence - but this conflicts with emergent design. Unfortunately, my boss is very anti-TDD and he is using this as ammunition (convincing him of the benefits of TDD and emergent design is proving to be an impossible task - but that's another conversation).
I hope I've explained the situation adequately - I look forward to hearing your thoughts,
Thanks,
Kent
Add Child Page to JoelAndEckelOnXp