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

Re: [XP] XP and .NET popularity

Expand Messages
  • Phlip
    ... I l soon be into .NET, but I don t know it yet. But I shudder to think there could be a heavily marketed programming system that somehow makes iterations,
    Message 1 of 219 , Jan 1, 2003
      Kathleen Dollard sez:

      > I'll be watching from the sidelines for a while, because from the
      > perspective of .NET I have some real hesitation about XP and I am
      > exploring other techniques to reduce the complexity of .NET programming.
      > This comes from the nature of XP and the type of applications I do.

      I'l soon be into .NET, but I don't know it yet.

      But I shudder to think there could be a heavily marketed programming system
      that somehow makes iterations, testing, or agility hard. There may be
      cultures that do, but not the system itself.

      > What happens to XP in a 400 KLOC - 1,000 KLOC project?

      Nothing. You shouldn't notice the line count, wherever it goes.

      If you do notice it, something is wrong. Most likely, you are not refactoring
      and partitioning your high-level concerns carefully. A big, hard project
      should look and smell just like a lot of little, easy projects, all with
      clean and tiny interfaces to each other.

      Vendors don't teach this, or promote it in their example code, because such
      partitioning defeats their ultimate goal of "vendor-lockin". MS won the
      desktop wars >entirely< by cultivating a culture of rampant VL.

      For example, do any of their sample programs that use a database actually
      encapsulate the SQL statements? Of course not! They just import the SQL layer
      globally, and then write SQL statements everywhere.

      > Doesn't the goal of "simpest thing possible" mean you abandon the n-tier
      > development techniques that have been the heart of business
      > applications?

      Yes. The OnsiteCustomer is not allowed to say "use MS Access", or "use
      3-tiers". If they try, your process is broke and you are not doing XP.

      http://c2.com/cgi/wiki?DeveloperBillOfRights
      http://c2.com/cgi/wiki?CustomerBillOfRights

      They >are< allowed to write user stories that say "I can read the raw program
      data in a spreadsheet format and tweak any row or column in it", and they are
      allowed to say, "The average transaction time will decrease in linear
      proportion to the number of tier servers we install."

      The team is allowed to use flat text files for the database, and run off a
      single server, until the customer says that. The team should have no fear (or
      FUD) that they won't be able to satisfy those user stories easily. In the
      program, OAOO means all those abilities occur once, and so will only need to
      be replaced once.

      And the customer, steering a project with rapid real-time feedback, might
      never discover a need for those abilities.

      > How does XP respond to major data base changes?

      By constantly performing minor ones, and by maintaining a script (itself
      written test-first) that upgrades the database.

      Databases have a terrible legacy of frozen schemas. Don't let them get away
      with it.

      http://c2.com/cgi/wiki?ContinuousDatabaseRefactoring

      > How does XP work if your database is behind other development?

      Won't happen if you release every two weeks. If the database user stories are
      showing a slow velocity, the customer must steer towards a cleaner database.

      > How does XP, outside pair programming (*), work with a
      > language/framework as monstrously complex as .NET?

      By only using that tiny piece of it which they really really need.

      When a programmer performs the refactor "Buy Don't Build", they commit a
      serious investment in the bought tool. Just because that tool is already
      installed, by fiat, on every computer within 1,000 meters does not mean it's
      still really free. Make an economic judgement call, and err on the side of
      thrift.

      Everyone on the team should be able to recite the short list of packages in
      use, and no individual is permitted to add another one without a team
      decision.

      > Does Collective Code Ownership really make sense when it means each
      > developer must understand the Core Framework, Security,
      > ASP.NET/HTML/JavaScript or Windows.Forms/Graphics, Deployment, ADO.NET,
      > Reflection, exceptions, configuration, etc in a context that includes
      > thread safety, performance, garbage collection, serialization, state
      > management, design time, and the hundreds of details that go with each
      > as well as some subset of XML, XSLT, Messaging, Remoting, Directory
      > Services, Enterprise Services, Enterprise Templates, Windows Services,
      > Regular Expressions, etc?

      Absolutely not. CCO does >not< mean everyone must know how to change anything
      at any time. Developers "bid" on User Stories - the lowest bidder will be
      the person most familiar with that part of the system. The GUI Guy will
      usually do the GUI work, the Network Guy will usually do the Network stories,
      and the Database Guy will usually do the Database work.

      CCO means you are not allowed to complain if you (and a pair) wrote a
      beautiful module, then later you discover another pair upgraded its design.

      > I interact with a lot of programmers, and it
      > is hard for me to see the practicality of requiring this much knowledge
      > - there are very, very few, _if any_, programmers capable of this. (And
      > doesn't collective ownership mean they also know database design and
      > stored procedure development and security?)

      XP also decrees "if it doesn't have a test, it doesn't exist." Hence, your
      top-level system needs a test. It is called "super_test"; it checks out the
      latest code, then runs all the tests.

      "Super_test" must run frequently on every developer workstation. If there is
      a problem in the system, some workstations will crash super_test. And those
      developers will learn.

      Do you see how many questions targetting one aspect of XP can be answered by
      applying a diametric opposite aspect? ;-)

      > Why C#, not Visual Basic .NET, when there is almost no difference now
      > and Microsoft's has stated that the difference will be increased RAD in
      > Visual Basic .NET? For example, Eric Gunnerson (C# team-while speaking
      > in Denver in November) seemed surprised at the interest in E&C (edit and
      > continue) for C#.

      Edit and Continue was invented to assist Debugger Based Coding. That's where
      you manually run the debugger over and over again, and edit the code as you
      see its behavior.

      Test-first programmers spend very little time in the debugger. They write the
      tests that simulate the activities they would have used the debugger to
      investigate. Running the tests over and over again debugs over and over
      again. TDD trades 6 hours in the debugger for 1 hour writing tests.

      Visual Basic sucks dead donkeys, but MS will continue to promote it long
      after the last VB programmer gets fired. Serious programmers forced to use MS
      tools learn to filter out and not even notice all the bogus marketing ploys
      MS promotes VB with.

      > From your perspective, what are the top four things that could be done
      > to .NET to make it friendlier to XP?

      Besides crush Microsoft like a bug and turn all its source over to Richard
      Stallman? No, I can't think of anything...

      > (*) I question the requirement of one keyboard/box during pair
      > programming in .NET. Even by myself I sometimes have a second box
      > (laptop) going for the help system (and I know .NET very well). It seems
      > that one person being able to look things up without interrupting the
      > flow of the other, and the flow of the application code on screen would
      > be valuable. I see this as being a smooth sequential flow between the
      > two, not two independent parallel tasks. It is just a different thinking
      > process to ask "How can I find?" instead of "How do I do?"

      Pair Programming is not about bondage or discipline. All the developer
      workstations I've seen or used in the last 4 years had a big desktop computer
      for the project, and a notebook on the side for research, slow-burn projects,
      e-mail and surfing. I have frequently looked up a question with Google while
      a pair on the big box continued to code. This is a blessed and totally
      efficient system to work.

      --
      Phlip
      http://www.greencheese.org/PeaceAndCalm
      -- This machine last rebooted during the Second Millenium --
    • Daniel Sheppard
      ... If the language isn t doing type-checking on you, you wouldn t have had to refactor that test to make it compile. You would have run your tests and see
      Message 219 of 219 , Jan 5, 2003
        > > Well, you had a test that did "new Car(owner)" and asserted
        > that this object
        > > returned what you expected from toString() before you
        > refactored. So you break
        > > your unit test.
        >
        > Yes, that test is in the unit tests for Car. When refactoring
        > Car, I of
        > course changed that one to take an OwnerList, rather than an
        > owner. The
        > problem is with someone who *calls* that method. I'm supposing that I
        > forgot about refactoring DmvImporter as well.

        If the language isn't doing type-checking on you, you wouldn't have had to refactor that test to make it compile.

        You would have run your tests and see that it fails, and your first thought at that point should not be "how do I change the test to make it work?" but "how do I change the code to make it work?". This would have led you to change your toString() method operates correctly regardless of it being an owner or an ownerlist. If you don't have control of all the calling code, or you can't trust yourself to change it all, this is the only solution you should be entertaining.

        Daniel Sheppard

        daniels at pronto.com.au
        #####################################################################################
        This email has been scanned by MailMarshal, an email content filter.
        #####################################################################################
      Your message has been successfully submitted and would be delivered to recipients shortly.