
Build Business Logic in Minutes, Not Weeks - ihodes
http://www.copperthoughts.com/p/business-logic-in-minutes-not-weeks/
======
ebiester
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
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
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
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
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
I'm curious why you didn't try UML or SysML instead?

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

------
krmmalik
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
Great! I will be in touch very soon, looking forward to chatting.

------
ppadron
Also, NoFlo: [http://noflojs.org/](http://noflojs.org/).

~~~
nathancahill
Reminds me of Quartz Composer

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

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

------
fleitz
Or do it on your own server with a DSL instead of JSON.

    
    
      gem install state_machine

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

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

------
elwell
"in Minutes"... no.

