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.



Related Information

Monday, December 4

Talk on Project Management (Agile and others) in Melbourne

IO

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 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 Information

Sunday, December 3

Road to Serfdom



Just finished this book. 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 finished reading Kent Beck's Extreme Programming Explained 2ed.

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.

Reviews: BookShelved, WikiWiki

Wednesday, November 29

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

Update: 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.


Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series)


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.

Reviews: BookShelved, WikiWiki

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
  • 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
  • GITEX highlights
  • MMV support
  • Business leads

Related Information

Benefits of Courage

Developer face many challenges in the work place. Fear can get in the way of doing what needs to be done.

Fear that making a necessary change will break something else in the system.

Agile practices such as automated tests (unit and functional tests) and continuous integration help provide a safety net that is going help overcome this fear.

Fear of admitting you need help when you hit a roadblock.Agile practices such as pair programming and/or the daily scrum or the daily stand up meeting can help. Providing a safe environment is also important.


Fear of bucking the system,

of saying to your boss that what they are suggesting did not work last time and is unlikely to work this time. Getting agile practices adopted can require a little courage and some managing upwards.

Fear of saying no,

of saying that if you move the deadline forward by a month we will miss the deadline by a month unless you reduce the scope.

Other fears,
perhaps the readers can suggest other times where courage is needed.

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 discussion drifted to Test Driven Development and the benefits. To my mind there are so many benefits that it is hard to pick a winner.

If TDD is too extreme for you or you are faced with non-unit tested legacy code, do not let the ideal of test first prevent you from adding unit tests.

Some of benefits of unit testing are

  • Provides a safety net that promotes confidence about making changes to code.
  • Instills a appreciation of the need to break dependencies.
  • Promotes good Object Oriented design
      • (bad design is hard to test)
  • Allows you to see your component from the outside.
      • (This helps increase ease of use from a callers perspective)
Ramp it up to test first development and these benefits intensify plus you get

  • It helps you focus on what you are try achieve instead of how you are going achieve it
  • There are times where some or all of what you need to achieve is already there in the code
      • (if this is the case the test will pass without you doing anything.)
      • (The number of times I have deleted large sections of legacy code because the sections did not do anything useful is depressing)
  • It encourages you to stick to what is needed immediately instead of adding what might be needed later.

A powerful benefit is a change of mindset.
The above list is in part a manifestation of the change in mindset and in part a cause of the change.

Can the readers think of any other benefits.

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 Information

Wednesday, November 15

Agile Estimating And Planning

The speaker at last nights MXPEG 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.

Melbourne XP

Attended the Melbourne eXtreme Programming Enthusiasts Group (MXPEG) 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: Related Information