Any design that is hard to test is crap. Pure crap. Why? Because if it’s hard to test, you aren’t going to test it well enough. And if you don’t test it well enough, it’s not going to work when you need it to work. And if it doesn’t work when you need it to work the design is crap.
When the author refers to designing:
You have to DESIGN period. No matter what you are writing; whether a unit test, or an acceptance test, or production code, or a mock, or a stub, you have to DESIGN.
Because you want to ensure that you always pass the majority of tests, you tend to think about this when you change and extend the program. You therefore are more reluctant to make large-scale changes that will lead to the failure of lots of tests. Psychologically, you become conservative to avoid breaking lots of tests.
I see this happening in AGILE teams. Teams dead scared to change anything because they risk that they fail the sprint. And good developers are held back to change too much because it might break something. So months later the software is in a worse crap than before.
The failure in unit testing as the SCRUM is relying on is, that you get a false sense of security/ Below the hood you may have 2 errors compensating each other and you don't realize it. Developers never do any effort to understand the code what is behind the tests. They just blindly assume that the test works perfectly and is to be trusted. However to get to the sprint deadline developers could disable the unit test, they will fix it after the demo. But they forget.
The idea of TDD is modeled on good developers as AGILE, however it gets abstracted to the extreme in such a way that even the developers they modeled it on will fail. Good developer invent new wheels and design patterns depending on their needs. They say f*ck you to imposed design patterns and design rules.
Everything you described is all about the people, not the process. The process can't hurt anyone, it can't fire anyone, it can't yell at anyone.
Just because someone can break a design guide doesn't mean they should. I've seen people who didn't care at all about design guides and it was a nothing but a tangled mess. Code that was so convoluted because no one stopped to think things through. Once I point out something to them about how their process could be so much more simple and linear, all I get is a soft "oh, well I guess that could work".
I'd also like to point out that the article didn't talk about Agile or Scrum, it only talked about TDD.
Everything you described is all about the people, not the process. The process can't hurt anyone, it can't fire anyone, it can't yell at anyone.
But the process can suck big. Do you know that "The process" has brought my productivity to 10%? Not only did it kill my productivity I am forced to deliver buggy code because of "The process"
I've seen people who didn't care at all about design guides and it was a nothing but a tangled mess.
I have seen more code that did follow the design guides that are completely unusable. I can remove 75% of most programs that are following the design guide and I guarantee you that they will work faster, near bug free, easily deployable, easy modifiable, easy documentable, easy testable and on top of it all "user friendly".
And on top of that, I probably do it in half the time your developers would take, guaranteed success, and developers fresh from school can easily understand the code, modify it and take over.
That's great that you feel that way, it doesn't mean much to me because I'm not, nor do I want to be, filled in on the context of your situation. My response was simply trying to point out that it can go both ways. Processes/methodologies can help or they can hurt, I won't argue that point. The point of the article I linked that I felt was relevant to most any situation in programming is the idea that it is imperative to think through the code before writing it. That's it. A sign that code wasn't thought through or written well is when the excuse of "it's too complicated to test" is used.
5 comments
1 u/captbrogers [OP] 22 Mar 2017 19:57
One part of the article that I felt was poignant:
When the author refers to designing:
0 u/roznak 22 Mar 2017 22:19
I see this happening in AGILE teams. Teams dead scared to change anything because they risk that they fail the sprint. And good developers are held back to change too much because it might break something. So months later the software is in a worse crap than before.
The failure in unit testing as the SCRUM is relying on is, that you get a false sense of security/ Below the hood you may have 2 errors compensating each other and you don't realize it. Developers never do any effort to understand the code what is behind the tests. They just blindly assume that the test works perfectly and is to be trusted. However to get to the sprint deadline developers could disable the unit test, they will fix it after the demo. But they forget.
The idea of TDD is modeled on good developers as AGILE, however it gets abstracted to the extreme in such a way that even the developers they modeled it on will fail. Good developer invent new wheels and design patterns depending on their needs. They say f*ck you to imposed design patterns and design rules.
0 u/captbrogers [OP] 23 Mar 2017 00:55
Everything you described is all about the people, not the process. The process can't hurt anyone, it can't fire anyone, it can't yell at anyone.
Just because someone can break a design guide doesn't mean they should. I've seen people who didn't care at all about design guides and it was a nothing but a tangled mess. Code that was so convoluted because no one stopped to think things through. Once I point out something to them about how their process could be so much more simple and linear, all I get is a soft "oh, well I guess that could work".
I'd also like to point out that the article didn't talk about Agile or Scrum, it only talked about TDD.
0 u/roznak 23 Mar 2017 18:01
But the process can suck big. Do you know that "The process" has brought my productivity to 10%? Not only did it kill my productivity I am forced to deliver buggy code because of "The process"
I have seen more code that did follow the design guides that are completely unusable. I can remove 75% of most programs that are following the design guide and I guarantee you that they will work faster, near bug free, easily deployable, easy modifiable, easy documentable, easy testable and on top of it all "user friendly".
And on top of that, I probably do it in half the time your developers would take, guaranteed success, and developers fresh from school can easily understand the code, modify it and take over.
0 u/captbrogers [OP] 23 Mar 2017 18:28
That's great that you feel that way, it doesn't mean much to me because I'm not, nor do I want to be, filled in on the context of your situation. My response was simply trying to point out that it can go both ways. Processes/methodologies can help or they can hurt, I won't argue that point. The point of the article I linked that I felt was relevant to most any situation in programming is the idea that it is imperative to think through the code before writing it. That's it. A sign that code wasn't thought through or written well is when the excuse of "it's too complicated to test" is used.