I am functioning as an Iteration Manager in my current project. This is a role that is rather undefined as far as I am aware. Certainly me and my IM colleagues are still trying to figure out how best to help the team in our current role. I approach it as something between Agile Coach and Team Lead. Anyway over drinks the other evening I was cautioned not to get in the developers way by trying to help deliver stories through pairing with developers since I now have other duties. This is not the first time I received this advice and I understand the position. Curiously I have always received it from excellent technical people who operate squarely on the technical side of the team. At the same time I find suggestions in the air that I should be learning what a Project Manager does now, or I am on the track to Project Manager, or that I am now Post-Technical.
But, of course, I have a problem with this thinking. The incongruency between the ideas above and how I see things is that I am not an IM. I do an IM’s job or I operate in an IM role, or (if I can totally geek out for a sec) I can be accessed through an IM interface. But the important thing is that I can also be accessed through a Developer Interface. I could write automated tests, run a test script and help a team develop a testing strategy, and could therefore be accessed through a QA interface. I even flatter myself to think that I can write a story, create a rapport with the business and function as a BA. So sitting with a Developer for a couple of hours to work on a Story card is not a risky concept as I see it, so long as I am responsible and don’t let my IM responsibilities keep me and my pair from concentrating on the dev task at hand.
So that was the bit about me and my problems.
I don’t think I am special in some way that allows me to function in multiple roles. But I do think plenty of people and HR departments are happy to confuse person and role. Imagine for a second how much better a developer could provide business value or operate as part of a cross discipline team if he had spent six months working as a BA at some time in the past. I think the gains could be significant to team productivity. I also think the cost of this training need not be too high. On the teams I usually operate in at ThoughtWorks a developer and BA are already expected to work quite closely during the course of an iteration, therefore there is an appreciation of the specifics of their job already. To walk a few miles in their shoes could be a great way to further forge teams into business value machines. Of course BA and Developer switching is standing in for role switching in general. There are deep areas of a discipline that won’t be picked up by a six month stint, but the suggestion is not that we can all be an expert at everything only that we can operate in a given role when necessary and better understand the perspective of other roles.
So what would be so bad about switching roles for awhile?
Thursday, 22 March 2007
Monday, 19 March 2007
Are you doing DDD? or Do you think or hope you are doing DDD? or What is DDD?
Though it has died down a bit now there has recently been a fair amount of talk about dogmatism and Agile. Though I did not see anyone mention the irony of dogmatic agilists, it is an amusing concept. Anyway the only way I can envision considering yourself agile but being dogmatic is to not really understand what Agile is about. Well I have seen a similar phenomena with DDD(Domain Driven Design). It used to be most people who understood the words Domain Driven Design would respond to the topic with “yeah, I need to read that book”. Now, in my small world, many people say “yeah, we do that here”, or “we strive for ubiquitous language”. However, I have actually never spoken with anyone on a project with me who has read the book when the topic first comes up, and I am only aware of one colleague who has read it after we began discussing it (good on ya mate).
I have heard it said that the book is long and difficult (i.e. boring). Personally, I find Eric’s DDD book(http://domaindrivendesign.org/books/) kind of like the Lord of the Rings of software books, in terms of readability. I have read it 2 ½ times since it came out 4 years ago, versus 10-15 times for LotR since I was 12. I find it compelling and full of examples that I can translate into real world situations I have come across, that part is not similar to LotR.
In many projects I have been involved with, I have seen some level of recognition of the benefits to be had from DDD, and a desire to do DDD. But these same projects happily trod over the fundamental idea of ubiquitous language. In speech we try to use the same words, but in code divergence from the language is immediate and continues. The nouns may remain but the verbs and constraints get removed from the domain. In addition new nouns and verbs crop up in the domain code that are not translatable to the business domain or in violation of the business domain. Examples would include code with setters for Database Ids on domain objects or account objects that have setters on the account owner, when the business would not allow an account to change owners. These are examples of letting your domain do things that the business does not do, or extra things that have nothing to do with the business. On the other hand many other “domain” objects have no behavior, maybe the occasional validation method, or an equals override, but absolutely lacking in many fundamental domain concepts. If you have to give your domain object to a ValidationHelper to tell you if a “domain” object is in an appropriate state, yet the business rules of validation are dependent on the state of the domain object then your code does not use ubiquitous language. If you need to give an account to a PerformanceCalculator to tell you its performance over time, yet performance is a property of an account in the business domain, then your code does not use a ubiquitous language. If a “domain” object exposes information about a Database Id, or allows you to change (business) immutable properties because your persistence framework requires setters then your code does not use a ubiquitous language. Of course it may not be bad that your code deviates from ubiquitous language, but you should be aware of the fact and be able to justify it.
If you can’t justify it then you can fix it. My recommended way is to make sure you have read the book and start wrapping your behaviour in interfaces that are business readable(prerequisite is favoring a rich domain over an anaemic one). I would suggest that a good way to judge how ubiquitous your language is is to see how much sense your code makes to a business person. On that note, JBehave has recently been released, which looks to be an excellent tool to get the language of the business into your code. JBehave is about writing tests(behaviours, for BDDists) in the language of the business, but I believe it will lead the whole team to think more in the language of the business domain and that must lead to more domain code being readable in the business language. Of course you may decide that DDD is not for you and your team. But if you don’t read the book then you can’t really know. So my advice is read the book. Even if you don’t like the ideas it will give you a perspective on how developers can make the code easier to understand in the terms of the business.
I have heard it said that the book is long and difficult (i.e. boring). Personally, I find Eric’s DDD book(http://domaindrivendesign.org/books/) kind of like the Lord of the Rings of software books, in terms of readability. I have read it 2 ½ times since it came out 4 years ago, versus 10-15 times for LotR since I was 12. I find it compelling and full of examples that I can translate into real world situations I have come across, that part is not similar to LotR.
In many projects I have been involved with, I have seen some level of recognition of the benefits to be had from DDD, and a desire to do DDD. But these same projects happily trod over the fundamental idea of ubiquitous language. In speech we try to use the same words, but in code divergence from the language is immediate and continues. The nouns may remain but the verbs and constraints get removed from the domain. In addition new nouns and verbs crop up in the domain code that are not translatable to the business domain or in violation of the business domain. Examples would include code with setters for Database Ids on domain objects or account objects that have setters on the account owner, when the business would not allow an account to change owners. These are examples of letting your domain do things that the business does not do, or extra things that have nothing to do with the business. On the other hand many other “domain” objects have no behavior, maybe the occasional validation method, or an equals override, but absolutely lacking in many fundamental domain concepts. If you have to give your domain object to a ValidationHelper to tell you if a “domain” object is in an appropriate state, yet the business rules of validation are dependent on the state of the domain object then your code does not use ubiquitous language. If you need to give an account to a PerformanceCalculator to tell you its performance over time, yet performance is a property of an account in the business domain, then your code does not use a ubiquitous language. If a “domain” object exposes information about a Database Id, or allows you to change (business) immutable properties because your persistence framework requires setters then your code does not use a ubiquitous language. Of course it may not be bad that your code deviates from ubiquitous language, but you should be aware of the fact and be able to justify it.
If you can’t justify it then you can fix it. My recommended way is to make sure you have read the book and start wrapping your behaviour in interfaces that are business readable(prerequisite is favoring a rich domain over an anaemic one). I would suggest that a good way to judge how ubiquitous your language is is to see how much sense your code makes to a business person. On that note, JBehave has recently been released, which looks to be an excellent tool to get the language of the business into your code. JBehave is about writing tests(behaviours, for BDDists) in the language of the business, but I believe it will lead the whole team to think more in the language of the business domain and that must lead to more domain code being readable in the business language. Of course you may decide that DDD is not for you and your team. But if you don’t read the book then you can’t really know. So my advice is read the book. Even if you don’t like the ideas it will give you a perspective on how developers can make the code easier to understand in the terms of the business.
Subscribe to:
Posts (Atom)