We will be meeting up on Thursday 29 October to discuss test driven development. We’ll be at the Lamb and Flag from 8pm. Our discussions will begin by talking about the books by Kent Beck and Dave Astels on the subject. But you don’t have to have read either to come and join in.
We will be meeting from 8pm on 11 November at the Lamb and Flag to discuss Organizational Change. The starting point for discussions will be the book Fearless Change, but come along if you are interested in the subject and have not read the book.
There were just four of us here to look once again at Domain Driven Design (DDD): Myself, Tom, John and Ursula. 
Tom began by saying that he hadn’t re-read Eric Evans’ book but that he had actually been trying to apply it since we last looked at this topic. He admitted that it was quite difficult, but that going back he’d found the key sentences that he’d missed when reading it the first time. He found that initially it is easy to get swept up in a wave of object oriented enthusiasm. But when you go back and look, Eric Evans is saying that you have to make compromises in some places. Ursula suggested that there is always a danger when learning a new pattern that you overuse it.
My initial thought was that the difficulties lie in the associations between objects. The ‘pure’ OO approach would yield a huge web of objects that just wouldn’t be practical. Tom agreed and said that going back and looking at the discussion of when to use association traversal and when to use a search was the key thing in this area.
John asked how hard it is to actually use the techniques described by Eric Evans. Tom admitted that it was hard and that you are constantly assessing how to proceed.
Ursula wanted to know about how you cope with the situation where one team builds a system using DDD and then another team takes ownership. My take on this was that it is very difficult indeed for the model to survive this transition. As Eric Evans describes on p3 of his book, the model is really a mental model. Any diagrams, documents or discussions of it are really just a view into that model, not the model itself. Tom said that you really need a permanent person to look after the model.
Ursula then asked about whether the modelling is done for the applications you are building today or if it is supposed to be a foundation for future development. I mentioned that Eric Evans talks about updating the model as new insights are gained and that he seems to suggest that it is possible that the model itself suggests future possibilities (Chapter 8). Tom was a little skeptical on this point.
Tom said he has found that the domain experts he has worked with have never seemed to be as good as those described in the book. John said that sometimes they find it hard to visualise what could be done, so there is always a gap between the developers and the domain experts. Often you need to produce a prototype just to get discussions going, but the Ubiquitous Language also helps to close this gap.
We then looked in particular at the part of the book in Chapter 7 where there is a discussion about how to design the associations, aggregations and so on, looking at an example. Tom said that he had an “aha” moment on p171 where the Handling Event object was not part of the Cargo aggregate, when he would naturally have put it inside. I mentioned that we’ve seen the problems of developing without the use of Aggregates in our codebase. So I’m definitely a fan of moving to the use of this pattern.
I also had a question about something on p171 – I wanted to know how the fact that the Delivery Specification object is a Value Object would affect the implementation of it. We had another read and it seems likely that the object would be immutable, shareable and cacheable (are those real words?). I found the idea of mutable value objects a difficult one. Looking at the discussion of this on p100 it seems that generally you shouldn’t do this, but that it is sometimes needed for performance reasons.
Ursula talked about the difference between an Analysis Model (which just models the domain) and a Design Model (which contains implementation details) and how those concepts fit into DDD. My take on this was that in DDD you do both types of modelling at the same time and that things like aggregates and the way associations are modelled are purely implementation specific, so are not really an artifact of analysis.
We will be meeting at the Lamb and Flag from 8pm to discuss Domain Driven Design. The starting point for the discussions will obviously be the concepts in Eric Evans’ book, but don’t be put off if you haven’t read it. There is a good free introduction to the area in this freely downloadable book available from InfoQ.
At yesterday’s meeting, we had a discussion about how to improve the way we run the group and encourage more folks to come along. Steven was at the forefront of these ideas and said that he thought that reading a book a month was really too much. He also thought that concentrating on the book puts people off, even though we explicitly say that you don’t need to have read the book to come along. So we are going to make a handful of changes going forward:
So, back to last night’s meeting. Joining me to discuss Release It! were Tom, Steven, Jocelyn, John and Ursula. Tom kicked off by saying that he hadn’t realised beforehand that it was about making your software robust for real life usage. But once he started reading it he found it hard to put down. Lots of it rang true and reminded him of situations he had been in before. On the down side, he felt that the stories were a little predictable after a while.
I pointed to the “Circuit Breaker” pattern as one that I found very interesting. This seems to be the one that has generated the most interest judging by the postings on the book’s forum. I also found a description of this pattern implemented as a Spring aspect.
Tom was also keen on the Bulkhead and Decoupling Middleware patterns. Something he thought was missing was a discussion of splitting up a large system into separate components so that you could shut down individual components and leave everything else running. This wouldn’t even have to be something as sophisticated as OSGi.
Steven said that he was looking for ideas to make his new mobile “Good Beer Guide” service stable. Unfortunately he didn’t get too far, which is ironic since he was the main person advocating this book.
Tom said that when he used to be a sys admin it was great to have data about the systems you are looking after. So when a problem arises and someone says “the network’s having problems”, you can open up your dashboard and say “Nope, look at the data”. He liked the story about ‘Voodoo Operations’ where the database kept being restarted just for luck (p280). Tom said he’d experienced people doing this sort of thing for real.
Ursula liked the discussion about making log files easy to read (p279). This seemed like a very simple idea, but a powerful one. John said that all this sort of thing had been done in the 80′s, but that when PCs and Unix took over from mainframes the whole financing of software changed. So that quick and dirty was the order of the day. But now we are going back to those roots.
Ursula said that she found the whole section on Capacity very interesting. In her experience that sort of work has always been left to experts to deal with at the end of a project whereas it might make more sense to think about this from the start. She did however find that the book was very focussed on web applications and mainly on Java. But she thought the references (internally forward and backward) were very well put together.
Our next meeting will be at 8pm on Tuesday 12 August 2008 at The Lamb and Flag to discuss Behind Closed Doors by Johanna Rothman and Esther Derby. This book is about management rather than software development as such, so the discussions should be slightly different from usual.
I was joined by Tom, Steven, Ursula, John and first timer Ed at the Lamb and Flag to discuss Ken Schwaber’s book on Scrum. I’d recently completed some ScrumMaster training with Mike Cohn, so I had one or two extra insights into Scrum over and above what’s in the book.
Steven began by saying that he’d begun by thinking that the book was very short, so would be easy to read. However, he found it quite dense and slightly repetitive. Ed said that while he liked the book, he didn’t really like the style very much. Tom felt that there wasn’t much to it and that he’d picked up most of the ideas in it from conferences and so on. Perhaps this is because what was fairly radical at the time it was written is no longer so? I also pointed out that there were parts of the book I just plain didn’t follow. Section 1.3.1 contains paragraphs discussing Sychsteps and Punctuated Equilibrium. This went straight over my head.
John admitted that he hadn’t read the book, but had picked up things on the web about Scrum. He questioned how the whole team pulls together in the right direction. Ed replied that using this methodology, there is nowhere to hide because the team needs to deliver working code every few weeks. If someone is doing the wrong thing or just plain lazy, this will soon be obvious.
John was pleased that Scrum seemed to embody some of Tom Gilb’s principles (as discussed in our previous meeting). But he seemed concerned over the lack of metrics to show that it works.
We then digressed into a discussion of software metrics. I questioned what metrics John would like to see. He suggested metrics around function point analysis and project predictability. I suggested that Scrum doesn’t concern itself with function points and the like because it is concerned with delivering value to the customer. In fact, if you can deliver more value (however measured) to the product owner with less function points then that would be good all round. I couldn’t help mentioning Martin Fowler’s essay on why he believes you cannot measure developer productivity. On predictability I pointed to the section of the book where Ken Schwaber talks about the difference between “defined” and “empirical” methods of process control (Section 2.1 in my copy of the book). His thesis is that software development is too noisy a process to try to control with the “defined” method, so Scrum goes for the “empirical” method instead.
Tom said he’d read the book and the thing he liked best was the way the team was protected from change during a sprint. He has seen first hand the problems that can occur when a team works on one thing, then switches to another and so on. In Scrum no changes are allowed during the sprint unless the whole sprint is terminated and the work thrown away. This sets a high enough bar that all but the most important changes are deflected until the next sprint.
Steven questioned if the sprint length of 30 days was set in stone as the book seemed to imply. In fact, on my course Mike Cohn suggested that 2 and 4 weeks were the most common sprint lengths. The main point is that you need to choose a length and stick to it so that the team gets into a rythmn.
Ursula asked about the difficulties of interacting with other teams who are not using Scrum or other iterative approach. This was not mentioned in the book, but at my course Mike Cohn talked about the idea of a “release sprint”. This is a sprint you do before each release to do things like awkward manual testing against legacy systems which it is not practical to do every iteration, but which must be done before a release.
I also pointed out the section on reuse (Section 7.1.2), as Ursula had asked about this at the previous meeting. She seemed to think that it seemed sensible, as it said that the code being reused must be stable before reuse can be considered.
Our next meeting will be at 8pm on Tuesday 8 July 2008 at The Lamb and Flag to discuss Agile Software Development with Scrum by Ken Schwaber. I’m personally doing some Scrum training just beforehand with Mike Cohn, so hopefully I’ll pick up some pearls of wisdom from him that I can share. See you there!
There were just four of us at the Lamb and Flag to discuss Tom Gilb’s book Principles of Software Engineering Management. Steven and I were joined by John and Ursula. John said that he had read the book in question some years ago. He said that lots of people didn’t really get it when it came out and he included himself in that category. One of the themes of the book is the idea of inspections, but John suggested that Tom Gilb had been frustrated that no-one really picked up on that. So he ended up writing another book Software Inspection to try to hammer the point home. Apparently people still didn’t really get it. John said he realised this when he read James Womack’s book Lean Thinking where there was a discussion of how western companies could never truly understand the ideas of Lean. I admitted that I didn’t feel that I’d really got what Gilb was driving at with inspections.
Something I did like about the book was the discussion of what requirements are and how they differ from solutions. No-one else discusses this – in other development methods it is always assumed that the customer takes care of that part and has at least some idea of what they want. Chapter 4 of the book did a very good job of exploring what parts of ‘requirements’ are actually just solutions. I loved the story of the California teacher system. The customer specified that they wanted a computerised system and that’s just what they got. Unfortunately it cost 7 times as much to use the new system as the old paper-based one. What they really wanted was a cheaper and more efficient system. But they expressed this by giving a solution, not the actual requirement. As Steven pointed out, this mindset is much like the thinking in agile and lean methods, where you focus on the end goals and delivery of value at all times.
While the mindset concentrating on the delivery of value was very much like lean, I found the idea of have one hundred attributes to measure the success of a project rather different. It seemed to me that this was almost like not concentrating on your base goal. Would the project be a success if all those attributes went in the right direction but the company became less profitable and less popular with its customers?
Going back to inspection, I said that the very use of that word is almost an anathema to those who practice lean. The mantra is that you should try to ensure that there are no defects, not look for them later. Ursula thought I had the wrong end of the stick and that there would always be defects in a software product and that Gilb’s inspection is more like the lean idea of “Stopping the Line” when there is a problem.
Steven said that he thought the key message of the book was that evolutionary delivery is key to success. John agreed that you need to give the users something as early as possible. This idea is now widely accepted, even if other parts of this book are not.
Ursula talked about the idea of constantly recording task estimates as a way of improving the quality of them. She also talked about confidence measuring. This was a way to see if people on the team had doubts which they didn’t want to bring up. It would be easier for them to say they were not confident about hitting a deadline perhaps than bring up the reasons why. I said that I thought that the idea of project velocity was a good one as you don’t need to keep re-estimating all the time.
Finally, I asked if anyone understood what Tom Gilb meant by an Open-ended Architecture. Steven suggested that it meant that the design was not constrained unnecessarily. I’m afraid this is something else that I didn’t really get. Someone may have tried to explain it to me, but I’m afraid it was too late in the evening for my brain to take it in by this stage.
Our next meeting will be at 8pm on Tuesday 10 June 2008 at the Lamb and Flag to discuss Principles Of Software Engineering Management by Tom Gilb. This was Steven’s choice and he explains:
The reason I add the Tom Gilb book, is that I met him at ACCU and he says this book from 1988 is timeless (rather like Mythical Man Month) as it is based on principles rather than specific technologies. He also said that this is the book that inspired Kent Beck et al to develop Agile software, and much of the agile principles such as evolutionary development come from this book… but they got some it wrong. So you could argue this is the original book about agile software development.