• (cs)

    It all sounds like what happens when you let someone loose on Aspect-Oriented Programming who doesn't have the good taste to know when to not use it. WaTerFagile indeed…

  • anonymous (unregistered) in reply to chubertdev
    chubertdev:
    Send him an email with "Hello, world!" in it, and tell him that it's been integrated with Outlook, then show him the scheduling functionality. Bam.
    So you're replacing Hello World with something vastly more complex (Outlook). I thought you wanted to make it simpler. And yes, I did get "can != should".

    Sometimes, what you should do is replace an ill-conceived, under-designed existing application with a more flexible redesign based on your current scope, which is drastically more complex than it was when you began.

  • (cs) in reply to dkf
    dkf:
    It all sounds like what happens when you let someone loose on Aspect-Oriented Programming who doesn't have the good taste to know when to not use it. WaTerFagile indeed…

    Too much bad code comes from over-eager developers wanting to use something that has no place in what they are developing.

  • Stewart Peterson (unregistered)

    "Fagile" - it's Italian!

  • S (unregistered) in reply to psuedonymous
    psuedonymous:
    I'd have gone with Agilefall: not only are you plummeting towards the ground, but you've got to avoid obstacles on the way down.

    And among those obstacles, the most relevant one is the ground...

  • Ol' Bob (unregistered)

    Ho-hum, normal day at the office, nothing to see here, folks, move along now...

    CAPTCHA : genitus - A.W. doubled over in agony after his suddenly-former girlfriend kicked him in the genitus...

  • Ol' Bob (unregistered) in reply to S
    S:
    psuedonymous:
    I'd have gone with Agilefall: not only are you plummeting towards the ground, but you've got to avoid obstacles on the way down.

    And among those obstacles, the most relevant one is the ground...

    Learning to fly is easy. You just have to develop the knack for throwing yourself at the ground, and mising...

    CAPTCHA : haero - don't try to be a haero...

  • Jeff Grigg (unregistered) in reply to cybaz01
    cybaz01:
    If you are putting ACL's on get/set routines, it doesn't matter which methodology you are using, you are going to fail
    If the ACL checking on all the setters is the system's main problem, why not just delete all that useless code?
  • pouzzler (unregistered)

    Snoofle should undergo a rewrite. Spoken language isn't the same as written language.

  • QJo (unregistered) in reply to chubertdev
    chubertdev:
    TRWTF is most people that think a rewrite shouldn't be simpler than what it's replacing.

    The only time I have ever seen a valid reason for a rewrite is when you are porting an entire application from e.g. FORTRAN on a VAX to e.g. C or Java on a Windows/Linux environment, implementing a browser front-end.

    In such cases you do well to implement it incrementally, porting it over a module at a time, ensuring you get exactly the same results on the new installation that you do on the original one. Any differences should be caused by bugs in the original version which were hitherto undetected. In a perfect world, those bugs should first be implemented in the new system, and then when the results do match precisely, only then do you implement the bug-free version on the new version.

    The argument "This code is a pile of rubbish, let's throw it all away and start again from scratch" is just so wrong it's become a standing joke in the industry. There is no program which cannot be improved by incremental refactoring, merely lazy, incompetent and/or prima-donna programmers who believe such tasks as either demeaning or unappealing.

  • anonymous (unregistered) in reply to QJo
    QJo:
    The argument "This code is a pile of rubbish, let's throw it all away and start again from scratch" is just so wrong it's become a standing joke in the industry. There is *no* program which cannot be improved by incremental refactoring, merely lazy, incompetent and/or prima-donna programmers who believe such tasks as either demeaning or unappealing.
    It's not that the program cannot be improved, nor is it that the programmers are lazy or incompetent. It's knowing when to cut your losses and recognise when trying to incrementally refactor a steaming pile is going to be less cost-effective than just starting over with a solid design.
  • (cs) in reply to QJo
    QJo:
    chubertdev:
    TRWTF is most people that think a rewrite shouldn't be simpler than what it's replacing.

    The only time I have ever seen a valid reason for a rewrite is when you are porting an entire application from e.g. FORTRAN on a VAX to e.g. C or Java on a Windows/Linux environment, implementing a browser front-end.

    In such cases you do well to implement it incrementally, porting it over a module at a time, ensuring you get exactly the same results on the new installation that you do on the original one. Any differences should be caused by bugs in the original version which were hitherto undetected. In a perfect world, those bugs should first be implemented in the new system, and then when the results do match precisely, only then do you implement the bug-free version on the new version.

    The argument "This code is a pile of rubbish, let's throw it all away and start again from scratch" is just so wrong it's become a standing joke in the industry. There is no program which cannot be improved by incremental refactoring, merely lazy, incompetent and/or prima-donna programmers who believe such tasks as either demeaning or unappealing.

    The real-world example that I have in mind is a site that I'm working on for a club that I belong to (i.e., for free).

    It's over a decade old, written in a mixture of Perl and PHP using a text file for a database. I've learned Perl and used by PHP skills from college to help clean up the worst parts of it, but not go overboard.

    It's bad enough that all of the forms use GET instead of POST. So I'm replacing all of the Perl and PHP scripts with Python, but simple. Something better than long, standalone scripts, making sure that anything that works with the database (aka text file) is in one place, so that after I update the entire front end to use Python, I can then replace the text file with MySQL, and it doesn't take much to do the upgrade. I won't need to change the Python scripts except for the actual data access ones.

    So after I upgrade the site to Python, but before the MySQL upgrade, the site won't work much differently other than simple things like using POST instead of GET.

    Once I get the site to use cleaner scripts, then I can upgrade it to use a real database, and things like jQuery.

    However, since I'm my own boss, this is the best case scenario, so it's unlikely that you'll get this level of control in a professional work environment. But in a development utopia, you'd be able to replace what you need to with code that works the same, but is much easier to upgrade, then make those upgrades in a later phase.

  • Andrew (unregistered) in reply to anonymous
    QJo:
    The argument "This code is a pile of rubbish, let's throw it all away and start again from scratch" is just so wrong it's become a standing joke in the industry. There is *no* program which cannot be improved by incremental refactoring, merely lazy, incompetent and/or prima-donna programmers who believe such tasks as either demeaning or unappealing.

    Why then do demolition companies exist? Can't any building be adapted to the desired purpose of the lot, save for the lazy/incompetent people in charge?

    The ultimate reason why "nothing" can be a better starting point than "something" is this: It's far more effective to read your own mind than to read someone else's.

  • (cs) in reply to TheCPUWizard
    TheCPUWizard:
    Some folks use Waterfall

    I have not seen a true waterfall project in decades...

    Not since the rebel attack on the death star.

  • Duke of New York (unregistered) in reply to TheCPUWizard
    TheCPUWizard:
    With true waterfall, once the spec is written, there are NO changes, no matter what, until the delivery is complete.
    "true waterfall" is one of those elusive beasts like "true freedom" and "true christianity"
  • (cs) in reply to Dazed
    Dazed:
    TheCPUWizard:
    With true waterfall, once the spec is written, there are NO changes, no matter what, until the delivery is complete.
    Where on earth did you get that idea? I've worked on over a dozen waterfall projects, for about a dozen organisations, in four different countries, and I've never met anyone who used that definition before.

    It's true that one commonly tries to keep the number of changes down, (and sometimes people try too hard) but I've never met a project so benighted as to try to forbid them completely.

    That was a common practice back when I started (early 1970's) and was almost universal a decade earlier when my mentors started their careers.

    You received an immutable and unquestionable (nobody to ask) specification, and delivered that. Eventually it would get tested, and a few months later you would get a new version of the specification along with a list of "deviations" which you addressed.

    I remember all too well a specification that contained "when age is 18+ OR under 25" (it should have said AND). The code was written (it executed for everyone, and the other conditions never did). Six months later the code was completed (about 3 man years of work), and submitted for testing. Nearly 9 months after that we got back a "failure" as part of the deviation report. We completed another 6 month cycle which contained justification (quoting the exact specification). They tested, it still was wrong, and more than 6 months later a revised specification (with "AND") was received (along with other changes) and another cycle began.

    Almost 3 years of delay that today (Even with CMMI) would be handled in a very short time (and nobody would proceed with writing the known wrong code).

  • thedailywtf (unregistered) in reply to chubertdev
    chubertdev:
    So after I upgrade the site to Python, but before the MySQL upgrade, the site won't work much differently other than simple things like using POST instead of GET.

    Once I get the site to use cleaner scripts, then I can upgrade it to use a real database, and things like jQuery.

    However, since I'm my own boss, this is the best case scenario, so it's unlikely that you'll get this level of control in a professional work environment.

    You're going to be on the front page, you know.

    Because when you do a good job, your WTF boss will fire you.

  • ph (unregistered) in reply to anonymous
    anonymous:
    QJo:
    The argument "This code is a pile of rubbish, let's throw it all away and start again from scratch" is just so wrong it's become a standing joke in the industry. There is *no* program which cannot be improved by incremental refactoring, merely lazy, incompetent and/or prima-donna programmers who believe such tasks as either demeaning or unappealing.
    It's not that the program cannot be improved, nor is it that the programmers are lazy or incompetent. It's knowing when to cut your losses and recognise when trying to incrementally refactor a steaming pile is going to be less cost-effective than just starting over with a solid design.

    Any program can be gradually made better. There is a methodology that any time you change something in the code, you refactor nearby code as well so the resulting codebase will be better in overall than before. This only works if the code has decent unit tests, otherwise the risk to break something is too large.

    It may sometimes happen indeed that a complete rewrite would be cheaper, but without tests or specifications you will never know if or when the rewrite is finished, so this claim cannot be really proved. And if your codebase already has tests and specifications, then a rewrite is typically not needed.

  • Kev (unregistered)

    '...dial down the lunacy...'

    In other words they couldn't be bothered doing their jobs so decided instead to define the task out of existence. Nice work if you can get it.

  • (cs) in reply to QJo
    QJo:
    The argument "This code is a pile of rubbish, let's throw it all away and start again from scratch" is just so wrong it's become a standing joke in the industry. There is *no* program which cannot be improved by incremental refactoring, merely lazy, incompetent and/or prima-donna programmers who believe such tasks as either demeaning or unappealing.
    So, let us know how you go with SSDS, then.
  • (cs) in reply to thedailywtf
    thedailywtf:
    chubertdev:
    So after I upgrade the site to Python, but before the MySQL upgrade, the site won't work much differently other than simple things like using POST instead of GET.

    Once I get the site to use cleaner scripts, then I can upgrade it to use a real database, and things like jQuery.

    However, since I'm my own boss, this is the best case scenario, so it's unlikely that you'll get this level of control in a professional work environment.

    You're going to be on the front page, you know.

    Because when you do a good job, your WTF boss will fire you.

    Yeah, I rock the boat a lot less at work. Although the managers in my department very strongly support us programmers, so I have that going for me, which is nice.

  • The Tragile Truth (unregistered)

    This is EXACTLY what 90% of organisations perceive "Agile" as. They never work out actual capacity, they do full project plans and simply break it down.

    Most Business Units won't fund something if they don't know what they're going to get, so you have to compromise and work it out. Of course, the compromise doesn't stop there: nothing is prioritised and everything is in. They use scrum to manage day-to-day operations but forget about the business.

    Quite honestly, the only people who really can implement true Agile practices are IT companies where the developers ARE the business and everyone understands what is going on. It will never change because IT is underappreciated and treated with great skepticism (usually for very good reason).

    The customer IS ALWAYS RIGHT, except when they're wrong but even they're right.

  • Douglastab (unregistered)

    Pharmacie en ligne livraison Europe https://kamagraenligne.com/# pharmacie en ligne france fiable

Leave a comment on “Waterfagile”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article