[erlang-questions] Rhetorical structure of code: Anyone interested in collaborating?

Grzegorz Junka list1@REDACTED
Thu May 5 00:29:53 CEST 2016

I didn't say there is anything wrong with waterfall, did I? I only said 
that it would no longer be DDD development but a waterfall project instead.


On 04/05/2016 20:36, Miles Fidelman wrote:
> And what, exactly is wrong with waterfall?  (Says this somewhat older, 
> crusty, systems architect?)
> I've seen way too many agile projects that ignore things like 
> architecture, operating environment, concept of operations, 
> interfaces, systems management, etc., etc., etc. - all those things 
> that are kind of important for mission critical systems.
> Miles Fidelman
> On 5/4/16 3:08 PM, Grzegorz Junka wrote:
>> This is called Documentation Driven Development:
>> http://thinkingphp.org/spliceit/docs/0.1_alpha/pages/ddd_info.html
>> http://stackoverflow.com/questions/588760/documentation-driven-design-your-experiences
>> https://gist.github.com/zsup/9434452
>> This works as long as the documentation isn't over-specific. 
>> Otherwise it turns into a waterfall model of development.
>> Grzegorz
>> On 04/05/2016 18:42, Éric Pailleau wrote:
>>> Hi,
>>> It is certainly unusual, but I almost always start by writing user 
>>> documentation,  before coding.
>>> There is some interests to do so.
>>> First, documentation exists at end of project because it exists at 
>>> beginning.
>>> Second, documentation describe simple things like you would need as 
>>> a user, and not complicated things as consequences of bad coding. 
>>> Coding is then driven by this goal, and generally simplify the code 
>>> itself.
>>> Third, coders know the goal to achieve at start and do not loose 
>>> time in, finally, unneeded things.
>>> I really recommend to do this experience.
>>> "Envoyé depuis mon mobile " Eric
>>> ---- Grzegorz Junka a écrit ----
>>> > - I have said several times that we write code because it is 
>>> quicker to
>>> > write it from scratch, than to discover code that does what we 
>>> want, or
>>> > modify code that does almost what we want but not quite.
>>> >
>>> That's very true, but it applies all the way through. The more time has
>>> been invested into some code the more time it would be needed to write
>>> it from scratch. For example, I would prefer Elixir's convention of
>>> listing the object on which the operation is being performed as the
>>> first argument in library function calls over the OTP convention of
>>> listing it as the last argument. But I am not going to rewrite OTP
>>> libraries for that small inconvenience.
>>> Very often understanding an existing application and fixing issues is
>>> easier and quicker than writing a new one from scratch, especially if
>>> one only need to understand a specific or small part of it, and even
>>> more if the existing application supports plugins allowing to skip 
>>> large
>>> parts of its code in custom modules.
>>> This should be a lesson for those who design applications and its
>>> interfaces, and in my opinion putting effort into designing the
>>> application properly is more important than documenting everything,
>>> because it's always a trade-off. Very often the documentation isn't
>>> there not because it's not needed, but because there was not enough
>>> resources to put it there in the first place.
>>> If the architecture is good then the documentation can always be added
>>> later. But if the architecture is not good, then no matter how much
>>> documentation is written, it will be quickly outdated by the constant
>>> and often fixes and patches to that architecture to make it working.
>>> Grzegorz
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>>> http://erlang.org/mailman/listinfo/erlang-questions
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
> -- 
> In theory, there is no difference between theory and practice.
> In practice, there is.  .... Yogi Berra
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160504/6a30c0f4/attachment.htm>

More information about the erlang-questions mailing list