5 ms·

Build Business Logic in Minutes, Not Weeks

51 points by ihodes 13y ago

ihodes 13y ago
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 :)
tarr11 13y ago
Is this a JSON oriented workflow engine? 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.
- ihodes 13y ago
  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.
  - fieldforceapp 13y ago
    I'm curious why you didn't try UML or SysML instead?
ericHosick 13y ago
What external APIs are working in Copper? Stripe? Twilio? etc.?
- ihodes 13y ago
  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 :)
  - deleted 13y ago
    [deleted]
gfodor 13y ago
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.
- ihodes 13y ago
  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.
  - gfodor 13y ago
    I don't understand. Can you explain? Writing jobs in SWF Flow Framework is an executable state machine.
krmmalik 13y ago
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) Look forward to chatting to you.
- ihodes 13y ago
  Great! I will be in touch very soon, looking forward to chatting.
ppadron 13y ago
Also, NoFlo: http://noflojs.org/ http://noflojs.org/.
- nathancahill 13y ago
  Reminds me of Quartz Composer
ebiester 13y ago
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.
elwell 13y ago
"in Minutes"... no.
memracom 13y ago
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.
- ihodes 13y ago
  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.
toddmorey 13y ago
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. [["if", "eq", "decline"], "Pending Response"]
- ihodes 13y ago
  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).
fleitz 13y ago
Or do it on your own server with a DSL instead of JSON. gem install state_machine
te0006 13y ago
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. See http://www.thingamy.com http://www.thingamy.com -> "process engine" (not associated in any way, just used to read and like their blog for some time)

51 points by ihodes 13y ago

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

tarr11 13y ago

Is this a JSON oriented workflow engine? 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.

ihodes 13y ago
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.
- fieldforceapp 13y ago
  I'm curious why you didn't try UML or SysML instead?

ericHosick 13y ago

What external APIs are working in Copper? Stripe? Twilio? etc.?

ihodes 13y ago
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 :)
- deleted 13y ago
  [deleted]

gfodor 13y ago

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.

ihodes 13y ago
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.
- gfodor 13y ago
  I don't understand. Can you explain? Writing jobs in SWF Flow Framework is an executable state machine.

krmmalik 13y ago

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) Look forward to chatting to you.

ihodes 13y ago
Great! I will be in touch very soon, looking forward to chatting.

ppadron 13y ago

Also, NoFlo: http://noflojs.org/ http://noflojs.org/.

nathancahill 13y ago
Reminds me of Quartz Composer

ebiester 13y ago

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.

elwell 13y ago

"in Minutes"... no.

memracom 13y ago

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.

ihodes 13y ago
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.

toddmorey 13y ago

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. [["if", "eq", "decline"], "Pending Response"]

ihodes 13y ago
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).

fleitz 13y ago

Or do it on your own server with a DSL instead of JSON. gem install state_machine

te0006 13y ago

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. See http://www.thingamy.com http://www.thingamy.com -> "process engine" (not associated in any way, just used to read and like their blog for some time)