Not all of the developers on the project have the domain knowledge to make these decisions well
If some developers lack deep understanding of the system's purpose or customer requirements (knowledge of the customer's domain), then they will take longer time to write, and the code written will require more testing and more rework. This is the typical trial-and-error approach to learning, and is both a cost and an investment.
If some developers did not design the architecture well, then delegate the design work to a better architect. It takes more than domain knowledge to design well, e.g. architecture wisdom, for which some programmers do better than others and which doesn't grow linearly with experience. There are two ways this can work:
- The architect can specify the CRC, and the interface methods, and let other developers implement the details.
- The architect can come in after-the-fact, and oversee the refactoring of the project while the code/spec/tests had already been stabilized.
If you want the software architecture to match nicely with the purpose, well ... switch team, or switch company. DDD usually have a "non-experts need not apply" policy.
Typically, the person writing the
specification/test is not the
developer who will write the
implementation and make the
If one specification/test is too general/vague/huge for the developers to implement ... break them into smaller specifications/tests.
Do I solve this problem (the
specification/test) with an existing
object(s), or do I create (for the
first time) the dependencies which
will allow the system to pass this
In your situation, I suggest embrace rework. Sometimes the answer to the create/reuse question is not obvious. Ask an architect whenever available. If not, flip a coin.
... we're colliding so far as disparate
designs and objects created in
relative isolation begin to conflict
and duplicate each other.
Here is one approach that has worked for me in a smaller project. It is probably not scalable for larger projects.
Each team member begins a day's work by reading all of every other team member's code changes.
(This is suitable for "everyone in one giant big room shared with other teams" settings as it can be done in absolute silence. It is also suitable for geographically dispersed teams as it does not occupy face time. Co-located teams which have dedicated office rooms might find pair programming more suitable.)
(The effort is manageable up to 10 source commits per day or 500 lines of change.)