Concurrent development w/o central design?

Question

I've got a team of developers which are trying to write specifications/tests concurrently for different (and sometimes adjacent) parts of the system.

Typically, the person writing the specification/test is not the developer who will write the implementation and make the specification/test pass.

Here's the problem we're having: the person receiving the specification/test for which an implementation hasn't yet been written isn't familiar enough with the design of the system's many objects to know:

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 specification/test?

Not all of the developers on the project have the domain knowledge to make these decisions well, and we're colliding so far as disparate designs and objects created in relative isolation begin to conflict and duplicate each other.

What is the solution(s) to this problem? Is it simply inescapable that every developer in the project must know (or be prepared to ask) the system's objects?

Feel free to provide what you think are obvious answers.

Answer 1

What domain is the system for? I've made the experience, that all this writing specifications often is overkill. It is often much more helpful to enforce communication + collaboration between the one who has the idea or vision of the software and the one who is implementing it. It is one of the core core agile-values (http://agilemanifesto.org/), working software over documentation (I include specification piles of paper to documentation).

In my view every developer has to understand the domain, for domain newbies this involves investment. A very helpful way is to do pair-programming or to have a mentor who is introducing developers with less understanding to the parts of the system.

Of course there are exceptions of this rule when specification-intense approach is the optimal solution of the problem... It also depends on the size of your system and the team size. So maybe you can give more details on that.

Answer 2

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 specification/test pass.

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 specification/test?

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.)

Answer 3

Sounds like you can save a LOT of money by bringing all the lead developers together for discussing each new specification before implementing.

The most important thing is communication, and if you don't know you cannot use.

Answer 4

This problem is usually resolved by a lead as part of answering developer questions or identifying flaws in a design review.

Another way that I've seen teams solve this problem is to silo their work. People are given silo-ed responsibilities. One primary and maybe one secondary person own a particular area of the system. They are the experts. They get all work in this area. While this can make it easier and be highly productive, it comes with a lot of risks that range from developer availability to a lack of overall system knowledge.