Loading ...
Sorry, an error occurred while loading the content.

Re: [altdotnet] Re: When is it overkill?

Expand Messages
  • Greg Young
    inline... ... Yes they are extremely relative and my point would be that great code is only one small part of the analysis. ... Yes and in many sectors this
    Message 1 of 51 , Jul 10, 2008
    View Source
    • 0 Attachment
      inline...

      On Tue, Jul 8, 2008 at 6:52 PM, Chad Myers <chad.myers@...> wrote:
      >
      > In my experience, 'best', 'solve', 'works/working', 'stakeholder' are all
      > relative. Most people deliver 'working' solutions, otherwise they wouldn't
      > have careers in software development.
      >

      Yes they are extremely relative and my point would be that great code
      is only one small part of the analysis.


      > (NOTE: I use the word 'you' a lot in here, I'm addressing everyone including
      > myself, not just jdn or Greg or whomever)
      >
      > But, and this is where people disagree because there's no way to quantify it
      > really, you can always do it better, and save your client more money and
      > make it better when 'best' might just be 'good enough'. Working, for most
      > of the places I've been at, is usually bare minimum and involves a re-write
      > in 2-3 years. You ask the business managers/stakeholders and they mumble and
      > grumble about this, but the software still makes them a bunch of money.
      >

      Yes and in many sectors this would be considered a huge success as the
      eco-system around the system would probably have drastically changed
      within those same 2-3 years. The financial industry is a great example
      of this ..


      > Could/can we do better? YES! And that's the key.

      Could you? You are looking at this problem from a PROGRAMMING
      perspective not from a BUSINESS perspective. It is quite possible that
      the main goals of the system were

      1) Time to Market
      2) Low initial Cost

      If those were the initial business goals and the system survived 2-3
      years before needing a rewrite due to the ecosystem around the
      software evolving so far from the software I might consider it a huge
      success.

      > Strive for perfection, make
      > well known/understoood compromises to get it out the door and focus on
      > maintaining quality and efficiency throughout the life of the project. I
      > have seen many a project rush to get things out the door and then everyone
      > leaves and the software completely goes to poop after just a few months due
      > to poor initial design choices followed by really bad design choices in
      > maintenance.
      >

      Yes an it sounds like in that situation MAINTAINABILITY should be a
      key business concern. My argument is that great code is not a defacto
      standard in providing the best possible option for a client. It is
      nothing more than one of the many non-functional requirements that
      need to be analyzed with the client.


      > Just about everyone's software 'works', if that's all you (any of us) are
      > looking for, then you should re-evaluate your professionalism because we
      > should all be striving for excellence and perfection and making compromises
      > where we must.
      >

      You tell me I need to "reevaluate my professionalism", bullshit. This
      is an extremely narrow minded (programmer centric) viewpoint that is
      only looking at a single metric. Remember that I am referring to an
      optimization of the ENTIRE process not only of one aspect of it. There
      are many parts of "success" and not all of them have to do with the
      code that is produced.


      > Are you going to build a product to last just long enough to satisfy the
      > warranty period, or are you going to make something that last well beyond
      > it's expected life span an delights the customer? (unless, of course,
      > you're told by your stakeholders to purposely make it last just long enough
      > for the warranty, but that's another matter altogether).
      >

      I don't believe anyone would suggest writing such code (unless that is
      what the current business dictates). Business changes greatly, quite
      often it is well known in advance that the software will very unlikely
      be running in 4 years because the entire business will have changed
      and the software in its current state will be useless. A stakeholder
      will never actually tell you this though ... You need to pry it out of
      them.

      > -c
      >
      > On Tue, Jul 8, 2008 at 5:35 PM, jdn3times <jdn3times@...> wrote:
      >>
      >> Abso-freaking-lutely what he said.
      >>
      >> jdn
      >>
      >> --- In altdotnet@yahoogroups.com, "Greg Young" <gregoryyoung1@...>
      >> wrote:
      >> >
      >> > OK I will take the opposing side...
      >>
      >> <snip good stuff>
      >>
      >> > I used to believe heavily in the writing of great software ...
      >> since
      >> > then I have grown up and been knocked off my soap box. Now I
      >> > understand that there is only one kind of great software and that
      >> is
      >> > the one that best solves the issues of the stakeholders, the
      >> quality
      >> > of the code generally has little to do with it.
      >> >
      >> > Cheers,
      >> >
      >> > Greg
      >>
      >>
      >>
      >> ------------------------------------
      >>
      >> Yahoo! Groups Links
      >>
      >>
      >>
      >
      >



      --
      It is the mark of an educated mind to be able to entertain a thought
      without accepting it.
    • Chad Myers
      inline On Thu, Jul 10, 2008 at 11:43 AM, Greg Young ... Please don t tell me what I m doing or not, sir :) (said humorously, no hard
      Message 51 of 51 , Jul 10, 2008
      View Source
      • 0 Attachment
        inline

        On Thu, Jul 10, 2008 at 11:43 AM, Greg Young <gregoryyoung1@...> wrote:

        > > Could/can we do better? YES! And that's the key.

        > Could you? You are looking at this problem from a PROGRAMMING
        > perspective not from a BUSINESS perspective.

        Please don't tell me what I'm doing or not, sir :)  (said humorously, no hard feelings)

        No, I'm thinking whole picture. Most software I know of doesn't do that great of a job and I hear programmers say something 'works', but they're costing the business side a fortune in maintenance fees and all the admin and support personnel required to keep the system goin.

        You betcha there's almost always room for more efficiency, especially once the initial release is out.
         
        You tell me I need to "reevaluate my professionalism", bullshit. This
        is an extremely narrow minded (programmer centric) viewpoint that is
        only looking at a single metric. Remember that I am referring to an
        optimization of the ENTIRE process not only of one aspect of it. There
        are many parts of "success" and not all of them have to do with the
        code that is produced.

        I think you might have misunderstood what I was saying here because your response isn't in-kind with my original point.

        A lot of shops I've been in, as soon as someone says it 'works', their brains shut off and this horrible apathy/complacency sets in and everything goes to hell rapidly. Vigilance is a sign of professionalism and I cringe when people say things like 'it works, we don't need to improve it'

        I'm talking specifically about the mindset that leads to statements like (paraphrased from someone else) "I don't need that [new stuff] because my current system works".

        "Works" ends up being an excuse for not being vigilant and constantly looking for ways to meet and exceed expectations.
      Your message has been successfully submitted and would be delivered to recipients shortly.