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

Warning for those that have to re-invent the wheel.

Expand Messages
  • geoffrey_slinker
    I have to warn those of you (or us) that find them self re-inventing the wheel. First, and we all know this, that you should not re-invent the wheel unless it
    Message 1 of 20 , Jan 26, 2010
    • 0 Attachment
      I have to warn those of you (or us) that find them self re-inventing the wheel.

      First, and we all know this, that you should not re-invent the wheel unless it is absolutely necessary. Often there is a performance criteria that causes the wheel to be remade.

      I have dealt with four major "new" wheels that I vividly recall.

      1) Memory Manager
      2) WinMac - a port of the Win32 API to the Macintosh
      3) XML parser
      4) The Gadget Library, a replacement for WinForms controls, layout, and UI containment

      All of these have commonalities.
      1) Performance was the driving reason
      2) Replacing well known and highly used functionality
      3) Complex code to give the performance increase
      4) One or two developers owning the code


      The Memory Manager

      The new memory manager allowed a product who's core was indexing and retrieval to be extremely fast on even Intel 386 based machines. Without such speed the product could not have gained the user base that it ultimately maintained.

      The growth of the company and the spreading use of the product allowed for the development of a Unix version. That is where I came into the picture. (My first computer was a Macintosh SE and I had installed an Object C and Object Pascal compiler. So I was Object Oriented and Mac GUI from day one. I got started programming in 1984, a little late I know) Since I was a Mac programmer I also did some Unix development, or another way to read this was I was a Win'tel hater. Youthful convictions run deeper than reason.

      I looked at porting the memory manager to Unix and found that the memory management on Unix was faster, so there was no need for the port. However I had to port the interface of the new memory manager so that I could reuse the "C" code of the product. So a bit of warning, performance issues and the resulting optimizations may not, most likely will not, be of value to cross platform code.

      Finally the memory manager itself was the bottleneck. It was so in two ways. First, as new versions of Windows came out and new compilers came out the native memory manager became faster than the custom one. Second, since the memory manager was developed by one person he could not keep his custom memory manager up to date, he was a bottleneck.

      Eventually the memory manager was removed. Was it necessary? Yes, it was. The company would not have grown to the point where the memory manager became obsolete if it hadn't have sold well allowing the company to stay in business and grow.

      The memory manager should have been architected differently. The issue was it had its own procedure calls completely different than "Stdlib". If the interface would have been the same as the standard memory manager then it would have been a simple swap out. So, when replacing something like the memory manager, stick to the interfaces so that it is a compile time or link time switch that uses the desired memory manager.


      WinMac - a port of the Win32 API to the Macintosh

      A good friend of mine took the task of porting a Win32 application to the Macintosh. He is an excellent programmer and therefore there is no coding task that he will not consider as the correct solution to the problem. (I on the otherhand will say, 'Yes it can be coded, but should it be coded?')

      To make a long story short he decided to get the Windows code to compile on the Mac without any modification to the code. Sounds good to management, one code base, all new Windows functionality is immediately available on the Mac. In those days no one even considered if it was legal, those types of legal issues had never been spoken of.

      Well, he got behind, had no one to bounce ideas off of, and so they decided to hire someone to help. That is where I come in. The pay raise was around 15%, who could say no.

      There were some big problems.

      1) The WinMac library was a subset of Win32. It only contained a port of the Win32 calls that were made by the Windows product.

      2) Macintosh OS 7 (8 and 9, and those before) is an event based model with one main event loop and cooperative multitasking. (I have dealt with crazy Mac programmers that coded up multiple event loops! Shame on them. SHAME.) Windows is a message based UI with crazy message pumps and all of those message id's, etc.

      3) No specification of Win32. Just run it, use the event spy, and figure it out. There was documentation on how to developer for WIn32, but not a specification on how Win32 was developed.

      4) Bugs in Windows.

      As we developed on the single code base we quickly found ourselve's downstream of the changes made to the Windows product. We would get the code compiling and then a few days later get code again to find that some developer called some new Windows API that we hadn't ported yet. We ended up porting the vast majority of the entire Windows API.

      Also, we found many bugs in Windows and the order of messages. The documentation would state a certain series of messages but the event spy showed at runtime that Windows did not do it that way. So, we had to mimic even the bugs.

      Finally my friend got into a workplace polictical conflict with management and left me all alone.

      Lesson learned, it is better to port ideas than it is code!


      The XML parser

      Once again performance was the issue. I do admit the developers I work with have a good vision for the future and when XML was very young the idea of using it for making calls to servers through http was leading edge. So, as SOAP is coming into existence the company has moved far ahead. Standard emerge and the team keeps the code up to date as best as they can. However, the XML that was used to test the custom XML parser was unique in that all attributes where in double quotes. No one, by habbit or dumb luck, ever passed xml that had attributes in single quotes. Well, that is where I come in. I had started using XML later and had used the libraries that came with the IDE. I spent several days trying to debug code that was an http call passing xml to a server and I kept getting exceptions. My XML was valid, I had checked in many times, had others look at it, etc. One of the "old timers" noticed the single quotes and said, "There's the problem".

      As the company grew rapidly the new/younger developers started writing SOAP implementations and now there were both worlds in existense at the same time. At first SOAP was slower and those that used it got chastized by the old timers for not stepping up and learning the proprietary solution. But, eventually SOAP gets the performance it needs.

      Lesson learned here is that if you are have a replacement for something in which there are standards then you have to keep up with the standard. The personel working of the code is the bottleneck. Typically an update in a standard is significant and you get it dumped upon you all at once. Therefore you find yourself picking and chosing and therefore you are now noncompliant.



      The Gadget Library, a replacement for WinForms controls, layout, and UI containment

      This is my most recent experience. Performance was the issue, that and the inability to create thousands of Controls dynamically, to draw all of these controls to offscreen bitmaps, or to visuall scale/zoom all of the controls.

      Because I have replaced WinForm's controls, completely replaced them I find myself the bottleneck to getting in new functionality. Imagine just one guy owning the WinForms classes for Microsoft. Each bug, each new feature, each change is huge. The amount of code to keep in one's head is tremendous as well.

      The issue is that UI components and their abilities are a commodity now. When I developed a gadget it was coded to do just what was needed and nothing extra. YAGNI was the driving mantra. Users are unaware that the Gadget library exists, it all looks like Windows to them. So, they say, "We would like it do X". "X" would be easy enough if I was using WinForm's controls. The users expect it and management doesn't necessarily see the difficulty in asking for it. But it is starting to wear me out. Too much code, too much responsibility, to much complexity, just too dang much.

      The lesson learned here is when replacing a UI commodity, you should fully replace it in most cases. Fully means, full functionality implemented, all of the behavior of the original.



      I hope these experiences help someone else.

      Geoff
    • Ron Jeffries
      Hello, geoffrey_slinker. On Tuesday, January 26, 2010, at ... um ... Ron Jeffries www.XProgramming.com www.xprogramming.com/blog Make it real or else forget
      Message 2 of 20 , Jan 26, 2010
      • 0 Attachment
        Hello, geoffrey_slinker. On Tuesday, January 26, 2010, at
        10:24:10 AM, you wrote:

        > To make a long story short ...

        um ...

        Ron Jeffries
        www.XProgramming.com
        www.xprogramming.com/blog
        Make it real or else forget about it -- Carlos Santana
      • Victor
        Independently of the length, it was a good story. :-) Víctor ... From: Ron Jeffries To: Sent:
        Message 3 of 20 , Jan 26, 2010
        • 0 Attachment
          Independently of the length, it was a good story. :-)

          Víctor

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

          ----- Original Message -----
          From: "Ron Jeffries" <ronjeffries@...>
          To: <extremeprogramming@yahoogroups.com>
          Sent: Tuesday, January 26, 2010 11:37 AM
          Subject: Re: [XP] Warning for those that have to re-invent the wheel.


          > Hello, geoffrey_slinker. On Tuesday, January 26, 2010, at
          > 10:24:10 AM, you wrote:
          >
          >> To make a long story short ...
          >
          > um ...
          >
          > Ron Jeffries
          > www.XProgramming.com
          > www.xprogramming.com/blog
          > Make it real or else forget about it -- Carlos Santana
          >
          >
          >
          > ------------------------------------
          >
          > 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
          >
          >
          >
          >
        • Sebastian
          Instead of re-inventing the wheel, why not invent a circular transportation facilitation device ? see:
          Message 4 of 20 , Jan 26, 2010
          • 0 Attachment
            Instead of re-inventing the wheel, why not invent a "circular transportation facilitation device" ?

            see:
            http://www.newscientist.com/article/dn965-wheel-patented-in-australia.html
          • geoffrey_slinker
            ... Okay, a version for my old online friend Mr. Jeffries (after he suffered through reading the other) Don t reinvent the wheel unless you have to. Then be
            Message 5 of 20 , Jan 26, 2010
            • 0 Attachment
              :-)

              Okay, a version for my old "online" friend Mr. Jeffries (after he suffered through reading the other)

              Don't reinvent the wheel unless you have to. Then be prepared for your new wheel to be replaced by a newer version of the old wheel. If your wheel is a "commodity" piece then it had better have all of the bells and whistles of the original wheel. (I love wheels that have bells and whistles on them, I have a set on my car.)

              Geoff



              --- In extremeprogramming@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
              >
              > Hello, geoffrey_slinker. On Tuesday, January 26, 2010, at
              > 10:24:10 AM, you wrote:
              >
              > > To make a long story short ...
              >
              > um ...
              >
              > Ron Jeffries
              > www.XProgramming.com
              > www.xprogramming.com/blog
              > Make it real or else forget about it -- Carlos Santana
              >
            • JeffGrigg
              ... Build a better wheel and the world will roll a path to your door. -- Ralph Waldo Emerson [NOT!] ;-
              Message 6 of 20 , Jan 26, 2010
              • 0 Attachment
                --- "geoffrey_slinker" <geoffrey_slinker@...> wrote:
                > I have to warn those of you (or us) that find them self
                > re-inventing the wheel.

                "Build a better wheel and the world will roll a path to your door."
                -- Ralph Waldo Emerson [NOT!] ;->
              • Curtis Cooley
                ... highways on circular pieces of carved stone connected by logs? -- Curtis Cooley curtis.cooley@gmail.com home:http://curtiscooley.com
                Message 7 of 20 , Jan 26, 2010
                • 0 Attachment
                  On Tue, Jan 26, 2010 at 10:31 AM, JeffGrigg <jeffgrigg@...> wrote:

                  >
                  >
                  > --- "geoffrey_slinker" <geoffrey_slinker@...> wrote:
                  > > I have to warn those of you (or us) that find them self
                  > > re-inventing the wheel.
                  >
                  > "Build a better wheel and the world will roll a path to your door."
                  > -- Ralph Waldo Emerson [NOT!] ;->
                  >
                  > If nobody ever re-invented the wheel, wouldn't we be rolling around our
                  highways on circular pieces of carved stone connected by logs?
                  --
                  Curtis Cooley
                  curtis.cooley@...
                  home:http://curtiscooley.com
                  blog:http://ponderingobjectorienteddesign.blogspot.com
                  ===============
                  Leadership is a potent combination of strategy and character. But if you
                  must be without one, be without the strategy.
                  -- H. Norman Schwarzkopf


                  [Non-text portions of this message have been removed]
                • Bill Caputo
                  ... No, they d be round cross-sections of logs cut by stone tools -- and we d probably be stuck in the mud of animal-made trails that meander through an
                  Message 8 of 20 , Jan 26, 2010
                  • 0 Attachment
                    On Tue, Jan 26, 2010 at 2:00 PM, Curtis Cooley <curtis.cooley@...> wrote:
                    > If nobody ever re-invented the wheel, wouldn't we be rolling around our
                    > highways on circular pieces of carved stone connected by logs?

                    No, they'd be round cross-sections of logs cut by stone tools -- and
                    we'd probably be stuck in the mud of animal-made trails that meander
                    through an increasingly logged landscape (well, that last part hasn't
                    changed anyway).

                    Bill
                  • Adam Sroka
                    ... Might there be a useful distinction between reinvention and innovation?
                    Message 9 of 20 , Jan 26, 2010
                    • 0 Attachment
                      On Tue, Jan 26, 2010 at 12:00 PM, Curtis Cooley <curtis.cooley@...> wrote:
                      >
                      >
                      >
                      > On Tue, Jan 26, 2010 at 10:31 AM, JeffGrigg <jeffgrigg@...> wrote:
                      >
                      > >
                      > >
                      > > --- "geoffrey_slinker" <geoffrey_slinker@...> wrote:
                      > > > I have to warn those of you (or us) that find them self
                      > > > re-inventing the wheel.
                      > >
                      > > "Build a better wheel and the world will roll a path to your door."
                      > > -- Ralph Waldo Emerson [NOT!] ;->
                      > >
                      > > If nobody ever re-invented the wheel, wouldn't we be rolling around our
                      > highways on circular pieces of carved stone connected by logs?

                      Might there be a useful distinction between reinvention and innovation?
                    • Curtis Cooley
                      ... There is, reinvent means to cast something old into a new light, innovate means to introduce something new. Taking something that exists and changing it is
                      Message 10 of 20 , Jan 26, 2010
                      • 0 Attachment
                        On Tue, Jan 26, 2010 at 12:18 PM, Adam Sroka <adam.sroka@...> wrote:

                        >
                        >
                        > On Tue, Jan 26, 2010 at 12:00 PM, Curtis Cooley <curtis.cooley@...<curtis.cooley%40gmail.com>>
                        > wrote:
                        > >
                        > >
                        > >
                        > > On Tue, Jan 26, 2010 at 10:31 AM, JeffGrigg <jeffgrigg@...<jeffgrigg%40charter.net>>
                        > wrote:
                        > >
                        > > >
                        > > >
                        > > > --- "geoffrey_slinker" <geoffrey_slinker@...> wrote:
                        > > > > I have to warn those of you (or us) that find them self
                        > > > > re-inventing the wheel.
                        > > >
                        > > > "Build a better wheel and the world will roll a path to your door."
                        > > > -- Ralph Waldo Emerson [NOT!] ;->
                        > > >
                        > > > If nobody ever re-invented the wheel, wouldn't we be rolling around our
                        > > highways on circular pieces of carved stone connected by logs?
                        >
                        > Might there be a useful distinction between reinvention and innovation?
                        >

                        There is, reinvent means to cast something old into a new light, innovate
                        means to introduce something new. Taking something that exists and changing
                        it is not innovation, by definition:
                        http://www.thefreedictionary.com/innovate but taking something that exists
                        and starting from scratch to produce something possibly better is
                        reinventing.

                        Of course, "reinvent the wheel" is a common phrase meant to indicate
                        worthless and wasted effort. I just wonder why. Automakers and tire
                        manufacturers reinvent the wheel all the time. Heck, Volvo has a car with
                        electric motors in each wheel, meaning no differential or transmission.
                        That's a heck of a reinvention of the wheel if you ask me :)

                        http://www.gizmag.com/go/7975/

                        It sounds a lot like to test or not to test. Should I reinvent the wheel? It
                        depends.
                        --
                        Curtis Cooley
                        curtis.cooley@...
                        home:http://curtiscooley.com
                        blog:http://ponderingobjectorienteddesign.blogspot.com
                        ===============
                        Leadership is a potent combination of strategy and character. But if you
                        must be without one, be without the strategy.
                        -- H. Norman Schwarzkopf


                        [Non-text portions of this message have been removed]
                      • Adam Sroka
                        ... It sometimes means that. As in, he reinvented himself. It clearly does not always mean that. The more usual meaning is to invent again something which
                        Message 11 of 20 , Jan 26, 2010
                        • 0 Attachment
                          On Tue, Jan 26, 2010 at 12:45 PM, Curtis Cooley <curtis.cooley@...> wrote:
                          >
                          >
                          >
                          > On Tue, Jan 26, 2010 at 12:18 PM, Adam Sroka <adam.sroka@...> wrote:
                          >
                          > >
                          > >
                          > > On Tue, Jan 26, 2010 at 12:00 PM, Curtis Cooley <curtis.cooley@...<curtis.cooley%40gmail.com>>
                          > > wrote:
                          > > >
                          > > >
                          > > >
                          > > > On Tue, Jan 26, 2010 at 10:31 AM, JeffGrigg <jeffgrigg@...<jeffgrigg%40charter.net>>
                          >
                          > > wrote:
                          > > >
                          > > > >
                          > > > >
                          > > > > --- "geoffrey_slinker" <geoffrey_slinker@...> wrote:
                          > > > > > I have to warn those of you (or us) that find them self
                          > > > > > re-inventing the wheel.
                          > > > >
                          > > > > "Build a better wheel and the world will roll a path to your door."
                          > > > > -- Ralph Waldo Emerson [NOT!] ;->
                          > > > >
                          > > > > If nobody ever re-invented the wheel, wouldn't we be rolling around our
                          > > > highways on circular pieces of carved stone connected by logs?
                          > >
                          > > Might there be a useful distinction between reinvention and innovation?
                          > >
                          >
                          > There is, reinvent means to cast something old into a new light,

                          It sometimes means that. As in, "he reinvented himself." It clearly
                          does not always mean that. The more usual meaning is "to invent again
                          something which has already been invented."

                          http://en.wiktionary.org/wiki/reinvent

                          innovate
                          > means to introduce something new. Taking something that exists and changing
                          > it is not innovation, by definition:
                          > http://www.thefreedictionary.com/innovate

                          From the Latin innovare which means "to make new."

                          The definition you referenced includes "to introduce /as if for the
                          first time/." There is nothing about the definition that remotely
                          suggests that innovation cannot build upon existing ideas. Neither is
                          that remotely similar to the colloquial usage.

                          What I get from the definitions of those two words is that an
                          innovation must be something new, but could be based on something that
                          exists. Whereas, a reinvention must be based on something new, but
                          need not necessarily be any different than what came before, and
                          certainly does not imply improvement.
                        • Adam Sroka
                          ... Clearly what I meant to say was that a reinvention must be based on something that exists.
                          Message 12 of 20 , Jan 26, 2010
                          • 0 Attachment
                            On Tue, Jan 26, 2010 at 1:14 PM, Adam Sroka <adam.sroka@...> wrote:
                            >Whereas, a reinvention must be based on something new, but
                            > need not necessarily be any different than what came before, and
                            > certainly does not imply improvement.
                            >

                            Clearly what I meant to say was that a reinvention must be based on
                            something that exists.
                          • D'Arcy J.M. Cain
                            On Tue, 26 Jan 2010 12:00:34 -0800 ... -- D Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ |
                            Message 13 of 20 , Jan 26, 2010
                            • 0 Attachment
                              On Tue, 26 Jan 2010 12:00:34 -0800
                              Curtis Cooley <curtis.cooley@...> wrote:
                              > > If nobody ever re-invented the wheel, wouldn't we be rolling around our
                              > highways on circular pieces of carved stone connected by logs?



                              --
                              D'Arcy J.M. Cain <darcy@...> | Democracy is three wolves
                              http://www.druid.net/darcy/ | and a sheep voting on
                              +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.


                              [Non-text portions of this message have been removed]
                            • D'Arcy J.M. Cain
                              On Tue, 26 Jan 2010 16:19:45 -0500 ... Yoink! It was just a small image. http://www.druid.net/darcy/mtf.jpg -- D Arcy J.M. Cain |
                              Message 14 of 20 , Jan 26, 2010
                              • 0 Attachment
                                On Tue, 26 Jan 2010 16:19:45 -0500
                                "D'Arcy J.M. Cain" <darcy@...> wrote:
                                > On Tue, 26 Jan 2010 12:00:34 -0800
                                > Curtis Cooley <curtis.cooley@...> wrote:
                                > > > If nobody ever re-invented the wheel, wouldn't we be rolling around our
                                > > highways on circular pieces of carved stone connected by logs?
                                > [Non-text portions of this message have been removed]

                                Yoink! It was just a small image. http://www.druid.net/darcy/mtf.jpg

                                --
                                D'Arcy J.M. Cain <darcy@...> | Democracy is three wolves
                                http://www.druid.net/darcy/ | and a sheep voting on
                                +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
                              • Peter Bell
                                I m finding myself doing an increasing amount of consulting with early stage start ups. Often the tech teams are either inexperienced or I m actually tasked
                                Message 15 of 20 , Apr 7, 2011
                                • 0 Attachment
                                  I'm finding myself doing an increasing amount of consulting with early stage start ups. Often the tech teams are either inexperienced or I'm actually tasked with some part of the recruiting process to build a team around some code I've delivered for the client.

                                  One of the challenge I run into with the people starting businesses is that they don't know much about best practices for managing software teams (why would they - that's one of the reasons they bring me in).

                                  My question relates primarily to sustainable pace. Strangely enough I'm not having a hard time selling (some) pairing. I have no issue selling TDD or building some time into each story to do refactoring. I get a lot of pushback initially on not interrupting scrums, but once we get into a process and get the management educated that goes away.

                                  What I *am* getting push back on is the idea of sustainable pace. Idea X, after all, is the one true idea that will change the world. The founder has decided to give up sleep until 2015 to build the next big thing. They're paying (what seems to them like) crazy salaries for Rails developers with experience, and they want to get everything they can out of their investment.

                                  There is both the fallacy of "if only we pushed them harder they'd deliver more" and the "if only they stayed 16 hours a day we'd be done in half the time". I'm looking for metaphors, research, suggestions, blog postings, whatever that supports the idea of sustainable pace in the early days of a start-up. Much of what I use elsewhere gets countered with the "yeah, but they are established so they can afford to take a little longer".

                                  Any thoughts or suggestions much appreciated.

                                  Best Wishes,
                                  Peter
                                • Ron Jeffries
                                  Hello, Peter. On Thursday, April 7, 2011, at 2:54:13 PM, you ... Ask them if they would like to get their next brain surgery done by a surgeon who works 15
                                  Message 16 of 20 , Apr 7, 2011
                                  • 0 Attachment
                                    Hello, Peter. On Thursday, April 7, 2011, at 2:54:13 PM, you
                                    wrote:

                                    > What I *am* getting push back on is the idea of sustainable pace.
                                    > Idea X, after all, is the one true idea that will change the
                                    > world. The founder has decided to give up sleep until 2015 to
                                    > build the next big thing. They're paying (what seems to them like)
                                    > crazy salaries for Rails developers with experience, and they want
                                    > to get everything they can out of their investment.

                                    > There is both the fallacy of "if only we pushed them harder
                                    > they'd deliver more" and the "if only they stayed 16 hours a day
                                    > we'd be done in half the time". I'm looking for metaphors,
                                    > research, suggestions, blog postings, whatever that supports the
                                    > idea of sustainable pace in the early days of a start-up. Much of
                                    > what I use elsewhere gets countered with the "yeah, but they are
                                    > established so they can afford to take a little longer".

                                    > Any thoughts or suggestions much appreciated.

                                    Ask them if they would like to get their next brain surgery done by
                                    a surgeon who works 15 hours a day.

                                    Ron Jeffries
                                    www.XProgramming.com
                                    Yesterday's code should be as good as we could make it yesterday.
                                    The fact that we know more today, and are more capable today,
                                    is good news about today, not bad news about yesterday.
                                  • Steven Gordon
                                    A couple of useful metaphors where it is well know that being greedy is counterproductive: * Server utilization - it is well known that letting utilization go
                                    Message 17 of 20 , Apr 7, 2011
                                    • 0 Attachment
                                      A couple of useful metaphors where it is well know that being greedy is
                                      counterproductive:

                                      * Server utilization - it is well known that letting utilization go above
                                      80% increases wait time, yet one would naively think that getting more work
                                      out of the servers would make the work go faster.

                                      * Freeway entrance ramp meters - those traffic lights at the ends of freeway
                                      entrance ramps increase effective freeway capacity during rush hours even
                                      though they reduce the number of vehicles using the freeway at any given
                                      time.

                                      Of course, the real reason is that software development is knowledge work,
                                      not rote labor. Tire people make mistakes that will later cost more time
                                      than was saved. Just redoing the work is usually not enough. Not only is
                                      there the additional work of detecting and finding the erroneous work, but
                                      other work based on that erroneous work may also have to be redone.

                                      SteveG



                                      On Thu, Apr 7, 2011 at 11:54 AM, Peter Bell <lists@...> wrote:

                                      >
                                      >
                                      > I'm finding myself doing an increasing amount of consulting with early
                                      > stage start ups. Often the tech teams are either inexperienced or I'm
                                      > actually tasked with some part of the recruiting process to build a team
                                      > around some code I've delivered for the client.
                                      >
                                      > One of the challenge I run into with the people starting businesses is that
                                      > they don't know much about best practices for managing software teams (why
                                      > would they - that's one of the reasons they bring me in).
                                      >
                                      > My question relates primarily to sustainable pace. Strangely enough I'm not
                                      > having a hard time selling (some) pairing. I have no issue selling TDD or
                                      > building some time into each story to do refactoring. I get a lot of
                                      > pushback initially on not interrupting scrums, but once we get into a
                                      > process and get the management educated that goes away.
                                      >
                                      > What I *am* getting push back on is the idea of sustainable pace. Idea X,
                                      > after all, is the one true idea that will change the world. The founder has
                                      > decided to give up sleep until 2015 to build the next big thing. They're
                                      > paying (what seems to them like) crazy salaries for Rails developers with
                                      > experience, and they want to get everything they can out of their
                                      > investment.
                                      >
                                      > There is both the fallacy of "if only we pushed them harder they'd deliver
                                      > more" and the "if only they stayed 16 hours a day we'd be done in half the
                                      > time". I'm looking for metaphors, research, suggestions, blog postings,
                                      > whatever that supports the idea of sustainable pace in the early days of a
                                      > start-up. Much of what I use elsewhere gets countered with the "yeah, but
                                      > they are established so they can afford to take a little longer".
                                      >
                                      > Any thoughts or suggestions much appreciated.
                                      >
                                      > Best Wishes,
                                      > Peter
                                      >
                                      >
                                      >


                                      [Non-text portions of this message have been removed]
                                    • Steve Freeman
                                      ... If your team is pairing, then a coding session is like taking a hard exam. It s not routine work, and if it is then that work should be automated. One
                                      Message 18 of 20 , Apr 10, 2011
                                      • 0 Attachment
                                        On 7 Apr 2011, at 19:54, Peter Bell wrote:
                                        > What I *am* getting push back on is the idea of sustainable pace. Idea X, after all, is the one true idea that will change the world. The founder has decided to give up sleep until 2015 to build the next big thing. They're paying (what seems to them like) crazy salaries for Rails developers with experience, and they want to get everything they can out of their investment.
                                        >
                                        > There is both the fallacy of "if only we pushed them harder they'd deliver more" and the "if only they stayed 16 hours a day we'd be done in half the time". I'm looking for metaphors, research, suggestions, blog postings, whatever that supports the idea of sustainable pace in the early days of a start-up. Much of what I use elsewhere gets countered with the "yeah, but they are established so they can afford to take a little longer".

                                        If your team is pairing, then a coding session is like taking a hard exam. It's not routine work, and if it is then that work should be automated. One option might be to have them actually pair for a session and see what the work is like. The other thing is to look for occasions where people screwed up through tiredness and make sure that comes up in the retrospectives.

                                        Meanwhile, I have a hard-enough time getting the developers to take breaks...

                                        S.

                                        Steve Freeman
                                        http://www.growing-object-oriented-software.com
                                      • Kay
                                        Hi, Steve, Failing frequently, which happens when one is tired and not doing one s best, as in the case of having to produce less than quality work can build
                                        Message 19 of 20 , May 20, 2011
                                        • 0 Attachment
                                          Hi, Steve,

                                          Failing frequently, which happens when one is tired and not doing one's best, as in the case of having to produce less than quality work can build up to a consciousness of failure. This can reduce effectiveness not only in the present but into the future if it is not corrected.

                                          Success builds on success. Another reason for sustainable pace.

                                          Kay Pentecost

                                          --- In extremeprogramming@yahoogroups.com, Steven Gordon <sgordonphd@...> wrote:
                                          >
                                          > A couple of useful metaphors where it is well know that being greedy is
                                          > counterproductive:
                                          >
                                          > * Server utilization - it is well known that letting utilization go above
                                          > 80% increases wait time, yet one would naively think that getting more work
                                          > out of the servers would make the work go faster.
                                          >
                                          > * Freeway entrance ramp meters - those traffic lights at the ends of freeway
                                          > entrance ramps increase effective freeway capacity during rush hours even
                                          > though they reduce the number of vehicles using the freeway at any given
                                          > time.
                                          >
                                          > Of course, the real reason is that software development is knowledge work,
                                          > not rote labor. Tire people make mistakes that will later cost more time
                                          > than was saved. Just redoing the work is usually not enough. Not only is
                                          > there the additional work of detecting and finding the erroneous work, but
                                          > other work based on that erroneous work may also have to be redone.
                                          >
                                          > SteveG
                                          >
                                          >
                                          >
                                          > On Thu, Apr 7, 2011 at 11:54 AM, Peter Bell <lists@...> wrote:
                                          >
                                          > >
                                          > >
                                          > > I'm finding myself doing an increasing amount of consulting with early
                                          > > stage start ups. Often the tech teams are either inexperienced or I'm
                                          > > actually tasked with some part of the recruiting process to build a team
                                          > > around some code I've delivered for the client.
                                          > >
                                          > > One of the challenge I run into with the people starting businesses is that
                                          > > they don't know much about best practices for managing software teams (why
                                          > > would they - that's one of the reasons they bring me in).
                                          > >
                                          > > My question relates primarily to sustainable pace. Strangely enough I'm not
                                          > > having a hard time selling (some) pairing. I have no issue selling TDD or
                                          > > building some time into each story to do refactoring. I get a lot of
                                          > > pushback initially on not interrupting scrums, but once we get into a
                                          > > process and get the management educated that goes away.
                                          > >
                                          > > What I *am* getting push back on is the idea of sustainable pace. Idea X,
                                          > > after all, is the one true idea that will change the world. The founder has
                                          > > decided to give up sleep until 2015 to build the next big thing. They're
                                          > > paying (what seems to them like) crazy salaries for Rails developers with
                                          > > experience, and they want to get everything they can out of their
                                          > > investment.
                                          > >
                                          > > There is both the fallacy of "if only we pushed them harder they'd deliver
                                          > > more" and the "if only they stayed 16 hours a day we'd be done in half the
                                          > > time". I'm looking for metaphors, research, suggestions, blog postings,
                                          > > whatever that supports the idea of sustainable pace in the early days of a
                                          > > start-up. Much of what I use elsewhere gets countered with the "yeah, but
                                          > > they are established so they can afford to take a little longer".
                                          > >
                                          > > Any thoughts or suggestions much appreciated.
                                          > >
                                          > > Best Wishes,
                                          > > Peter
                                          > >
                                          > >
                                          > >
                                          >
                                          >
                                          > [Non-text portions of this message have been removed]
                                          >
                                        • Kay
                                          And to respond to my own post: Great quote from Chad Fowler s _The Passionate Programmer_: So, I learned from this that people can significantly improve or
                                          Message 20 of 20 , May 20, 2011
                                          • 0 Attachment
                                            And to respond to my own post:

                                            Great quote from Chad Fowler's _The Passionate Programmer_: "So, I learned from this that people can significantly improve or regress
                                            in skill, purely based on who they are performing with. And, prolonged
                                            experience with a group can have a lasting impact on one's
                                            ability to perform."

                                            --- In extremeprogramming@yahoogroups.com, "Kay" <tranzpupy@...> wrote:
                                            >
                                            > Hi, Steve,
                                            >
                                            > Failing frequently, which happens when one is tired and not doing one's best, as in the case of having to produce less than quality work can build up to a consciousness of failure. This can reduce effectiveness not only in the present but into the future if it is not corrected.
                                            >
                                            > Success builds on success. Another reason for sustainable pace.
                                            >
                                            > Kay Pentecost
                                            >
                                            > --- In extremeprogramming@yahoogroups.com, Steven Gordon <sgordonphd@> wrote:
                                            > >
                                            > > A couple of useful metaphors where it is well know that being greedy is
                                            > > counterproductive:
                                            > >
                                            > > * Server utilization - it is well known that letting utilization go above
                                            > > 80% increases wait time, yet one would naively think that getting more work
                                            > > out of the servers would make the work go faster.
                                            > >
                                            > > * Freeway entrance ramp meters - those traffic lights at the ends of freeway
                                            > > entrance ramps increase effective freeway capacity during rush hours even
                                            > > though they reduce the number of vehicles using the freeway at any given
                                            > > time.
                                            > >
                                            > > Of course, the real reason is that software development is knowledge work,
                                            > > not rote labor. Tire people make mistakes that will later cost more time
                                            > > than was saved. Just redoing the work is usually not enough. Not only is
                                            > > there the additional work of detecting and finding the erroneous work, but
                                            > > other work based on that erroneous work may also have to be redone.
                                            > >
                                            > > SteveG
                                            > >
                                            > >
                                            > >
                                            > > On Thu, Apr 7, 2011 at 11:54 AM, Peter Bell <lists@> wrote:
                                            > >
                                            > > >
                                            > > >
                                            > > > I'm finding myself doing an increasing amount of consulting with early
                                            > > > stage start ups. Often the tech teams are either inexperienced or I'm
                                            > > > actually tasked with some part of the recruiting process to build a team
                                            > > > around some code I've delivered for the client.
                                            > > >
                                            > > > One of the challenge I run into with the people starting businesses is that
                                            > > > they don't know much about best practices for managing software teams (why
                                            > > > would they - that's one of the reasons they bring me in).
                                            > > >
                                            > > > My question relates primarily to sustainable pace. Strangely enough I'm not
                                            > > > having a hard time selling (some) pairing. I have no issue selling TDD or
                                            > > > building some time into each story to do refactoring. I get a lot of
                                            > > > pushback initially on not interrupting scrums, but once we get into a
                                            > > > process and get the management educated that goes away.
                                            > > >
                                            > > > What I *am* getting push back on is the idea of sustainable pace. Idea X,
                                            > > > after all, is the one true idea that will change the world. The founder has
                                            > > > decided to give up sleep until 2015 to build the next big thing. They're
                                            > > > paying (what seems to them like) crazy salaries for Rails developers with
                                            > > > experience, and they want to get everything they can out of their
                                            > > > investment.
                                            > > >
                                            > > > There is both the fallacy of "if only we pushed them harder they'd deliver
                                            > > > more" and the "if only they stayed 16 hours a day we'd be done in half the
                                            > > > time". I'm looking for metaphors, research, suggestions, blog postings,
                                            > > > whatever that supports the idea of sustainable pace in the early days of a
                                            > > > start-up. Much of what I use elsewhere gets countered with the "yeah, but
                                            > > > they are established so they can afford to take a little longer".
                                            > > >
                                            > > > Any thoughts or suggestions much appreciated.
                                            > > >
                                            > > > Best Wishes,
                                            > > > Peter
                                            > > >
                                            > > >
                                            > > >
                                            > >
                                            > >
                                            > > [Non-text portions of this message have been removed]
                                            > >
                                            >
                                          Your message has been successfully submitted and would be delivered to recipients shortly.