From: Ilya Zakharevich on 5 Jul 2010 06:05 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 5 Jul 2010 06:12 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 5 Jul 2010 07:32 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 5 Jul 2010 07:55 Martijn Lievaart wrote: > The bigger the project , the bigger the failure. -- Ruud
From: Peter J. Holzer on 5 Jul 2010 09:27
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 |