in reply to Creating large apps

Failure to take the time to really map out the data and logic flows of an application are one of the biggest problems that programmers seem to face when writing anything more significant than "Hello, World".
I have found with Perl it is better to just dig in and avoid a lengthy overy intellectual design phase. And then just evolve the code as need be. Perl is naturally flexible and should be used as such.

Another interesting tack is: in a language where there is no distinction between data and logic, who needs such mapping out? And such a language is Prolog... the actual algorithms may be heinously slow, but hey at least the whole prototype is fleshed out... it, it allows you to design and run your design: the specification is the implementation in Prolog.

Replies are listed 'Best First'.
Re: Re: Creating large apps
by eduardo (Curate) on Jun 06, 2001 at 22:01 UTC
    I have to strongly disagree with your statements princepawn, based on my experience. You say:
    I have found with Perl it is better to just dig in and avoid a lengthy overy intellectual design phase. And then just evolve the code as need be. Perl is naturally flexible and should be used as such.
    I am afraid that choice in language it is unfortunately irrelevant. The "maping out the data and logic flows" in programming projects that I have dealt with had little, if anything, to do with actual implementation detail, or the toolset (or toolsets) which we had chosen to utilize. While I am a proponent of a softare development methodology which leverages some more RAD philosophies (I think XP is closer, but not completely there yet), the "map of the data and logic flow" is usually instrinsically tied to business processes as well as client requirements. In most *large* application development projects, the problem domain is not sufficiently documented so that one actually understands the nature of the problem they are attempting to solve, so without an upfront phase of "discovery" where the problem set is enumerated, and the relationships between the entities are at least partially established.

    To do otherwise, is a lack of feduciary responsibility, and is one of the keystone reasons why over 80% of software projects fail (CHAOS Report, Standish Group.)
      I agree with eduardo.

      When designing *really* big application, you just cannot be too cautious in design phase. If you hope your code will "evolve" - good luck.

      Trying to "evolve" code might work is application where you have knowledge of problem area, so your "feeling" about desig decision will be based on your knowledge and intuition - and yes on your luck.

      OTOH, *really* big applications are far too complex to rely on plain intuition and luck. What is worse, there might not be ane person understanding the whole picture. So even XP programming will have setbacks.

      Just an example from my experience: I was working recently on a huge project for a big bank. When I started, we were supposed to go live in 2 months. When I left 2 years later, we were 2 months live. And most of the time we were some 2-3 months before going live.

      Why? Because bank itself lacked understanding how different deparments collaborate. There were couple of users who know in detail how works department they worked in, couple even had experience in work for more than one dept.

      But sometimes part of experience was outdated, or not detailed enough - they knew only about problems for "junior" positions.

      Also, big problems have most likely previous solution, which is not adequate, and you need to replace it, but previous solution formed perception of users how solution to their problems should look like. So sometimes you cannot provide better solution, but solution they believe is closer what they used to have. Especially if you are in time constraints as we were, there is not enough time to research and provide better solution - you just go ahead and try to simulate part of what they have without much understanding.

      I was added to one obscure part of project, what another (decent programmer, but without design experience) was implementing - to help him. We found that in whole company there was only one person completely understanding this obscure, but very basic and important feature of the system (custom enhancement of big system). He was very helpful, but his time was very valuable and not easy to get.

      After much research, we found that database contained various types of wrong data from different stages of implementation of custom part, which he did not want to distract us, and was forced to add features what he needed but decided not to implement in old system, because of expected conversion to new system.

      And of course this person was very smart when talking, but completely not capable express himself in writing. So you cannot imagine how bad written specifications were...

      It was big struggle.

      Summary: In *really big application*, do not expect that there is one person, or even a group of persons, who understands it as a whole, or it will be easy to solicit correct specifications. To overcome this migt be substantial part of problem.

      pmas

      To make errors is human. But to make million errors per second, you need a computer.

Re: Re: Creating large apps
by Anonymous Monk on Jun 06, 2001 at 23:02 UTC
    Here is an example of why this is a bad idea.