7 ms·

I've heard these change to design tradeoffs that occur to increase testability, test induced design damage. Enterprise craftsman I believe

sidlls 10y ago
This sort of rigid adherence to a particular paradigm isn't restricted to enterprise developers. I've seen this sort of thing in practice (or attempted) from colleagues in data pipelines for machine learning and other very much not-enterprise settings.
- adrianratnapala 10y ago
  I find such religious devotion rules common among scientists who have to code even though they are not programmers by trade. Religious overcommenting etc. Whatever rule they happened to read in their FORTRAN-for-beginners book. ML people are probably more knowledgeable, but their job is also often more like science than traditional software engineering.
  - sidlls 10y ago
    That doesn't match my experience (as a former academic scientist who moved into software development). The governing rule for us was always "publish or perish." Programming was a means (exploring a problem) to an end (advancing knowledge and publishing the results). I, at least, never came across the jargon for testing, maintenance, etc. until I moved out of academia and into this industry.
    - adrianratnapala 10y ago
      Oh I agree, scientists are far less inundated by software "best practices" than professionals. It's just that those which they have heard of, they often stick to religiously. Personally I prefer the results of these scientists to much of what I see from real software engineers. It might be wreck, but it is only 1000 lines of wreck -- and not a sophisticated wreck created with powerful modern tools.
theptip 10y ago
Here's a retort to that argument from the source (Uncle Bob): http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Architecture.html http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Ar... DHH wrote an article with the title "test induced design damage", not sure if he coined the term. I think there's a grain of truth there; it is possible, but not necessary, to mangle your architecture to enable testability. The case that DHH was complaining about is quite interesting in itself; it was an architecture that Weirich suggested (https://www.youtube.com/watch?v=tg5RFeSfBM4 https://www.youtube.com/watch?v=tg5RFeSfBM4) where the framework DB models (in his case Rails) are separated from the Domain Models, to allow you to 1) run your tests of the business logic faster (without spinning up a DB) and 2) decouple your business logic from your choice of framework. I've felt the need for this factoring in my own code, but actually making it happen is tricky, since you lose a lot of the magic that makes your life easier (but that also couples every level of your architecture to the framework's concepts).

sidlls 10y ago

This sort of rigid adherence to a particular paradigm isn't restricted to enterprise developers. I've seen this sort of thing in practice (or attempted) from colleagues in data pipelines for machine learning and other very much not-enterprise settings.

adrianratnapala 10y ago
I find such religious devotion rules common among scientists who have to code even though they are not programmers by trade. Religious overcommenting etc. Whatever rule they happened to read in their FORTRAN-for-beginners book. ML people are probably more knowledgeable, but their job is also often more like science than traditional software engineering.
- sidlls 10y ago
  That doesn't match my experience (as a former academic scientist who moved into software development). The governing rule for us was always "publish or perish." Programming was a means (exploring a problem) to an end (advancing knowledge and publishing the results). I, at least, never came across the jargon for testing, maintenance, etc. until I moved out of academia and into this industry.
  - adrianratnapala 10y ago
    Oh I agree, scientists are far less inundated by software "best practices" than professionals. It's just that those which they have heard of, they often stick to religiously. Personally I prefer the results of these scientists to much of what I see from real software engineers. It might be wreck, but it is only 1000 lines of wreck -- and not a sophisticated wreck created with powerful modern tools.

theptip 10y ago

Here's a retort to that argument from the source (Uncle Bob): http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Architecture.html http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Ar... DHH wrote an article with the title "test induced design damage", not sure if he coined the term. I think there's a grain of truth there; it is possible, but not necessary, to mangle your architecture to enable testability. The case that DHH was complaining about is quite interesting in itself; it was an architecture that Weirich suggested (https://www.youtube.com/watch?v=tg5RFeSfBM4 https://www.youtube.com/watch?v=tg5RFeSfBM4) where the framework DB models (in his case Rails) are separated from the Domain Models, to allow you to 1) run your tests of the business logic faster (without spinning up a DB) and 2) decouple your business logic from your choice of framework. I've felt the need for this factoring in my own code, but actually making it happen is tricky, since you lose a lot of the magic that makes your life easier (but that also couples every level of your architecture to the framework's concepts).