

Why software development is broken - gfmio
https://www.kozo.io/blog/why-software-development-is-broken/

======
lordbusiness
[http://xkcd.com/927/](http://xkcd.com/927/)

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

~~~
hvs
I think many people were coming here to post that. It is apropos in my
opinion.

------
allendoerfer
The author sees other languages and frameworks as implementation details and
wants developers to get rid of them and actually define solutions to problems.
What he misses is, that these technologies are actually the language you use
to define solutions.

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

~~~
gfmio
Thank you for the useful remarks. It depends on the nature of your task,
doesn't 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. ;)

