From: Ilya Zakharevich on
On 2010-07-05, Martijn Lievaart <m(a)rtij.nl.invlalid> wrote:
>> In general, I consider the pipe dream of "formulate the requirements
>> first, then code to specification" very counter-productive; most
>> probably, it is one of the principal tumbling blocks in the contemporary
>> state of the programming. It may work in a handful of toy situations,
>> but it does not scale up to "what really happens".

> That is why one of the cardinal rules of Prince II project management is
> "Requirements change".

>> Software designers should be ready to changes-in-specification when new
>> information is gathered by pilot implementations. They should be ready
>> to advise ASAP the clients on possible pitfalls in the pilot
>> specifications, etc.

> Encapsulation and loose coupling are your friends here. Well written
> components encapsulate the requirements and are easy to change.

Not in my experience. Encapsulation is also a mantra which "really
helps" in toy situations only. "With real problems" you cannot guess
the "proper" capsules until you finished the project...

So, essentially, encapsulation helps only when one is ready to move
boundaries of capsules (which usually leads to major headackes
coding-wise...).

Likewise, `loose coupling' is possible only if you guessed boundaries
of capsules "correct", AND this choice provides enough "looseness".
And, of course, "in real life" the boundaries of capsules MUST go over
"a live flesh" when there is just not enough loose coupling inherent in
the problem domain.

Yours,
Ilya
From: Dr.Ruud on
Martijn Lievaart wrote:
> On Thu, 01 Jul 2010 22:25:41 +0000, Ilya Zakharevich wrote:

>> In general, I consider the pipe dream of "formulate the requirements
>> first, then code to specification" very counter-productive; most
>> probably, it is one of the principal tumbling blocks in the contemporary
>> state of the programming. It may work in a handful of toy situations,
>> but it does not scale up to "what really happens".
>
> That is why one of the cardinal rules of Prince II project management is
> "Requirements change".
>
>> Software designers should be ready to changes-in-specification when new
>> information is gathered by pilot implementations. They should be ready
>> to advise ASAP the clients on possible pitfalls in the pilot
>> specifications, etc.
>
> Encapsulation and loose coupling are your friends here. Well written
> components encapsulate the requirements and are easy to change.

OTOH, you can't always afford a wasteful interface. And project
management is often evil in itself.

We make many small changes every day to a big central code base, shared
by all sub-processes. Hardly any redesign or refactoring needed. No
tiers, just Linux, Apache, MySQL, Perl.

Only one out of ten changes really survives, so never mind throwing out
what you recently did. By keeping changes small, the mistakes are
limited too, and you still know immediately where they come from.

--
Ruud
From: Martijn Lievaart on
On Mon, 05 Jul 2010 10:05:29 +0000, Ilya Zakharevich wrote:

> On 2010-07-05, Martijn Lievaart <m(a)rtij.nl.invlalid> wrote:
>
>> Encapsulation and loose coupling are your friends here. Well written
>> components encapsulate the requirements and are easy to change.
>
> Not in my experience. Encapsulation is also a mantra which "really
> helps" in toy situations only. "With real problems" you cannot guess
> the "proper" capsules until you finished the project...

I agree that it is hard to get it right the first time, but as the
requirements DO change, you get several shots at it. :-) Although said
tongue in cheek, it is very true in real life.

I also agree that in retrospect you always see better ways and some grave
design errors you made.

Still, encapsulation does help. Some parts are always trivial, some parts
are (much) harder and some thinking upfront (preferably in a team!) may
save you a lot of time later. If unsure, prototype first. Not for the
customer, but for yourself. Be prepared to throw the prototype away ro
completely rewrite it.

If the requirements change and it turns out your encapsulation was wrong,
you probably didn't understand the problem domain well enough anyhow and
should indeed change the encapsulation as a result of your new insights.

And I strongly disagree about the "Toy situations". The bigger the
project, the more important modeling and encapsulation become.

>
> So, essentially, encapsulation helps only when one is ready to move
> boundaries of capsules (which usually leads to major headackes
> coding-wise...).

Strongly disagree. Although sometimes the problem context is hard to
model, more often than not it is not that hard. And it always pays off.

If you did not encapsulate well or at all, the rewrite is often just as
painful, or even more. Only when your encapsulation is really poor, it
becomes a real pain in the butt and you had better start over.

>
> Likewise, `loose coupling' is possible only if you guessed boundaries of
> capsules "correct", AND this choice provides enough "looseness". And, of

Same reasoning as above applies, it is not only likewise, it is actually
the same issue.

> course, "in real life" the boundaries of capsules MUST go over "a live
> flesh" when there is just not enough loose coupling inherent in the
> problem domain.

I don't understand that last sentence (English is not my native
language), can you repeat that?

M4
From: Dr.Ruud on
Martijn Lievaart wrote:

> The bigger the project

, the bigger the failure.

--
Ruud
From: Peter J. Holzer on
On 2010-07-01 22:25, Ilya Zakharevich <nospam-abuse(a)ilyaz.org> wrote:
> On 2010-07-01, Peter J. Holzer <hjp-usenet2(a)hjp.at> wrote:
>> I disagree. He should have mentioned that and quite a few things more
>> (for example the different date formats, whether user and group names
>> are always numeric, and if not, whether they can contain spaces, etc.)
>>
>> Test data is nice but you can never assume that it covers all possible
>> cases and requirements reverse engineered from a few lines of test
>> data are almost guaranteed to be incomplete. Besides, why should
>> everyone in this group have to figure out the requirements when the OP
>> can do it once?
>
> I think that now you realized that your arguments lead you to a
> contradiction.

No, not at all.

> This thread provided tons of useful information about
> how the OP's requirements MIGHT look like.

But not from test data provided by the OP. Most of the useful
information came from the experience of other posters. And they
presented their knowledge in English, not in the form of uncommented
"ls -l" output.

> Armed with this list of
> possible complications, NOW the OP is in the position of answering the
> question about which of these complications might appear in his listings.

Right. And without knowledge about these complications he couldn't have
selected the test data either. The knowledge you need to select minimal
test data with maximum coverage is exactly the same knowledge you need
to write a specification in plain English.

Now the "minimal" test data absolutely not a requirement in real life:
If I needed to parse ls output I would be happy to get 10000 lines of
real output from each of the target systems. But this is Usenet. If the
OP simply posted 10000 lines of test data here, Tad would be the first
to ask him whether he'd lost his marbles. And with good reason. This
group is not for solving somebodys programming requirements but for
discussing Perl.

hp