Thursday, December 7

Talk on Design Patterns in Melbourne

M elbourne Patterns Group Meeting
Went to the design patterns talk yesterday.


Steve Hayes turned up. He had just come back from India.

The test patterns talk ended up being a group discussion of the relationship between TDD and good O-O Design. We talked about what made good tests and what made good design.

Steve raised the concept of habitability which comes from the book Patterns of Software by Richard Gabriel.

"Habitability is the characteristic of source code that enables programmers, coders, bug-fixers, and people coming to the code later in its life to understand its construction and intentions and to change it comfortably and confidently. Either there is more to habitability than clarity or the two characteristics are different."

This struck a cord with me and I talked about treating your team members (both present and future) as first class customers who are entitled to find the components you write both easy to use and easy to maintain.






Monday, December 4

Talk on Project Management (Agile and others) in Melbourne


O rganized by the Content Management Professional Australian Community
The panel consisted of six project managers only one of which was using agile and he seamed to think that agile was a watered down version of XP. The panelists had very different backgrounds and could not seam to agree on much of anything.

There was agreement that communicating and building relationship with people was one of the key aspects of project management. Plus the rapid changes in technology within the IT industry makes yesterday's solutions obsolete very quickly and inflexible long range plans foolish.

One of the panelist highlighted the need to keep on asking 'Why?' in order to uncover the root cause of problem. This reminded me of the Toyota Way's practice of asking 'Why?' five times.

Update:  

Related Posts

    Related Information  

    Upcoming Talk on Design Patterns in Melbourne

    MPG Melbourne Patterns Group on 6th December  

    Part 1 - Prototype Pattern by Dave Cameron
    Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype. [Design Patterns, Gamma et al]
    Part 2 - Unit Testing Patterns, by Khali Young
    TDD is not about testing, it's about using tests to create software in a simple, incremental way. Not only does this improve the quality and design of the software, but it also simplifies the development process.
    More Info - Home Page and Forum

    Update:  

    Related Posts







    Sunday, December 3

    Road to Serfdom


    Just finished The Road to Serfdom. Insists that centralized planning inevitably leads to corruption of the original intention of planning, destruction of freedom and moral decay of the individual and hence of society of as a whole. Friedrich Hayek would totally agree with Ken Schwaber about the need to align responsibility and authority. He would totally be in favor of the people responsible for implementing work being the ones to plan it.


    Finished Reading Extreme Programming Explained

    I have just finished reading Kent Beck's Extreme Programming Explained.

    He seems to have backed away from one of the most controversial aspects of extreme programming, the On Site Customer. The first edition practice of On Site Customer has changed to Whole Team which sounds much more like scrum's concept of cross-functional teams. He adds corollary practices which he says are difficult or dangerous to implement before completing the preliminary work of the primary practices of XP. Real Customer Involvement is a corollary practice that seems to be intended to partially offset the effect of ditching On Site Customer for Whole Team as a primary practice. It seams a lot weaker and Beck admits that most teams have real trouble getting adequate access to real customers.

    He also is quite candid about the fact XP will not work unless the organizations real values as opposed to it's professed values are aligned with XPs values.


    Update:  

    Wednesday, November 29

    Agile Project Management With Scrum

    Just read Agile Project Management with Scrum

    Ken Schwaber gives lots of case studies in this. He is not afraid to use his own mistakes as examples to highlight the fact that scrum is a learning process.

    I liked the 'Scrum is art of the possible' sound bite.

    He uses case studies grouped by theme to illustrate proper use of scrum practices topped off with a series of lessons learned sections to nail his points down.
     
    Update:  

    Related Post

    Related Information  


    Tuesday, November 28

    Started Reading Extreme Programming Explained

    With all the detailed information about Extreme Programming on Ward Cunningham's WikiWiki and other sources reading Kent Beck's Extreme Programming Explained never seemed urgent. However I decided that it was about time I went to the primary source.

     


    So far it is quite different from what I have read from other sources (many of which seem to have been based on the first edition). It has a loose style sometimes wandering off topic. However the first sentence grabs your attention. "Extreme Programming is about social change". After more than 10 years experience in the industry I can tell you that it is hard to underestimate the importance of the human factor in software development.

    The neglect of this human factor in traditional approaches and the emphasis of it in agile approaches is what attracted me to agile in the first place.

    Update:  

    Related Posts

      Friday, November 24

      Talk on DotNetNuke on the 28 Nov

      V ICTORIA . NET DEV SIG - 28th November

      Enterprise Development of Dot Net Nuke Modules Part 2 by Philip Beadle

      Topics covered
      • How to use TFS Source Control with DNN Web Application Modules
      • Using Team Build to create installable DNN Modules
      • Unit Testing DNN Modules
      • Using nDoc (for ASP 2.0) to create your documentation
      • Writing a Test Script for your module
      VICTORIA . NET's mission for members in the Middle East - a great business opportunity by Peter Halliday & Maria Papadopoulos
      Topics covered
      • GITEX highlights
      • MMV support
      • Business leads

      Update:  

      Related Posts

      Related Information  

      Benefits of Courage

      Developers face many challenges in the workplace, but one of the most insidious is fear—fear that quietly undermines progress, communication, and quality. It can drive  hesitation, silence, and inaction.  

      Fear of Breaking the System

      You know something needs to change, but you're afraid that change will break something else. This fear is not unfounded—complex systems often behave in unexpected ways.

      Agile practices help. Automated tests—both unit and functional—combined with continuous integration provide a safety net. They allow developers to make changes with confidence, knowing they’ll catch regressions quickly.


      Fear of Admitting You Need Help

      You hit a roadblock. It’s taking longer than expected. But instead of reaching out, you stay stuck—worried you’ll look incompetent.

      Agile practices encourage support. Pair programming and daily stand-ups create regular, low-friction opportunities to raise your hand. But even with these practices in place, it’s vital to foster a psychologically safe environment, where asking for help is seen as professional, not weak.


      Fear of Challenging the Status Quo

      Sometimes the fear is political. You know the approach being suggested has failed before. But do you speak up? Or stay silent to avoid conflict?

      Agile adoption itself takes courage. Whether it’s speaking truth to power or suggesting new ways of working, being honest about risks and past learnings requires tact—and bravery. Managing upwards is part of the job.


      Fear of Saying No

      The timeline gets shorter. The scope stays the same. You know it’s impossible—but saying “no” feels confrontational.

      Agile encourages transparency. Velocity, burn-down charts, and scope control make trade-offs visible. But someone still has to raise the flag and say: if we cut the time, we must cut the scope. That takes courage.


      What Other Fears Have You Faced?

      These aren’t the only fears developers encounter. What have you seen? When did courage make a difference in your work—or when did the lack of it lead to trouble?

      Related Posts

      Thursday, November 23

      Benefits of TDD


      A fter the e-Commerce SIG talk I started chatting with a fellow attendee. We talked about what was not covered by the presentation.

      The conversation drifted toward Test Driven Development (TDD)  —and for good reason. To my mind, there are so many benefits that it’s hard to pick a single winner.

      But TDD isn’t for everyone. If writing tests before writing code feels too extreme, or if you’re working with legacy code that has no tests at all, don’t let the ideal of test-first stop you from writing any unit tests. Start where you can. Something is always better than nothing.

      Here are just a few of the benefits of writing unit tests:

      Confidence Through a Safety Net

      Unit tests give you the confidence to make changes, knowing that regressions will be caught early.

      Pressure to Break Dependencies

      When a module is hard to test, that’s often a clue (a code smell): it has too many dependencies. Testing encourages better separation of concerns.

      Better Object-Oriented Design

      Poorly designed code is hard to test. Unit tests push you toward cleaner, more modular, and more cohesive components.

      External View of Your Component

      Writing tests helps you see your code from the caller’s perspective—which naturally leads to more intuitive APIs and usage patterns.

      Now, ramp that up with TDD—writing the test first—and you get all of the above, plus some added magic:

      Focus on What, Not How

      Starting with a test forces you to clarify what you’re trying to achieve, instead of diving straight into implementation details.

      Discover Code That Already Works

      Sometimes you write a test… and it already passes. Why? Because the system already has that behavior.
      This has led me to delete large sections of legacy code that were—frankly—doing nothing useful.
      (It’s both satisfying and depressing.)

      Stick to What’s Needed

      TDD discourages speculative code. You implement only what the test demands—not what you think might be needed someday.

      The Biggest Benefit

      Ultimately this may be a shift in mindset.


      What About You?
      What other benefits have you experienced with unit testing or TDD?
      What helped you start—or what’s still holding you back?


      Update:  

      Related Posts

        Related Information  

        Agile Development Talk

        I just arrived back from the Agile Development Talk that the ACS e-Commerce SIG put on in Melbourne.


        The presenter was Martin Bauer who has been managing projects using FDD (Feature Driven Development) for 6 years.

        He talked about XP and Scrum as well as FDD. Unfortunately he did not know much about either XP or Scrum. He was on much firmer ground with FDD.

        He did not cover many of what I considered the greatest benefits of agile practices. He did cover the reduced risk of failure and he did emphasize the importance of the human element.

        The organizer suggested getting detailed requirements up front and an IID (Incremental and Iterative Development ) version of Waterfall.

        I told him that requirements were like pornography, the client knows what he wants [the requirements] when he sees it.

        It got a laugh.

        I not sure were I stole that from. Perhaps a kind reader could tell me who originally said it.

        Update:  

        Related Posts

          Related Information  

          Wednesday, November 15

          Agile Estimating And Planning

          The speaker at last nights  Melbourne eXtreme Programming Enthusiasts Group meeting reviewed Agile Estimating and Planning by Mike Cohn.


          He attended a course run by the author. The speaker showed everyone planning poker cards that Mike Cohn gives out. They were a big hit.

          Update:  

          Related Posts

            Related Information  

            Melbourne XP

            Attended the Melbourne eXtreme Programming Enthusiasts Group (MXPEG)p  last night. The topic discussed was Estimating XP stories.


            The conversation was driven by a newcomer to the group. She managed to get a lot out of the group by focusing on the groups collective experience of XP.



            Update: