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

This could be fun. I hope.

Expand Messages
  • Esther Schindler
    Howdy, folks. I haven t had the opportunity to hang around in these parts recently (drat, haven t gotten to write-or-edit much about software dev for a while),
    Message 1 of 9 , Sep 22, 2010
    • 0 Attachment
      Howdy, folks. I haven't had the opportunity to hang around in these parts recently (drat, haven't gotten to write-or-edit much about software dev for a while), but happily that appears to be changing.

      I've just been given an assignment to write a short article with the working title of "7 Things the Consumerized Enterprise Can Learn From Agile Development." The "7" is really &n; the actual number will reflect how many points I can come up with. And by "consumerized enterprise" I mean large companies that recognize that their users are bringing in technology (eg smartphones) without IT's approval but expecting some level of support from IT.

      For instance, I'm thinking (but haven't yet articulated into a "point" yet) that enterprise IT must change its processes to expect change and respond quickly to it. This, I think, it can learn from Agile in terms of "iterative development." Once, the IT department could make declarations about "this is what we support, and if you use something else we will point at you and laugh -- at best." Nowadays, IT had better be ready to support a user's iPhone to connect to the company e-mail... and not simply add that as a Supported Product to a list (after 6 months of negotiations).

      This isn't meant to be a "he said she said" reported article as much as "What Esther thinks about the topic" though if anyone has pithy comments I'd be happy to quote you.

      Meanwhile... got any suggestions? What should I include on my list?

      Esther Schindler
      http://www.twitter.com/estherschindler
    • DH
      On 10-09-22 12:54 PM, Esther Schindler wrote: ... Hello, As much as I love the sentiment of your message that is not how it works. There is a big
      Message 2 of 9 , Sep 22, 2010
      • 0 Attachment
        On 10-09-22 12:54 PM, Esther Schindler wrote:
        <Snip>

        > For instance, I'm thinking (but haven't yet articulated into a "point" yet) that enterprise IT must change its processes to expect change and respond quickly to it. This, I think, it can learn from Agile in terms of "iterative development." Once, the IT department could make declarations about "this is what we support, and if you use something else we will point at you and laugh -- at best." Nowadays, IT had better be ready to support a user's iPhone to connect to the company e-mail... and not simply add that as a Supported Product to a list (after 6 months of negotiations).
        >

        Hello,

        As much as I love the sentiment of your message that is not how it
        works. There is a big difference between supporting your internal users
        (employees), your development and production environments. Most IT
        departments are very flexible when it comes to supporting the Production
        environments and many people agree that control over deveolpment systems
        should slowly be fed back into the teams that needs them most. After all
        you can always ask for a system Admin to be part of your sprint when
        need be.

        However when it comes to supporting the actual employee cost control and
        the fact that you need to understand what you are focusing on often
        prohibits the behaviour you are describing. That is not something that
        has to do with "Agile" it is a problem of cost control and how the CFO
        interacts with his procedures with the IT people. I am sure the IT guy
        would be happy to give you the brand new iPhone 4 but your company has a
        standing contract with Blackberry and thus costs are 40% lower. What do
        you think you will be ending up with?

        Not to mention that it is complicated to service diversification when
        you do not have the ability for the user to serve themselves. Take a
        company like Rogers here in Canada. They have nearly 10.000 employees
        everyone included and the mere idea of letting people choose what phone
        they want to use would cause havoc. Not because it is a bad idea, but
        because there is no way for them to service their chosen phone when
        something goes wrong.

        So while I like the sentiment of the article, I think you are targeting
        the wrong audience for the message that you are sending.

        -d
      • Victor
        Hi Esther, I would say that more than a technical approach, Agile is about people working together in a respectful environment of cooperation to get long term
        Message 3 of 9 , Sep 22, 2010
        • 0 Attachment
          Hi Esther,

          I would say that more than a technical approach, Agile is about people
          working together in a respectful environment of cooperation to get long term
          good results, measured in small steps.

          Ricardo Semler might be a good example of an enterprise applying a similar
          approach, with impressive results.
          On the other hand, those interested to be the head of a company, division,
          or group for the main purpose of playing power games in their private
          fiefdoms, will have less successful results in the long term.

          Victor Goldberg

          ==================================

          ----- Original Message -----
          From: "Esther Schindler" <esther@...>
          To: <extremeprogramming@yahoogroups.com>
          Sent: Wednesday, September 22, 2010 12:54 PM
          Subject: [XP] This could be fun. I hope.


          > Howdy, folks. I haven't had the opportunity to hang around in these parts
          > recently (drat, haven't gotten to write-or-edit much about software dev
          > for a while), but happily that appears to be changing.
          >
          > I've just been given an assignment to write a short article with the
          > working title of "7 Things the Consumerized Enterprise Can Learn From
          > Agile Development." The "7" is really &n; the actual number will reflect
          > how many points I can come up with. And by "consumerized enterprise" I
          > mean large companies that recognize that their users are bringing in
          > technology (eg smartphones) without IT's approval but expecting some level
          > of support from IT.
          >
          > For instance, I'm thinking (but haven't yet articulated into a "point"
          > yet) that enterprise IT must change its processes to expect change and
          > respond quickly to it. This, I think, it can learn from Agile in terms of
          > "iterative development." Once, the IT department could make declarations
          > about "this is what we support, and if you use something else we will
          > point at you and laugh -- at best." Nowadays, IT had better be ready to
          > support a user's iPhone to connect to the company e-mail... and not simply
          > add that as a Supported Product to a list (after 6 months of
          > negotiations).
          >
          > This isn't meant to be a "he said she said" reported article as much as
          > "What Esther thinks about the topic" though if anyone has pithy comments
          > I'd be happy to quote you.
          >
          > Meanwhile... got any suggestions? What should I include on my list?
          >
          > Esther Schindler
          > http://www.twitter.com/estherschindler
          >
          > ------------------------------------
          >
          > To Post a message, send it to: extremeprogramming@...
          >
          > To Unsubscribe, send a blank message to:
          > extremeprogramming-unsubscribe@...
          >
          > ad-free courtesy of objectmentor.comYahoo! Groups Links
          >
          >
          >
          >
        • George Dinwiddie
          Hi, Esther, I d say that the Agile ability to respond to change, and the further impetus to do things in a way that expects change, handles it, and uses
          Message 4 of 9 , Sep 22, 2010
          • 0 Attachment
            Hi, Esther,

            I'd say that the Agile ability to respond to change, and the further
            impetus to do things in a way that expects change, handles it, and uses
            strategies to allow for change, will make it easier for the Consumerized
            Enterprises to keep up with the new technology that people bring with
            them. I would suspect that doing so will also help the CE keep up with
            the technology changes of their customers and colleagues. And they
            might even discover some competitive advantages along the way.

            - George

            P.S. I'm always happy to see my name in lights with a link back to my
            website, but it's entirely up to you.

            On 9/22/10 12:54 PM, Esther Schindler wrote:
            > Howdy, folks. I haven't had the opportunity to hang around in these
            > parts recently (drat, haven't gotten to write-or-edit much about
            > software dev for a while), but happily that appears to be changing.
            >
            > I've just been given an assignment to write a short article with the
            > working title of "7 Things the Consumerized Enterprise Can Learn From
            > Agile Development." The "7" is really&n; the actual number will
            > reflect how many points I can come up with. And by "consumerized
            > enterprise" I mean large companies that recognize that their users
            > are bringing in technology (eg smartphones) without IT's approval but
            > expecting some level of support from IT.
            >
            > For instance, I'm thinking (but haven't yet articulated into a
            > "point" yet) that enterprise IT must change its processes to expect
            > change and respond quickly to it. This, I think, it can learn from
            > Agile in terms of "iterative development." Once, the IT department
            > could make declarations about "this is what we support, and if you
            > use something else we will point at you and laugh -- at best."
            > Nowadays, IT had better be ready to support a user's iPhone to
            > connect to the company e-mail... and not simply add that as a
            > Supported Product to a list (after 6 months of negotiations).
            >
            > This isn't meant to be a "he said she said" reported article as much
            > as "What Esther thinks about the topic" though if anyone has pithy
            > comments I'd be happy to quote you.
            >
            > Meanwhile... got any suggestions? What should I include on my list?
            >
            > Esther Schindler
            > http://www.twitter.com/estherschindler

            --
            ----------------------------------------------------------------------
            * George Dinwiddie * http://blog.gdinwiddie.com
            Software Development http://www.idiacomputing.com
            Consultant and Coach http://www.agilemaryland.org
            ----------------------------------------------------------------------
          • Esther Schindler
            George my dear, I am always happy to quote you in my articles, because you always make me look smarter. :-) I agree with your overall assessment but I m
            Message 5 of 9 , Sep 22, 2010
            • 0 Attachment
              George my dear, I am always happy to quote you in my articles, because you always make me look smarter. :-)

              I agree with your overall assessment but I'm scratching my head to come up with an example. Can we imagine a scenario?

              On Sep 22, 2010, at 1:27 PM, George Dinwiddie wrote:

              > Hi, Esther,
              >
              > I'd say that the Agile ability to respond to change, and the further
              > impetus to do things in a way that expects change, handles it, and uses
              > strategies to allow for change, will make it easier for the Consumerized
              > Enterprises to keep up with the new technology that people bring with
              > them. I would suspect that doing so will also help the CE keep up with
              > the technology changes of their customers and colleagues. And they
              > might even discover some competitive advantages along the way.
              >
              > - George
              >
              > P.S. I'm always happy to see my name in lights with a link back to my
              > website, but it's entirely up to you.
              >
              > On 9/22/10 12:54 PM, Esther Schindler wrote:
              >> Howdy, folks. I haven't had the opportunity to hang around in these
              >> parts recently (drat, haven't gotten to write-or-edit much about
              >> software dev for a while), but happily that appears to be changing.
              >>
              >> I've just been given an assignment to write a short article with the
              >> working title of "7 Things the Consumerized Enterprise Can Learn From
              >> Agile Development." The "7" is really&n; the actual number will
              >> reflect how many points I can come up with. And by "consumerized
              >> enterprise" I mean large companies that recognize that their users
              >> are bringing in technology (eg smartphones) without IT's approval but
              >> expecting some level of support from IT.
              >>
              >> For instance, I'm thinking (but haven't yet articulated into a
              >> "point" yet) that enterprise IT must change its processes to expect
              >> change and respond quickly to it. This, I think, it can learn from
              >> Agile in terms of "iterative development." Once, the IT department
              >> could make declarations about "this is what we support, and if you
              >> use something else we will point at you and laugh -- at best."
              >> Nowadays, IT had better be ready to support a user's iPhone to
              >> connect to the company e-mail... and not simply add that as a
              >> Supported Product to a list (after 6 months of negotiations).
              >>
              >> This isn't meant to be a "he said she said" reported article as much
              >> as "What Esther thinks about the topic" though if anyone has pithy
              >> comments I'd be happy to quote you.
              >>
              >> Meanwhile... got any suggestions? What should I include on my list?
              >>
              >> Esther Schindler
              >> http://www.twitter.com/estherschindler
              >
              > --
              > ----------------------------------------------------------------------
              > * George Dinwiddie * http://blog.gdinwiddie.com
              > Software Development http://www.idiacomputing.com
              > Consultant and Coach http://www.agilemaryland.org
              > ----------------------------------------------------------------------
              >
              >
              >
              > ------------------------------------
              >
              > To Post a message, send it to: extremeprogramming@...
              >
              > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
              >
              > ad-free courtesy of objectmentor.comYahoo! Groups Links
              >
              >
              >
              >
            • George Dinwiddie
              Esther, ... I hardly think so, because you look pretty smart already. ... OK, what about this hypothetical scenario: A system admin is going on a business
              Message 6 of 9 , Sep 22, 2010
              • 0 Attachment
                Esther,

                On 9/22/10 7:03 PM, Esther Schindler wrote:
                > George my dear, I am always happy to quote you in my articles,
                > because you always make me look smarter. :-)

                I hardly think so, because you look pretty smart already.

                > I agree with your overall assessment but I'm scratching my head to
                > come up with an example. Can we imagine a scenario?

                OK, what about this hypothetical scenario: A system admin is going on a
                business trip in a few weeks, and wants the web interface that he often
                uses customized in a version more usable on a cell phone browser rather
                than having to use the company laptop.

                For an experienced Agile team, this is just another change, even if
                they've never done a cell phone interface before. The code is already
                well factored such that putting a new front end is fairly
                straightforward; they just need to learns the ins and outs of what
                displays well on the small screen.

                With the knowledge they gain doing this work, they realize they can
                easily make public-facing pages accessible on small screens, also. The
                company decides it's a good idea. They do so, and publicize it
                well--taking a few percent of market share from their slower, stodgier
                competitors.

                How's that?

                - George

                > On Sep 22, 2010, at 1:27 PM, George Dinwiddie wrote:
                >
                >> Hi, Esther,
                >>
                >> I'd say that the Agile ability to respond to change, and the further
                >> impetus to do things in a way that expects change, handles it, and uses
                >> strategies to allow for change, will make it easier for the Consumerized
                >> Enterprises to keep up with the new technology that people bring with
                >> them. I would suspect that doing so will also help the CE keep up with
                >> the technology changes of their customers and colleagues. And they
                >> might even discover some competitive advantages along the way.
                >>
                >> - George
                >>
                >> P.S. I'm always happy to see my name in lights with a link back to my
                >> website, but it's entirely up to you.
                >>
                >> On 9/22/10 12:54 PM, Esther Schindler wrote:
                >>> Howdy, folks. I haven't had the opportunity to hang around in these
                >>> parts recently (drat, haven't gotten to write-or-edit much about
                >>> software dev for a while), but happily that appears to be changing.
                >>>
                >>> I've just been given an assignment to write a short article with the
                >>> working title of "7 Things the Consumerized Enterprise Can Learn From
                >>> Agile Development." The "7" is really&n; the actual number will
                >>> reflect how many points I can come up with. And by "consumerized
                >>> enterprise" I mean large companies that recognize that their users
                >>> are bringing in technology (eg smartphones) without IT's approval but
                >>> expecting some level of support from IT.
                >>>
                >>> For instance, I'm thinking (but haven't yet articulated into a
                >>> "point" yet) that enterprise IT must change its processes to expect
                >>> change and respond quickly to it. This, I think, it can learn from
                >>> Agile in terms of "iterative development." Once, the IT department
                >>> could make declarations about "this is what we support, and if you
                >>> use something else we will point at you and laugh -- at best."
                >>> Nowadays, IT had better be ready to support a user's iPhone to
                >>> connect to the company e-mail... and not simply add that as a
                >>> Supported Product to a list (after 6 months of negotiations).
                >>>
                >>> This isn't meant to be a "he said she said" reported article as much
                >>> as "What Esther thinks about the topic" though if anyone has pithy
                >>> comments I'd be happy to quote you.
                >>>
                >>> Meanwhile... got any suggestions? What should I include on my list?
                >>>
                >>> Esther Schindler
                >>> http://www.twitter.com/estherschindler
                >>
                >> --
                >> ----------------------------------------------------------------------
                >> * George Dinwiddie * http://blog.gdinwiddie.com
                >> Software Development http://www.idiacomputing.com
                >> Consultant and Coach http://www.agilemaryland.org
                >> ----------------------------------------------------------------------
                >>
                >>
                >>
                >> ------------------------------------
                >>
                >> To Post a message, send it to: extremeprogramming@...
                >>
                >> To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                >>
                >> ad-free courtesy of objectmentor.comYahoo! Groups Links
                >>
                >>
                >>
                >>
                >
                >
                >
                > ------------------------------------
                >
                > To Post a message, send it to: extremeprogramming@...
                >
                > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                >
                > ad-free courtesy of objectmentor.comYahoo! Groups Links
                >
                >
                >
                >

                --
                ----------------------------------------------------------------------
                * George Dinwiddie * http://blog.gdinwiddie.com
                Software Development http://www.idiacomputing.com
                Consultant and Coach http://www.agilemaryland.org
                ----------------------------------------------------------------------
              • Brad Appleton
                Hi Esther, not sure I know how best to put this into words but I ll try ... (which means it aint gonna be very brief) One big problem with /Agile /IT (or with
                Message 7 of 9 , Sep 24, 2010
                • 0 Attachment
                  Hi Esther,
                  not sure I know how best to put this into words but I'll try ... (which
                  means it aint gonna be very brief)

                  One big problem with /Agile /IT (or with Agile /your-discipline-here/)
                  is that it can too easily focus on optimizing IT (or one particular
                  discipline) rather than on the whole system and its business-cycle. And
                  these days /Lean /IT seems to be more about reducing IT costs, often at
                  the expense of knowledge-workers productivity or the flow of overall
                  business value.

                  And something I regularly hear from IT folks who are all "into"
                  responding-to-change is that in order to do this effectively at large
                  scale, they need to limit the complexity of the diversity of
                  configurations and combinations thereof that they have to support. This
                  typically leads to the conclusion that they have to have a "common
                  image" comprising the set of approved software packages and versions and
                  configurations they support. They understand the need for variation, and
                  that the "common image" needed by business & marketing folks will be
                  different from the ones needed by software folks and hardware folks,
                  etc. So really there are approximately a half-dozen common images (which
                  share a "core" set of basic office/productivity apps), but they have to
                  limit themselves to supporting just those apps and a limited set of
                  version of those apps.

                  As examples, some shops may insist on supporting for example IE, but not
                  Firefox or Opera or Chrome, or the limited one or two commercial version
                  control tools supported and not Subversion or Git or open-source ones.
                  I'm sure therest of you can think of plenty of other examples as well.

                  On the one hand, it's easy to see their point and sympathize with ...
                  one could regard each of these "variations" as the equivalent of
                  creating another "branch" of the environment they would have to support
                  (and we know branching is evil :) and they want to maintain a single
                  line (or at least as few as possible). [Of course there are better ways
                  than branching for managing some of these kinds or variation, and many
                  of those focus architecture & design techniques instead]

                  At the same time, the "bottom line" for justifying such constraints and
                  imposing uniform commonality on the computing environments supported is
                  often said to come down to "economies of scale." Large enterprises of
                  the nature you mention below are dealing with a very large number of
                  users and machines and applications and other technologies and the
                  argument is that economies of scale apply.

                  But do economies of scale really apply for /Agile IT?/ It would seem
                  many of the big names in Lean/Agile IT think so. In fact, in a recent
                  book (May 2010) entitled *Lean Integration*: An Integration Factory
                  Approach to Business Agility
                  <http://www.amazon.com/Lean-Integration-Addison-Wesley-Information-Technology/dp/0321712315>
                  (which is not about continuous integration, but rather about integration
                  of enterprise systems/applications/data -- see also
                  http://www.integrationfactory.com/ and the wikipedia page on Lean
                  Integration <http://en.wikipedia.org/wiki/Lean_Integration>) the authors
                  state in the online sample chapter What Is Lean Integration and Why Is
                  It Important? <http://www.informit.com/articles/article.aspx?p=1594850>

                  *"Why Lean?" and "So What?"*

                  In financial terms, the value of Lean comes from two
                  sources: economies of scale and reduction in variation.
                  Development of data and process integration points is a
                  manufacturing process. We know from years of research in
                  manufacturing that every time you double volume, costs drop
                  by 15 to 25 percent. There is a point of diminishing returns
                  since it becomes harder and harder to double volume, but it
                  doesn't take too many doublings to realize an
                  order-of-magnitude reduction in cost. Second, we also know
                  that manufacturing production costs increase from 25 to 35
                  percent each time variation doubles. The degree of
                  integration variation today in many organizations is
                  staggering in terms of both the variety of tools that are
                  used and the variety of standards that are applied to their
                  implementation. That is why most organizations have a
                  hairball---thousands of integrations that are "works of art."

                  Some studies by various analyst firms have pegged the cost
                  of integration at 50 to 70 percent of the IT budget. This is
                  huge! Lean Integration achieves both economies of scale and
                  reduction in variation to reduce integration costs by 25
                  percent or more. This book explores some specific case
                  studies that we hope will convince you that not only are
                  these cost savings real, but you can realize them in your
                  organization as well.

                  The statement that struck me was "In financial terms, the value of Lean
                  comes from two sources: economies of scale and reduction in variation"
                  This was because "reduction in variation" sounds to me a lot more like
                  "Six Sigma" rather than Lean's idea of "Standardized Work" (tho I
                  understand the relationship to reducing/eliminating Failure Demand) and
                  also because I vividly remember reading Mary Poppendiecks latest book
                  "Leading Lean Software Development: Results Are not the Point
                  <http://www.informit.com/title/0321620704>" in the section on
                  Policy-Driven Waste where she mentions "Economies of Scale" as one of
                  the most common causes of policy-driven waste:

                  Many of our instincts, policies, and procedures are rooted
                  in the economies of scale, which drove huge improvements in
                  productivity as industrial production replaced craft
                  production in the first half of the twentieth century. But
                  during the second half of that century, it became apparent
                  that in any system with high variety, the economies of flow
                  outperform the economies of scale, even in manufacturing.
                  Software groups develop one-of-a-kind systems---the essence
                  of It should be obvious that we should base our policies and
                  processes on the economies of flow. And yet . . .
                  [...]
                  Lean thinking uses economies of flow, rather than economies
                  of scale, to frame the world we look at. Variety is an
                  essential ingredient of software development, and so we need
                  processes that absorb the variety gracefully.


                  I think IT is very keen on these ideas of /economies of scale/ and
                  /reduction in variation/. I recently saw a set of slides from a
                  presentation Griffin Caprio
                  <http://www.slideshare.net/gcaprio/intro-to-lean-software-development>
                  over the summer where the presenter said /economies of scale/ and
                  /reduction in variation /where not the right models to be applying to
                  software development, and that instead what was needed were /economies
                  of *scope*/* *and /reducing the* economic impact* of variation/. (Also
                  see Griffin's blog-post on this topic
                  <http://blog.1530technologies.com/2010/09/economies-of-scope-scale-flow-for-software-development.html>).

                  Maybe (and I don't claim to know for sure) but perhaps this is one of
                  the key lessons for lean/agile IT to learn from lean/agile software
                  development: in order to optimize economizes of [business-value] flow
                  they need to switch their underlying motivation and focus economies of
                  /scope /and reducing the /economic impact/ of variation. Maybe instead
                  of trying to drastically limit the use of newer/different "consumerized"
                  technologies (granted, some limitations are probably necessary) they
                  should be focusing on how IT can sustain creating and supporting an IT
                  environment that minimizes the impact of those variations upon the rest
                  of their customers, their infrastructure and the enterprise.

                  --
                  Brad Appleton<brad {AT} bradapp.net>
                  Agile CM Environments (http://blog.bradapp.net/)
                  & Software CM Patterns (www.scmpatterns.com)
                  "And miles to go before I sleep" -- Robert Frost



                  On 9/22/2010 11:54 AM, Esther Schindler wrote:
                  >
                  > Howdy, folks. I haven't had the opportunity to hang around in these
                  > parts recently (drat, haven't gotten to write-or-edit much about
                  > software dev for a while), but happily that appears to be changing.
                  >
                  > I've just been given an assignment to write a short article with the
                  > working title of "7 Things the Consumerized Enterprise Can Learn From
                  > Agile Development." The "7" is really &n; the actual number will
                  > reflect how many points I can come up with. And by "consumerized
                  > enterprise" I mean large companies that recognize that their users are
                  > bringing in technology (eg smartphones) without IT's approval but
                  > expecting some level of support from IT.
                  >
                  > For instance, I'm thinking (but haven't yet articulated into a "point"
                  > yet) that enterprise IT must change its processes to expect change and
                  > respond quickly to it. This, I think, it can learn from Agile in terms
                  > of "iterative development." Once, the IT department could make
                  > declarations about "this is what we support, and if you use something
                  > else we will point at you and laugh -- at best." Nowadays, IT had
                  > better be ready to support a user's iPhone to connect to the company
                  > e-mail... and not simply add that as a Supported Product to a list
                  > (after 6 months of negotiations).
                  >
                  > This isn't meant to be a "he said she said" reported article as much
                  > as "What Esther thinks about the topic" though if anyone has pithy
                  > comments I'd be happy to quote you.
                  >
                  > Meanwhile... got any suggestions? What should I include on my list?
                  >
                  > Esther Schindler
                  > http://www.twitter.com/estherschindler
                  >
                  >
                  >
                  > __,_._,__


                  [Non-text portions of this message have been removed]
                • David H
                  ... Having been in that situation myself (as the sys admin) I would never allow the deveolpment team to fuck around with an interface that monitors a live
                  Message 8 of 9 , Sep 30, 2010
                  • 0 Attachment
                    On 10-09-23 1:18 AM, George Dinwiddie wrote:
                    > Esther,
                    >
                    > On 9/22/10 7:03 PM, Esther Schindler wrote:
                    >> George my dear, I am always happy to quote you in my articles,
                    >> because you always make me look smarter. :-)
                    >
                    > I hardly think so, because you look pretty smart already.
                    >
                    >> I agree with your overall assessment but I'm scratching my head to
                    >> come up with an example. Can we imagine a scenario?
                    >
                    > OK, what about this hypothetical scenario: A system admin is going on a
                    > business trip in a few weeks, and wants the web interface that he often
                    > uses customized in a version more usable on a cell phone browser rather
                    > than having to use the company laptop.
                    >
                    > For an experienced Agile team, this is just another change, even if
                    > they've never done a cell phone interface before. The code is already
                    > well factored such that putting a new front end is fairly
                    > straightforward; they just need to learns the ins and outs of what
                    > displays well on the small screen.

                    Having been in that situation myself (as the sys admin) I would never
                    allow the deveolpment team to fuck around with an interface that
                    monitors a live system just to make it prettier on my cell phone. I
                    would rather get myself a better cellphone, such as an iPhone where I
                    can have a half decent, fully featured browser. The one thing you do not
                    do when you are a system adinsitrator is fuck around with a system that
                    is up and running well just because you want a prettier interface to
                    access it. You would usually try it out on a backup system or a system
                    that monitors machines which are not in live use. After that has worked
                    for a while you _might_ transiiton it into the real environment.

                    -d
                  • Clive Evans
                    ... Having become a developer after spending a lot of time as a System Administrator tweaking my control interfaces almost constantly, I d suggest that while
                    Message 9 of 9 , Oct 1, 2010
                    • 0 Attachment
                      On 1 Oct 2010, at 00:34, David H wrote:
                      > Having been in that situation myself (as the sys admin) I would never
                      > allow the deveolpment team to fuck around with an interface that
                      > monitors a live system just to make it prettier on my cell phone. I
                      > would rather get myself a better cellphone, such as an iPhone where I
                      > can have a half decent, fully featured browser. The one thing you do
                      > not
                      > do when you are a system adinsitrator is fuck around with a system
                      > that
                      > is up and running well just because you want a prettier interface to
                      > access it. You would usually try it out on a backup system or a system
                      > that monitors machines which are not in live use. After that has
                      > worked
                      > for a while you _might_ transiiton it into the real environment.
                      >
                      >

                      Having become a developer after spending a lot of time as a System
                      Administrator tweaking my control interfaces almost constantly, I'd
                      suggest that while you may be playing safe, in actuality you're
                      missing out on an opportunity to learn more about running your systems
                      and improve your reliability steadily.

                      Prettier is very important in control systems, as is usability. Being
                      Pretty and usable on devices such as a mobile phone is one of the best
                      things you can aspire to - it takes your time to respond to an
                      incident to almost nothing, regardless of where you are and whether
                      you are on technically duty or not.

                      Clive
                      --
                      Clive Evans
                      "Black holes are where God divides by zero" - anon
                    Your message has been successfully submitted and would be delivered to recipients shortly.