[erlang-questions] Rhetorical structure of code: Anyone interested in collaborating?
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:
>> This works as long as the documentation isn't over-specific.
>> Otherwise it turns into a waterfall model of development.
>> On 04/05/2016 18:42, Éric Pailleau wrote:
>>> 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
>>> 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
>>> 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
>>> 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.
>>> erlang-questions mailing list
>> erlang-questions mailing list
> In theory, there is no difference between theory and practice.
> In practice, there is. .... Yogi Berra
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions