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.
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).
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).
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.
This has been my project for the past few months, in one form or another. I'm planning on making a video to show just how easy and extensible this system is, as well as launching to a few small companies in the coming weeks. I'd love to answer any questions/take any criticism. Crocker's Rules (but that's a given around here :)
My experience with workflow engines (as a developer) has been ... not great. They are hard to debug, and difficult to code once the logic gets complicated.
First I'll say that I am nowhere near an expert on working with workflow engines. If you wouldn't mind, I'd love to chat with you about your experiences with them.
The main difference is it's an extended state machine, not just a workflow engine.
It's similar in functionality in a few ways, but quite different from a WE in many more ways. A workflow engine has a subset of a state machine's functionality, hid behind a layer of abstraction that complicates things.
These networked extended state machines can be composed and nested, and as such, I think they avoid a lot of the complexities of a WE. I'll be going into more details on all of this in subsequent posts + a video, hopefully soon.
No, building business logic takes years, and even then it is not done because the business needs demand that it be changed yet again. Business logic is never correct. At best it is just good enough for now. This is why established businesses place so much emphasis on change management. They know that change is constant and that they need changes to be carefully managed in order to adapt fast enough, yet not break anything.
I debated using the word "build" in lieu of "implement". Designing building logic is an ongoing process; implementing it is what we're seeking to make easier.
As an extended state machine, it's certainly an interesting concept. I also love that you describe the components of your workflow in JSON, but the logical pieces are I think where this approach struggles.
I mean I get what's going on here, but the syntax clutter drives me nuts.
I agree completely. DEFINITELY something I'm working on; the syntax is not ideal. That's not even quite how it looks anymore (and even that isn't where I want it to be yet), though I didn't have time to switch it out for the post. Additionally, a lot of that will be abstracted away by the GUI (which should actually be a nice way to build these things; stay tuned).
I'd love to chat with you more about this. I don't know if we could benefit since we're not building a business app even though it has a fair amount of business logic planned in the spec.
I've signed up to your mailing list anyhow. (Khuram Malik)
Amazon has a killer offering for this problem in the form of SWF. It's fairly under the radar as they have done a terrible job marketing it, but it's great.
They are going after a similar market, but the key difference (and it's very important in terms of expressiveness) is that they have a workflow engine, but this is a state machine at its core.
thingamy.com have been building and offering a web-based system for supporting what they chose to call "Barely Repeatable (business) Processes" for years, and put a lot of tought into it. Written in Lisp btw.
Right now I have Twilio, Urban Airship, Mailgun, and also arbitrary webhooks. More to come soon. It's actually a technology of Marion Tech, copperthoughts is just the silly name of my blog :)
"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.