Talk on Design Patterns in Melbourne

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.

Update:  2009

Related Posts

• Melbourne User Groups 
• Melbourne Patterns Group Home Page 
• Melbourne Patterns Group Forum

Talk on Project Management (Agile and others) in Melbourne

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:  2010

Related Posts

• 5 Whys
• Melbourne User Groups 
• Online Resources

Related Information

• Melbourne Scrum User Group (The replacement for MXPEG)

Upcoming Talk on Design Patterns in Melbourne

PG 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:  2009

Related Posts

• Melbourne User Groups 
• Melbourne Patterns Group Home Page 
• Melbourne Patterns Group Forum

Road to Serfdom

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

Update: 2009

Related Posts

• Agile Project Management with Scrum
• Software Development Book List

Finished Reading Extreme Programming Explained

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:  2009

Related Posts

• Started Reading Extreme Programming
• Software Development Book List

Reviews

• BookShelved
• WikiWiki
• GoodReads

Agile Project Management With Scrum

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

 

Reviews

• BookShelved
• WikiWiki
• GoodReads

Update: 2010

Related Post

• My Top Ten Software Development Books 
• Online Agile Resources

Related Information

• Melbourne Scrum User Group (The replacement for MXPEG)

Started Reading Extreme Programming Explained

ith 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

• Finished Reading Extreme Programming
• Software Development Book List

Reviews  

• BookShelved
• WikiWiki
• GoodReads

Talk on DotNetNuke on the 28 Nov

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:  2010

Related Posts

• Melbourne User Groups

Related Information  

• More Info on event
• Melbourne Scrum User Group (The replacement for MXPEG)

Benefits of Courage

evelopers 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

• Value Statement 

More Information

Articles

Inspiration

• Agile Manifesto
• Software Craftsmanship Manifesto

Courage

• Courage is an increasingly important
• There is a need to stand up, be visible, say no
• You have to have the courage to make hard decisions

Safety

• Agile practices failing without safety
• Google’s Data-Driven Insights on High-Performing Teams
• Psychological safety vs. mere comfort

Books

Accelerate: Building High Performing Tech Organizations by  Forsgren, Humble, Kim

What makes software teams perform at a high level? Reducing fear through automation, transparency, and fast feedback loops.

Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity by Kim Malone Scott

Giving (and receiving) honest feedback without fear—balancing care with challenge.

Read the book.

Watch the Video.

The Fearless Organization  by Amy C. Edmondson

Explains why teams perform better when people feel safe to speak up, share concerns, and admit mistakes.

Benefits of TDD

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

• Melbourne User Groups 
• Agile Development Talk

Related Information

Groups

• Melbourne Scrum User Group (The replacement for MXPEG)

Books

Test-Driven Development: By Example Kent Beck

A disciplined way to write software by writing tests before code. Illustrate how TDD works in real projects, along with underlying principles and best practices.

• video review

The Art of Unit Testing by Roy Osherove
.Net Version
Javascript Version

Practical book on writing effective unit tests in real-world software projects. Goes beyond syntax and frameworks to teach the mindset and discipline of testing.

Continuous Delivery by David Farley, Jez Humble

The discipline of building software so that it can be released to production at any time, safely and sustainably. The goal is not to release constantly, but to always be in a deployable state.

• video

The Mikado Method Ola Ellnestam , Daniel Brolund

A structured, lightweight, and pragmatic approach designed to help developers make non-trivial improvements to complex or legacy codebases—without breaking anything in the process.

• video review

Agile Development Talk

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: 2010

Related Posts

• Benefits of TDD
• Melbourne User Groups

Related Information

• Melbourne Scrum User Group (The replacement for MXPEG)

Melbourne User Groups I Attend

list of user groups I found useful (2006)

• ACS - Australian Computer Society
• 💀ACS Victorian e-Commerce SIG
• Content Management Professional Australian Community
• Vdnug - Victorian Dot Net User Group
• 💀Microsoft Office System SIG (MOSSIG)
• MPG - Melbourne Patterns Group
  • Messages
• Melbourne Python User Group
• OWASP - Open Web Application Security Project
• 💀SocSIG - Service Oriented Computing SIG
• Australian SQL Server User Group
• VAMSIG - Victoria Agile Methods Special Interest Group  
• MXPEG - Melbourne eXtreme Programming Enthusiasts Group

Update: 2009

Related Posts

• A more comprehensive list of Melbourne user groups.

Related Information

• Melbourne Scrum User Group (The replacement for MXPEG)

Agile Estimating And Planning

he 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: 2006

Related Posts

• Groups I Attended (2006) 
• Melbourne User Groups
• MXPEG Meetup - Melbourne XP   

Related Information

• Melbourne Scrum User Group (The replacement for MXPEG)