Why software development is broken
kozo.io
kozo.io
I fully expect to get down voted here, but I really hope the damage is minimal. Please be gentle since inside my link is a valid point pertinent to this post, which summarizes my thoughts concisely. :-)
He argues, that his tool uses a declarative style to define the solution. There are other solutions which do the same. (lordbusiness already provided the xkcd, so i will skip this.) In my experience, declarative is great when it works, until you grow out of it and have to fight it.
I already wanted to comment something like that on the first thread he started but hesitated. With a linkbaiting title like this I feel they finally deserved it :)
In most cases, a solution relating (real-life) actors, processes and objects they handle can (and will) be described in plain text. In an Enterprise environment, this may be part of the project specification. However, the actual implementation will be specified as source code. To an extent this may even apply to purely technical projects.
In a larger team, creating this specification of a project is typically part of a project manager's job. However, in a smaller team or start-up, these roles may merge and are not as clearly defined. This is especially true, if the team is focussed on both building a product and working with (potential) customers.
And of course, it's up to you to decide whether Kozo will be useful for you once it is released. ;)