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

XP and .NET popularity

Expand Messages
  • Kathleen Dollard
    On Tuesday, December 31, 2002, at 1:10:29 AM, David Vydra ... I m coming from the other side. Peeking at you guys through the holes in the fence so to speak. I
    Message 1 of 219 , Jan 1, 2003
    • 0 Attachment
      On Tuesday, December 31, 2002, at 1:10:29 AM, David Vydra
      <groups-xp@...> wrote:

      > I've been noticing lately that many XP luminaries are doing work with
      > .NET.

      > Is it due to:
      > a. .NET is a superior technology
      > b. .NET market is growing fast and we like to eat well
      > c. We want to take revenge on Java for J2EE :)
      > d. .NET apps are significantly simpler to create and deploy than
      > equivalent java apps e. Other____________

      I'm coming from the other side. Peeking at you guys through the holes in
      the fence so to speak. I have pretty much lacked any other life than
      .NET for two years.

      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'll be looking for answers to questions like the following. Yes, I am
      also reading books, but I can't begin to keep up with my .NET reading
      and writing, so the extra XP reading is going very slowly.

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

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

      How does XP respond to major data base changes?

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

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

      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? 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?)

      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#.

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

      (*) 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?"


      Kathleen
    • 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
      • 0 Attachment
        > > 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.