TDD for dummies !
-
On the project I mentioned, the first warning signs to the team should have been that there were 149 projects in the solution (C#, MVC4) yet all it actually did was show a login form (and even that didn't work properly!) :doh: And when you mention anything you get the usual "you don't understand TDD/DDD", "that's an anti-pattern", "what you're suggesting isn't Agile", etc. (i.e. ways to try and prevent any discussion of the real problems).
Brent Jenkins wrote:
there were 149 projects in the solution (C#, MVC4) yet all it actually did was show a login form
My jaw quite literally dropped open when I read this. I know I'm guilty of gold-plating my code, but the worst I've ever gone on a single application is 9 projects. :doh:
-
On the project I mentioned, the first warning signs to the team should have been that there were 149 projects in the solution (C#, MVC4) yet all it actually did was show a login form (and even that didn't work properly!) :doh: And when you mention anything you get the usual "you don't understand TDD/DDD", "that's an anti-pattern", "what you're suggesting isn't Agile", etc. (i.e. ways to try and prevent any discussion of the real problems).
Brent Jenkins wrote:
the first warning signs to the team should have been that there were 149 projects in the solution
Seems like that would have been more like the 100th warning sign unless all of those projects just showed up all at once in the middle of the night.
Brent Jenkins wrote:
and prevent any discussion of the real problems
Process, any process, that doesn't allow change in response to actual work is guaranteed to fail.
-
Brent Jenkins wrote:
there were 149 projects in the solution (C#, MVC4) yet all it actually did was show a login form
My jaw quite literally dropped open when I read this. I know I'm guilty of gold-plating my code, but the worst I've ever gone on a single application is 9 projects. :doh:
Mine too - when I first opened the solution there were already over 130 projects there. I'd previously seen a solution with 50 projects in another contract - that was too many as well, but they had accumulated over a few years and it did actually (mostly) do what it was supposed to. Most solutions I come across seem to have between 10 and 15 projects including test projects. I'd say once 20 project is reached, red warning lights should be flashing. Not that it's necessarily wrong, but at that point it's probably worth considering if a different approach may be more appropriate.
-
Brent Jenkins wrote:
the first warning signs to the team should have been that there were 149 projects in the solution
Seems like that would have been more like the 100th warning sign unless all of those projects just showed up all at once in the middle of the night.
Brent Jenkins wrote:
and prevent any discussion of the real problems
Process, any process, that doesn't allow change in response to actual work is guaranteed to fail.
Agreed, as I mentioned in another post, most solutions I come across tend to be between 10 and 15 projects including test projects. Anything higher than 20 is time to review and reconsider the design. The most ridiculous thing was that Visual Studio struggled (unsurprisingly) to keep running. So brilliant suggestions flowed forth - such as doubling the amount of RAM on each PC, fitting SSD drives, changing the methodology from Agile to Waterfall (why that would help I have no idea?), and finally removing required functionality from the requirements documents because of the difficulties getting anything done because the architecture was extremely brittle and fragile. Anything and everything except dumping the solution and building it properly. Ah well, at least I can laugh about it all now with only a small dose of medication :laugh:
-
TDD as a religion should die. In my previous contract the team (before I joined) followed their own (misguided) interpretation of DDD and TDD. They had an awful lot of passing unit and integration tests (pats on back and a slice of cake for everyone, hoorah! :java:), but the project didn't work properly from the users perspective, it continually missed all it's deadlines and after spending over £1 million on it, the team and the project have been canned (I'd got out before then, it was obvious from the start where the project was heading - I'd raised issues with management, but it all fell on deaf ears). If you're developing a product, it's the product that matters at the end of the day, not the tests. TDD is a nice to have, but it's far from essential.
Brent Jenkins wrote :
TDD as a religion should die
I'm not a follower of TDD as religion. :) When I come to you point. Well I don't blame on TDD. I blame the team who wrongly practicing it. Off course, if anyone who abuse the methodology will eventually fail.Same is true for OOP, Design Patterns so on so forth.
Brent Jenkins wrote :
it's the product that matters at the end of the day, not the tests
Agree, it just a matter of making the best robust product. TDD will contribute it's share and most importantly it's alive. :)
Wonde Tadesse
-
Brent Jenkins wrote :
TDD as a religion should die
I'm not a follower of TDD as religion. :) When I come to you point. Well I don't blame on TDD. I blame the team who wrongly practicing it. Off course, if anyone who abuse the methodology will eventually fail.Same is true for OOP, Design Patterns so on so forth.
Brent Jenkins wrote :
it's the product that matters at the end of the day, not the tests
Agree, it just a matter of making the best robust product. TDD will contribute it's share and most importantly it's alive. :)
Wonde Tadesse
Wonde Tadesse wrote:
I'm not a follower of TDD as religion.
Me neither, but an awful lot of development teams are - you can find yourself being hunted down by the Coding Inquisition[^] (and all their cunning instruments of torture) by not covering one obscure line of code with a unit test.
Wonde Tadesse wrote:
Well I don't blame on TDD. I blame the team who wrongly practicing it.
That's exactly my point! While there a few organisations who have got it right, the vast majority are abusing various methodologies - they just don't realise it. Every place has it's own implementation/interpretation made up to suit themselves. Surely they can't all be right? The "religion" angle is basically a defensive mechanism to prevent anyone questioning why things are being done in a certain (often illogical) way - a bit like the old days of shouting "heretic" at anyone who was deemed a threat.
