3 ms·

I get it, in principle, but in every project I've been in, actually nailing down the business logic itself is the tricky part, more than coding it up. It usuall

I get it, in principle, but in every project I've been in, actually nailing down the business logic itself is the tricky part, more than coding it up. It usually goes like this. "I want it to work like A." code it up, find twenty edge case potentials "Well, 3, 5, 6, and 7 can be solved like this, let's guard to make sure 1, 3, 8, 9 never happen, 10-13 can never happen, and let me get back to you on the rest." code it up, notice a few more edge cases. Lather, rinse, repeat. Along the way, one of the edge cases will show me that what they really want is B, and time and budget let me know if we start down that path.

ericHosick 13y ago
In general, nailing down requirements is a very tricky part of engineering. Having a system/body of knowledge to map requirements to implementation is really important. Specific to software engineering, this process is best supported with BDD and TDD (in my opinion). BDD gets you 100% coverage of behavior: what the "customer" wants. TDD helps you cover edge cases which improves on robustness (which is the process you are describing above). Coding before you have behavior (what customer wants) is, in my opinion, a bad idea (product market fit first). Any type of development approach, ill-relevant of it being coding or visually oriented, is going to be iffy without using best known practices. Now, if you are doing R&D then I would ignore the above process of BDD/TDD with the understanding that any code/program written would be "thrown out" (not put into production).
ihodes 13y ago
Absolutely agree; the business logic is the tough part. That's why it should be easy it iterate and verify it, which is the goal of what we're doing here. The sooner you can get a product out, the sooner you can spot your edge cases and things you didn't think through, and fix them (very quickly).
mathattack 13y ago
Exactly. It's not the logic that's hard, it's the exceptions. If you're not building a new business around the technology, you wind up having to deal with a lot of well-reasoned exceptions and fuzziness that's in people's heads or embedded in hands-on processes.

ericHosick 13y ago

In general, nailing down requirements is a very tricky part of engineering. Having a system/body of knowledge to map requirements to implementation is really important. Specific to software engineering, this process is best supported with BDD and TDD (in my opinion). BDD gets you 100% coverage of behavior: what the "customer" wants. TDD helps you cover edge cases which improves on robustness (which is the process you are describing above). Coding before you have behavior (what customer wants) is, in my opinion, a bad idea (product market fit first). Any type of development approach, ill-relevant of it being coding or visually oriented, is going to be iffy without using best known practices. Now, if you are doing R&D then I would ignore the above process of BDD/TDD with the understanding that any code/program written would be "thrown out" (not put into production).

ihodes 13y ago

Absolutely agree; the business logic is the tough part. That's why it should be easy it iterate and verify it, which is the goal of what we're doing here. The sooner you can get a product out, the sooner you can spot your edge cases and things you didn't think through, and fix them (very quickly).

mathattack 13y ago

Exactly. It's not the logic that's hard, it's the exceptions. If you're not building a new business around the technology, you wind up having to deal with a lot of well-reasoned exceptions and fuzziness that's in people's heads or embedded in hands-on processes.