8

I am designing a class library to represent western equal temperament music theory concepts for the purpose of composing notated music with code (I realize there are other libraries and programs for this but I want to design my own). The problem I am having is that when I start with the most fundamental concept (PitchClass) and start building upwards, I very quickly spiral out of control with too much complexity in the design. I end up scrapping it and starting over.

I am thinking about a new approach. Start by writing a program (which will not compile) that demonstrates how I want to use the library in the end. For example write the sample programs that might accompany a library first, as a part of the design process. I am hoping that doing so might help me with lower-level design decisions so that I do not lose myself in design complexity.

This approach is analogous to test driven design, but different in that the sample program is not isolated to a single class or function, but instead demonstrates the interface of many high-level classes.

Question
Is the top-down design methodology I am describing here a valid approach? Does it have a name? I am working alone, but do teams ever use an approach like this?

This does not answer the question because it is specifically about designing a web UI and dealing with browser differences.

This is not relevant because it is about back-end vs front-end specifications.

This is not a duplicate because it is specifically about approaching an MVC stack.

  • 3
    If this approach meets your software's goals for functionality, maintainability and performance, on-time and on-budget, then yes, it is a valid approach. Will it? – Robert Harvey Apr 29 '15 at 21:11
  • 1
    To cross the great ocean, should one sail from east to west, or from west to east? It might not matter, if the ship is not fit for traversing the great ocean. When the software requirements and design is in the great unknown, both top-down and bottom-up design approaches could possibly fail. Fortunately, software development is an iterative process; you can make as many retries as resource permits; and every retry benefits from the insights and partially-working code obtained from earlier attempts. If you insist on one advice, here it is: start from the side which you are more confident with. – rwong Apr 29 '15 at 21:54
  • 1
    Since you are a domain expert (you understand the theory and requirements in the domain of music quite well), the top-down approach, or ATDD (RobertHarvey's answer) is the side which you should be more confident with, therefore it is a good suggestion. – rwong Apr 29 '15 at 21:57
  • 1
    You left out the 3rd option which is to pick a specific Use-Case and get that entire Use-Case working. Top-down/Bottom-up doesn't matter. Pick another Use-Case and repeat, refactor as necessary. Keep repeating until done. This approach may lead to a lot of rework as new functionality is added but you shouldn't need to just throw stuff away and begin again. IMO, the more optimal approach is to identify most all of your use-cases, pick the most architecturally impactful ones, do the design and implementation on those. Then adding later use-cases shouldn't have large refactorings required. – Dunk Apr 30 '15 at 15:32
10

You're describing Acceptance Test-Driven Development.

The basic principle behind ATDD is that each software requirement is accompanied by an acceptance test that, when executed, provides proof that the requirement has been satisfied.

enter image description here

Acceptance tests are created when the requirements are analyzed and prior to coding. They can be developed collaboratively by requirement requester (product owner, business analyst, customer representative, etc.), developer, and tester. Developers implement the system using the acceptance tests. Failing tests provide quick feedback that the requirements are not being met.

The tests are specified in business domain terms. The terms then form a ubiquitous language that is shared between the customers, developers, and testers.

Tests and requirements are interrelated. A requirement that lacks a test may not be implemented properly. A test that does not refer to a requirement is an unneeded test. An acceptance test that is developed after implementation begins represents a new requirement.

I'm personally a big fan of ATDD. Requirements that are not accompanied by an acceptance test are not requirements at all; they're wishes.

| improve this answer | |
  • 1
    Great answer here from Robert Harvey, I agree, you should look into ATDD. I would add one thing, I think it would be worth pointing out the idea in TDD that this kind of issue can often be thought about by taking a single slice, or golden path through the system. Get one small aspect of it working end to end first. User Stories are a single piece of function that adds value, if you can get one of those working then it makes build out sideways a lot easier to reason about. – Encaitar Apr 29 '15 at 22:12
  • I don't really see how this relates to OPs question about a overall top-down or a bottom-up approach in designing the system. Surely ATDD could be used in both cases, where the most intuitive match is with the same bottom-up approach that is common in TDD? Could you clarify? – Alex Apr 30 '15 at 10:59
3

Is the top-down design methodology I am describing here a valid approach? Does it have a name?

Yes, it is called top-down design, and there's a decent Wikipedia article. In particular, you're describing an informal variant where you figure out what you want the library to do and how you want it organized based on how you intend to use it.

do teams ever use an approach like this?

Yes, but the larger the team is, the more formality you need in order to keep everyone working toward the same goals. In the old days, the top-down design was done on paper before the programmers were hired.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.