Anyone else follow DDD, BDD, TDD, Agile, etc groups/communities?

Dj_Jestar

Dj_Jestar

Dj_Jestar

Caporegime
Joined
18 Oct 2002
Posts
29,493
Location
Back in East London
We've had plenty of "help me code this stuff" and/or technical threads, but nothing 'higher level'. I was wondering if anyone else likes to follow the practices and principles laid out by the aforementioned communities and such?

I often attend meet-ups for TDD/BDD and DDD. I try to get in on as many software craftsmanship courses as I can, and also attend the free agile workshops at Skillsmatter when I have the time. I attended the Domain Driven Design eXchange this year and last, and hope to attend next year too. I'm also attending the agile specifications, BDD and agile testing eXchange later in the month.

Anyone else here interested in these areas? Anyone want to discuss/debate them?

:)
 
Dj_Jestar said:
We've had plenty of "help me code this stuff" and/or technical threads, but nothing 'higher level'. I was wondering if anyone else likes to follow the practices and principles laid out by the aforementioned communities and such?

I often attend meet-ups for TDD/BDD and DDD. I try to get in on as many software craftsmanship courses as I can, and also attend the free agile workshops at Skillsmatter when I have the time. I attended the Domain Driven Design eXchange this year and last, and hope to attend next year too. I'm also attending the agile specifications, BDD and agile testing eXchange later in the month.

Anyone else here interested in these areas? Anyone want to discuss/debate them?

:)
Click to expand...

I'm interested, although areas I have still yet to explore fully.

What I read about them I kind of find myself thinking 'i kind of already do this' but it does put methods and meanings behind why which is interesting.

What are the most interesting things you have learnt ?
 
At the moment I am fascinated by CQRS with Event Sourcing since seeing/meeting Greg Young and Udi Dahan at DDDx. Though I've not got any use of them yet (outside of personal projects) so can't really say they have returned much value (at work/in the real world) for me yet.

A lot of the TDD/BDD workshops I have attended have really helped at work, especially Acceptance testing, and specifically how it has shown me the value of involving the client into the process. Letting them see the real-time feedback of a test passing, and their involvement in the design via these tests. We've also learned a lot from some courses provided by software craftsmanship (Jason Gorman) namely his TDD Masterclass, Refactoring Masterclass and OODesign Masterclass.

If you already "do" those things, then even better for you to attend any groups/workshops to discuss the ideas with other like-minded people. These aren't just "sit there and soak up information" seminars, although they will have presentations, they are also for people to exchange ideas and experiences. Sometimes all you get as a reward is confirmation that what you are doing is right, but most of the time you'll be able to relate to someone else's experience and both of you can discuss and learn. :)

It's also good fun to just have some geek beers with other developers that are not in your organisation and just talk about stuff.
 
Hmm.. I hoped there would be a bigger response to this, even if it was "I don't care for Agile". Maybe posting at the weekend didn't help, so here is a midday Monday bump :p
 
I'm starting to, on a very small scale, purely to start getting an idea of what goes on. I don't know whether or not you remember, but you gave me some advice on getting in to the field and although it's a slow process, I am getting there. Figured this would help and it certainly seems to be. :)

I can't really contribute much to the thread, but those links seem interesting. I doubt attending any workshops would help at the moment though, right? :p
 
I don't think it'd do any harm to get involved, though there is a level of assumption made about everyone that attends. They aren't there to teach you how to code, only how to manage your project(s) and improve your practices such as test driven development. :) I.e not the technical side.
 
I'd love to be seasoned in these techniques, but I’m on the learning curve right now. I’ve only been involved in IT for 18 months or so, but in that time the company decided to move from waterfall to agile (scrum). It’s been interesting seeing the transition but it’s not been easy for a lot of people. There have been a lot of failed scrum teams while everyone is adjusting.

I’m more the type to embrace change and prefer working with the newest tech / concepts. I have been lucky to capitalise on the changes and get some scrum master training. I did scrum master duties for a project and we were very successful, produced software on time, in budget and basically we all had a laugh doing it too. It was a very good experience and I’m a big fan of agile as a result – it’s not universally popular though by any means!

We are still developing large business critical applications on ASP.NET Webforms and not much thought is being put into architecture. I would like to help drive the technology we use and the way we develop forward if I can, so I’ve currently got my head in a book called ‘Pro ASP.NET MVC2 Framework’ and I’ve encouraged a few others to start looking at MVC2 as well.

This goes into DDD, BDD, Mocking, DI etc. It’s making my head hurt trying to learn all of this but I can see how this would be great for an upcoming replacement of a large application (currently on classic ASP with massive pages, some over 6000 lines of code).

The ‘business’ is constantly requiring new functionality over the life of this application, and for parts to be removed, upgraded, changed. The current application has no unit testing set up, so we constantly run the risk of breaking existing things when we add new functionality – which has happened a few times even with regression testing in place. Also the business rules, application logic, database queries, page formatting, client & server side scripting is ALL interwoven on each page – making changes to it is a bit of a pig.

Hopefully using all the latest concepts will make it much more fun to develop and we end up with a nicely architected application with maximum separation of concerns. Also with the ongoing changes that will have to be made, it will be nice to have the views, models, application logic, business logic and database persistence all separated out instead of one 6K line lump! It will also be nice to be able hit a button and see all of the old unit tests pass before the changes are released.

So yeah basically I am definitely interested in all this stuff but have a hell of a long way to go before I’m where I want to be with it. Thanks for the link i'll check these out...
 
We're just finishing up rewriting out client side website using DDD (sharparch framework with nhibernate), MCV 2 and CQS command query separation in the service layer and down. It's been very good so far, the code is clean and logic lives where it's meant to in most situations.

With CQS, instead of going down the route that Udi Dahan has been talking about with full CQRS and event sourcing we simply split out our service layers in to Command and Query, these then call down to two separate mappings/repository/entity projects looking at the same DB. This has allowed us to tweak each side differently, query has little validation, entities can be returned to the front end as they are read only, the mappings and queries can be tuned for performance with caching etc. The command side is locked down with full validation, caching is only used in very specific places and no command side entity is exposed outside the application service layer.

The front end is straight MVC 2 and using a fair amount of jquery. Controllers are kept very light as almost all the business logic is in the service layer and entities. Security is dealt with mainly in the service layer, all calls to any sensitive data are checked for ownership and fair usage, it's like our barrier.

The team working on this is about 10 devs, 5 designers and 3 dba's with support from 2 PM's and about 8 business people, the project has been over about 10 months. We use our own slightly customised agile system. Work is usually broken down to 2 week timeboxes with 2 programmers, 1 designer, 1 business owner and a PM. It seems to work very well so far, we tried the usual agile/scrum stuff like daily meetings and shorter 1 week packages but we found it gets in the way of the deliverables. We found that a lot of these ideas need to be tuned to your working environment and can take a few months to figure out i.e. what is expected from a timebox, how do the teams work together, how and when you pair program, time estimates for deliverables, length of timeboxes, when to have meetings, sorting out the proper chain of ownership etc.

I'd say that a lot of these ideas are great if they are used to just help setup your own systems, I'm not sure if going 100% agile in medium sized teams with real business deliverables is always the best way or easy to pull off. Ours certainly isn’t perfect, we’re still tweaking it after using a lot of the approaches for years but that’s half the fun.

CQRS with event sourcing does look really nice but it's just another package of patterns and best practices to solve certain situations. You really need to work out what you are delivering and why you want to use a specific solution to solve it. What are the benefits/trade-off, how complex does it really need to be.

Hopefully we'll be able to continue tuning this approach for our other sites although they will need to be laid out a bit differently as they have much higher traffic with less transactions. New methodologies certainly keep you busy :)
 
Thanks for that DanF, that sounds like a good setup you've got. :)

Agile (and any sub-set/framework you choose to use) are certainly not easy to introduce. The learning curve is quite steep. Not because there is a massive amount of knowledge to learn, but because it is a mindset change, and you can pretty much guarantee it will be met with resistance.

If you haven't already, I know that Agile groups and the DDD groups would be very interested to hear of your experience. Particularly as you appear to be in an organisation that is quite set in its ways and are being "agile within a non-agile organisation."

And lastly, I completely agree. The point of Agile is not to do this or that, but to be in the right position to decide what is for your organisation and what isn't. :)
 
The project I am on is pure .NET, but we aren't using MVC (though we'd like to, and plan to in the near future) as the project is now ageing on quite a bit. The bulk of the project is in fact unrelated to web, it's a logistics track and trace system that has multiple interfaces (including system to system, as well as web and desktop).

However if the question is "What is my tool of choice?" then I'd say Seaside for Smalltalk or ASP.NET MVC2. Seaside for the pleasure of developing, ASP.NET MVC2 if the client doesn't trust Smalltalk. :)
 
Last edited:
We found that most of Agile/scrum itself was fairly easy to progress into as it's more the layout of teams and split of work side of things. We setup most of that side maybe 2-3 years ago when just working with webforms and std 3 tier architecture. The pms have been a big help here as they have slowly tuned the way they work to get the best out of it. The hickups where really in the experimentation phases like daily scrum meetings but I guess you'd hit this style of thing with any new methodology.

The biggest stumbling block we had at the beginning of this last project was convincing the DB team to let us loose with an ORM instead of sticking with tried and trusted sproc calls. Then it was picking between EF4 and nhibernate, we have an on-going database structure that isn't perfectly setup so if we had used EF4 it would have had to be Code First and lose the nice auto mapping features. At the time sharparch was only supporting nhibernate and we were keen to use it as it had done a lot of the ground work for DDD implementation.

It's also our first big heavy project with MVC/jquery so we are still sorting out best practices for going forward with it. Debugging JS gets pretty complicated the more you try to lean on it but it's the way the business wants to go.

The sharparch framework has been very handy to speed up the initial part of the project, we also use nhprof which is a really great tool for analysing nhibernate code, it’s like sql profiler on steroids. Other than that it’s just VS2010 + resharper and linqpad on the tooling side.
 
Last edited:
By daily scrum meetings do you mean stand-ups? Do you not have them?

We have 2 a day now! Easily the second most valuable tool in the Scrum framework, the first being retrospectives. First as soon as everyone is in the office, the second roughly half-way through the day (usually not long after lunch).
 
I can't remember all the proper terminology now, we tried having daily catchups but found that there wasn't much to say, I'd probably better explain :) The way the office is layed out we're all on the same open plan floor, the biz team is only 10 meters away so we go to each others desk through the day whenever there's something to sort out. Open communication with the biz owner of a timebox is really important but we found that it meant we had much less need for a scheduled meeting each day.

We lay out timeboxes over 2 weeks, the first Monday/Tuesday is going over requirements, signing off work, liasing with all people involved to make sure everything is correct and we're doing the right thing, the Wednesday to following Thursday are coding days giving us 6 days per 2 weeks. The Friday is just final testing and checking in the morning then usually we'll present back the work in the afternoon to the other groups keeping everyone up to date on what's been happening. Some work is too big for just 2 weeks so it's broken down to core parts and further timeboxes to add functionality in a more modular way.

It seems to be working pretty well so far, the PM's get solid units of work to plan and they fit in easily with set timebox lengths, the biz team get complete sets of functionality at regular times and they can plan out and priorities work well. The devs are kept working fairly hard with built in time to check specs and do testing and Friday afternoons are kept fairly light.
 
The stand-ups are for each team, not the entire org :) They are also literally stand-ups. They should take no longer than enough time for each participant to briskly describe what they have done since the previous stand-up, and what they are going to commit to for the next standup. Most importantly, they are to report impediments, and should not be dragged out by having a sit down meeting off in some conference room. They should take place where you work (next to your workstations). :) Do you have a work board with story cards etc?

That's fantastic that you have such great collaboration with the business. Are they they stakeholders and product owners, or do you have customers that they talk to (i.e. Are they analysts or actually the users etc?)
 
Last edited:
Might be where we where going wrong then, we tended to sit down and once your sat down it's easy to end up stretching things out and talking nonsense :) we're using tfs for workitem tracking but have the tfs sharepoint portal for the spec documents broken down to timebox chunks. There's whiteboard space around for working things out and a larger one the PM's use to show days left, issue counts etc. Right now we're using it to track only the most major of bugs as it's code freeze on Friday for the whole project.

The biz team has a few members, there's a set website manager style role for the 3 main sites which are all customer facing, then there's biz analysts and support. Upstairs is the sales team who we also keep up to date with as they are in contact with managed clients all the time. Depending on the work item either the analysts, site manager or office director will step in as the stakeholder role, really depends on the extent of the new item or change. All big pieces of work are usually signed off at dual director level (biz and tech directors) who are also on the same floor and sit in-amongst us. The structure is pretty open for anyone to help shape or influence what happens, input from all angles is considered but not always needed. It's good though that most people feel like their input is contributing and appreciated.
 
We find a physical board helps, particularly just to let everyone on the team know what the current score is and all anyone has to do is physically look to see what is next up when they are changing task.

If you haven't tried it, and everyone on the team is willing, I heartily recommend using one :)

Are you guys using practices like TDD? What about pair programming?

Just to add it sounds like you have a wonderful environment to work in :)
 
Last edited:
Will do, I think we'll have catchups once the site is out to talk about what was successful and what still needs work, I think the overall process is a living work in progress :D
 
You must log in or register to reply here.
Back
Top Bottom