Consutlant, coach, guide in all things agile at Allan Kelly Associates
Allan started his career as a coder, one day he realised the code wasn't the challenge: it was the way companies were set up and run. So he began a new journey, to help the coder he was. Today he specialises in better ways of working through agile approaches and OKRs. He partners with growing technology focused businesses to enhance effectiveness and predictability through improved organization, product focus, and delivery. He has written several books including the best selling "Succeeding with OKRs in Agile" and "The Art of Agile Product Ownership". He most proud of the badly named "Business Patterns for Software Developers".
Stats
Reputation: | 1670 |
Pageviews: | 1.3M |
Articles: | 11 |
Comments: | 36 |
Comments
Feb 21, 2014 · Tony Thomas
Thanks Jeff, that story is most illuminating.
One thing that intrigues me is: what was the bug count like?
Both overall and from the different developers, did the one who practices TDD religiously have a significantly different number is issues to those who didn't?
You said the TDD'ed code was slower to write, I would argue that while code may well be slower to write initially it will be faster to complete, i.e. clear testing and need less rework, and this will save time and money when it is deployed. Again it would be good to know more about this case.
What I take from the story is this: even those who practices it less often knew how to do it, they made a (hopefully) informed choice of when to do it and when not.
To me, this is what we want: there may well be occasions when it makes sense to not do things test first but that decision can only be informed when those doing the work understand the options and are capable of proceeding by either route.
My objection is when developers say: "This code can't/shouldn't be done test first" without really understanding what is involved.
Feb 21, 2014 · Tony Thomas
Thanks Jeff, that story is most illuminating.
One thing that intrigues me is: what was the bug count like?
Both overall and from the different developers, did the one who practices TDD religiously have a significantly different number is issues to those who didn't?
You said the TDD'ed code was slower to write, I would argue that while code may well be slower to write initially it will be faster to complete, i.e. clear testing and need less rework, and this will save time and money when it is deployed. Again it would be good to know more about this case.
What I take from the story is this: even those who practices it less often knew how to do it, they made a (hopefully) informed choice of when to do it and when not.
To me, this is what we want: there may well be occasions when it makes sense to not do things test first but that decision can only be informed when those doing the work understand the options and are capable of proceeding by either route.
My objection is when developers say: "This code can't/shouldn't be done test first" without really understanding what is involved.
Feb 21, 2014 · Tony Thomas
Thanks Jeff, that story is most illuminating.
One thing that intrigues me is: what was the bug count like?
Both overall and from the different developers, did the one who practices TDD religiously have a significantly different number is issues to those who didn't?
You said the TDD'ed code was slower to write, I would argue that while code may well be slower to write initially it will be faster to complete, i.e. clear testing and need less rework, and this will save time and money when it is deployed. Again it would be good to know more about this case.
What I take from the story is this: even those who practices it less often knew how to do it, they made a (hopefully) informed choice of when to do it and when not.
To me, this is what we want: there may well be occasions when it makes sense to not do things test first but that decision can only be informed when those doing the work understand the options and are capable of proceeding by either route.
My objection is when developers say: "This code can't/shouldn't be done test first" without really understanding what is involved.
Feb 21, 2014 · Tony Thomas
Thanks Jeff, that story is most illuminating.
One thing that intrigues me is: what was the bug count like?
Both overall and from the different developers, did the one who practices TDD religiously have a significantly different number is issues to those who didn't?
You said the TDD'ed code was slower to write, I would argue that while code may well be slower to write initially it will be faster to complete, i.e. clear testing and need less rework, and this will save time and money when it is deployed. Again it would be good to know more about this case.
What I take from the story is this: even those who practices it less often knew how to do it, they made a (hopefully) informed choice of when to do it and when not.
To me, this is what we want: there may well be occasions when it makes sense to not do things test first but that decision can only be informed when those doing the work understand the options and are capable of proceeding by either route.
My objection is when developers say: "This code can't/shouldn't be done test first" without really understanding what is involved.
Feb 21, 2014 · Allen Coin
Thanks Jeff, that story is most illuminating.
One thing that intrigues me is: what was the bug count like?
Both overall and from the different developers, did the one who practices TDD religiously have a significantly different number is issues to those who didn't?
You said the TDD'ed code was slower to write, I would argue that while code may well be slower to write initially it will be faster to complete, i.e. clear testing and need less rework, and this will save time and money when it is deployed. Again it would be good to know more about this case.
What I take from the story is this: even those who practices it less often knew how to do it, they made a (hopefully) informed choice of when to do it and when not.
To me, this is what we want: there may well be occasions when it makes sense to not do things test first but that decision can only be informed when those doing the work understand the options and are capable of proceeding by either route.
My objection is when developers say: "This code can't/shouldn't be done test first" without really understanding what is involved.
Feb 21, 2014 · Allen Coin
Thanks Jeff, that story is most illuminating.
One thing that intrigues me is: what was the bug count like?
Both overall and from the different developers, did the one who practices TDD religiously have a significantly different number is issues to those who didn't?
You said the TDD'ed code was slower to write, I would argue that while code may well be slower to write initially it will be faster to complete, i.e. clear testing and need less rework, and this will save time and money when it is deployed. Again it would be good to know more about this case.
What I take from the story is this: even those who practices it less often knew how to do it, they made a (hopefully) informed choice of when to do it and when not.
To me, this is what we want: there may well be occasions when it makes sense to not do things test first but that decision can only be informed when those doing the work understand the options and are capable of proceeding by either route.
My objection is when developers say: "This code can't/shouldn't be done test first" without really understanding what is involved.
Feb 21, 2014 · Allen Coin
Thanks Jeff, that story is most illuminating.
One thing that intrigues me is: what was the bug count like?
Both overall and from the different developers, did the one who practices TDD religiously have a significantly different number is issues to those who didn't?
You said the TDD'ed code was slower to write, I would argue that while code may well be slower to write initially it will be faster to complete, i.e. clear testing and need less rework, and this will save time and money when it is deployed. Again it would be good to know more about this case.
What I take from the story is this: even those who practices it less often knew how to do it, they made a (hopefully) informed choice of when to do it and when not.
To me, this is what we want: there may well be occasions when it makes sense to not do things test first but that decision can only be informed when those doing the work understand the options and are capable of proceeding by either route.
My objection is when developers say: "This code can't/shouldn't be done test first" without really understanding what is involved.
Feb 21, 2014 · Allen Coin
Thanks Jeff, that story is most illuminating.
One thing that intrigues me is: what was the bug count like?
Both overall and from the different developers, did the one who practices TDD religiously have a significantly different number is issues to those who didn't?
You said the TDD'ed code was slower to write, I would argue that while code may well be slower to write initially it will be faster to complete, i.e. clear testing and need less rework, and this will save time and money when it is deployed. Again it would be good to know more about this case.
What I take from the story is this: even those who practices it less often knew how to do it, they made a (hopefully) informed choice of when to do it and when not.
To me, this is what we want: there may well be occasions when it makes sense to not do things test first but that decision can only be informed when those doing the work understand the options and are capable of proceeding by either route.
My objection is when developers say: "This code can't/shouldn't be done test first" without really understanding what is involved.
Jan 30, 2014 · Tony Thomas
Good points. (A reply to Dave Beck).
You bring us back to the "people or the system" argument. I have heard many people say "its the people" and I agree with them, and I've read Deming and he say "its 98% the system" and I agree with him. I think the whole industry is stuck in this double-think.
Let me suggest that the best programmers gravitate towards TDD, OK, its my opinion, but all the programmers I respect practice it. It may be that doing TDD is a filter. Or it may be that the best people conclude that it is effective.
Unraveling cause and effect here is beyond me.
Jan 30, 2014 · Allen Coin
Good points. (A reply to Dave Beck).
You bring us back to the "people or the system" argument. I have heard many people say "its the people" and I agree with them, and I've read Deming and he say "its 98% the system" and I agree with him. I think the whole industry is stuck in this double-think.
Let me suggest that the best programmers gravitate towards TDD, OK, its my opinion, but all the programmers I respect practice it. It may be that doing TDD is a filter. Or it may be that the best people conclude that it is effective.
Unraveling cause and effect here is beyond me.
Jan 19, 2014 · Tony Thomas
Thanks Darryl,
I couldn't have said it better myself!
I think you've put your finger on something here, something I'll have to follow up in a later blog. In my experience, when presented with a coherent argument most managers get it. As I said, this deserves more discussion, another blog
allan
Jan 19, 2014 · Tony Thomas
Thanks Darryl,
I couldn't have said it better myself!
I think you've put your finger on something here, something I'll have to follow up in a later blog. In my experience, when presented with a coherent argument most managers get it. As I said, this deserves more discussion, another blog
allan
Jan 19, 2014 · Allen Coin
Thanks Darryl,
I couldn't have said it better myself!
I think you've put your finger on something here, something I'll have to follow up in a later blog. In my experience, when presented with a coherent argument most managers get it. As I said, this deserves more discussion, another blog
allan
Jan 19, 2014 · Allen Coin
Thanks Darryl,
I couldn't have said it better myself!
I think you've put your finger on something here, something I'll have to follow up in a later blog. In my experience, when presented with a coherent argument most managers get it. As I said, this deserves more discussion, another blog
allan
Jan 15, 2014 · Tony Thomas
Burabari, doing TDD is improving your coders.
TDD - and no other method I know of - guarantee's software will be bug free but all the evidence I have tells me it reduces - sometimes vastly reduces - the number of bugs that are there.
If not TDD then what?
Manual Unit tests?
If not manual unit tests then what?
Static analysis tools, code reviews and similar are good but you can use all these techniques, they are not exclusive.
Jan 15, 2014 · Tony Thomas
Burabari, doing TDD is improving your coders.
TDD - and no other method I know of - guarantee's software will be bug free but all the evidence I have tells me it reduces - sometimes vastly reduces - the number of bugs that are there.
If not TDD then what?
Manual Unit tests?
If not manual unit tests then what?
Static analysis tools, code reviews and similar are good but you can use all these techniques, they are not exclusive.
Jan 15, 2014 · Allen Coin
Burabari, doing TDD is improving your coders.
TDD - and no other method I know of - guarantee's software will be bug free but all the evidence I have tells me it reduces - sometimes vastly reduces - the number of bugs that are there.
If not TDD then what?
Manual Unit tests?
If not manual unit tests then what?
Static analysis tools, code reviews and similar are good but you can use all these techniques, they are not exclusive.
Jan 15, 2014 · Allen Coin
Burabari, doing TDD is improving your coders.
TDD - and no other method I know of - guarantee's software will be bug free but all the evidence I have tells me it reduces - sometimes vastly reduces - the number of bugs that are there.
If not TDD then what?
Manual Unit tests?
If not manual unit tests then what?
Static analysis tools, code reviews and similar are good but you can use all these techniques, they are not exclusive.
Jan 15, 2014 · Tony Thomas
Steven,
Thanks for your comment. What you describe is exactly what I believe. Its good to have someone else describe it from direct experience.
I probably over did it in my comments on manual testing, I believe there will always be an element of manual testing - exactly as you say after the automated tests. But I so rarely see true exploratory testing, usually it is manual testing in the absence of any automation.
allan
Jan 15, 2014 · Tony Thomas
Steven,
Thanks for your comment. What you describe is exactly what I believe. Its good to have someone else describe it from direct experience.
I probably over did it in my comments on manual testing, I believe there will always be an element of manual testing - exactly as you say after the automated tests. But I so rarely see true exploratory testing, usually it is manual testing in the absence of any automation.
allan
Jan 15, 2014 · Allen Coin
Steven,
Thanks for your comment. What you describe is exactly what I believe. Its good to have someone else describe it from direct experience.
I probably over did it in my comments on manual testing, I believe there will always be an element of manual testing - exactly as you say after the automated tests. But I so rarely see true exploratory testing, usually it is manual testing in the absence of any automation.
allan
Jan 15, 2014 · Allen Coin
Steven,
Thanks for your comment. What you describe is exactly what I believe. Its good to have someone else describe it from direct experience.
I probably over did it in my comments on manual testing, I believe there will always be an element of manual testing - exactly as you say after the automated tests. But I so rarely see true exploratory testing, usually it is manual testing in the absence of any automation.
allan
Jan 14, 2014 · Allen Coin
:)
Jan 14, 2014 · Tony Thomas
:)
Jan 10, 2014 · Allen Coin
Thanks for that Jarek,
Interesting to note that in the Twitter stream about this article (no hashtag, you'll have to look at @allankellynet and the interactions) many area expressing pessimism that this will come to pass by 2022. But from what you, and a few other people say, this is already the norm in many many places.
Jan 10, 2014 · Tony Thomas
Thanks for that Jarek,
Interesting to note that in the Twitter stream about this article (no hashtag, you'll have to look at @allankellynet and the interactions) many area expressing pessimism that this will come to pass by 2022. But from what you, and a few other people say, this is already the norm in many many places.
Jan 09, 2014 · Allen Coin
Thanks for pointing that out Barry, it a while since I (re)read MMM.
A reasonable observation - one I hope is wrong.
In 1974 processor cycles were expensive and few people had easy access to machines. Brooks could see the benefits but the argument didn't catch. Hopefully now CPU cycles are dirt cheap and we all have as much power in our pocket as he had in a room automated testing has more chance.
I sometimes wonder if the while "agile" movement is about correcting a wrong turning the industry took somewhere about 1980.
Jan 09, 2014 · Tony Thomas
Thanks for pointing that out Barry, it a while since I (re)read MMM.
A reasonable observation - one I hope is wrong.
In 1974 processor cycles were expensive and few people had easy access to machines. Brooks could see the benefits but the argument didn't catch. Hopefully now CPU cycles are dirt cheap and we all have as much power in our pocket as he had in a room automated testing has more chance.
I sometimes wonder if the while "agile" movement is about correcting a wrong turning the industry took somewhere about 1980.
Jun 09, 2013 · Tony Thomas
Wow, sounds like Lego have something of the Disney about them!
Apr 03, 2013 · Taylor Gautier
Exactly! Great example
And god help us, literally, if anyone decides to refactor or rewrite DNA without a damn good set is tests!
Feb 21, 2013 · Tony Thomas
Florin,
Thanks for the comments, I think there is much to what you say. Particularly about complexity, I don't know who made the comments originally but they are repeated and re-invented in many forms. The enemy is complexity.
Big Ball of Mud is a very deep pattern, and its even debatable how far you can prevent it, or even if you want to. My (<a href="http://www.allankelly.net/patterns/encapsulatedcontext.html">Encapsulated Context pattern http://www.allankelly.net/patterns/encapsulatedcontext.html</a>) had something to say about that. (Continue the argument far enough and it becomes Dick Gabriel's "Worse if Better" discussion.)
Back to SOA. I think most of what you say applies to large system and modularization/decoupling in general. SOA is just the latest, and perhaps largest, tool to be through at this issue.
While I am sure that for you, and many other programmers, SOA - and web APIs in general - are really about decoupling I don't think that is how the debate plays out at the highest level. I don't think CIO and CFOs sign-off on multi-million dollar efforts to decouple their systems. I think they do sign-off on multi-million dollar efforts to reuse services and expose mainframe to the web.
And that is exactly where I see the problem. First you have mixed understanding of what SOA is for (programmers see it as decoupling, those paying the bills see something else.) Second I don't think spending millions and millions of dollars on will pay back, specifically in re-use terms.
As per the other comments: I stand my ground when we are talking about bolting on SOA, retro-fitting it to an existing system.
When its a case of building a system from the ground up with exposed APIs, whether we call it SOA, web services, or whatever, the case is more complex and may make commercial sense.
Feb 20, 2013 · Tony Thomas
I've also been told about an example at Amazon
http://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/
Although I immediately have reservations about any strategy that puts a gun to people's head: do it or be fired.
I think your onto something about the not bolting it on afterwards, build it with hooks, services, APIs, call it what you will.
Second, a common theme, maybe, from Netflix and Amazon may be that it was wide: many teams, if not all, did this. The SOA I've seen is a team sat in the corner and tasked with coming up with services for others.
Feb 19, 2013 · Tony Thomas
Jurgen,
Your reply doesn't seem to address any of the points raised in my piece. Rather it reads like a regurgitation of the usual arguments for SOA.
You mention BPM but I prefer the original name: BPR, lets be honest, Business Process Reengineering was an utter disaster. If you are saying SOA supports BPM/BPR I'll add that to my list of reason NOT to adopt SOA.
Feb 19, 2013 · Tony Thomas
Jurgen,
Your reply doesn't seem to address any of the points raised in my piece. Rather it reads like a regurgitation of the usual arguments for SOA.
You mention BPM but I prefer the original name: BPR, lets be honest, Business Process Reengineering was an utter disaster. If you are saying SOA supports BPM/BPR I'll add that to my list of reason NOT to adopt SOA.
Feb 19, 2013 · Tony Thomas
Mark,
Thanks for your comments. Do you have a link to something about the Netflix SOA you say is right?
I'll agree SOA is not all about reuse, however it is often presented as that - especially to developers and probably to the business too. Perhaps the first thing to get straight when you look at SOA is: Why? - what are you hoping to achieve?
The SOA initiatives I have seen are bolting on after exercises. In particular: bolting the mainframe to the web. I've actually started to wonder if really SOA is a cover story for just this.
As for maintenance: if you have separate teams they can at least handle issues themselves. When you link teams together you need to coordinate these fixes. At that point dis-economies of scale really cut in.
Jun 07, 2010 · Tony Thomas
Thanks for your comment, can I reply in reverse order?
I whole heartedly agree with your final point. There are many different types of projects, many different type of developers and many different ways to fail. When you look at projects that work certain common patterns and practices emerge. As Tolstoy wrote "All happy families are happy in the same happy way, all unhappy families are unhappy in ther own unique way."
The greatest mistake is to blindly follow anything to the extreme without questioning it and asking "Does it apply to me?". For that reason I often talk about Agile as a set of tools in a toolbox and you select the ones that apply.
This piece, from the picture on, is a discussion of things you could do to improve your code quality. This is a list of tools: pick some. Its not a comprehensive list, I ask for more suggestions, nor is it a mandatory list, its a list for you to pick from.
As to pair programming I do not believe it doubles cost at all. On the contary, I find that pair programming enables deep thougt because it provides someone equallly dedicated to share the thinking. True, if two developers are not compatible there will be problems, but, there will be problems if two incompatible programmers are working on the same project anyway. Pair programming will simply highlight the problem sooner.
As to TDD assuming the design is 100% complete before you start coding nothing could be further from the truth. Not only does TDD not assume this but it greatly assists in helping designs to emerge over time. In the long run TDD is an essential completement to refactoring and emergent design.