Wednesday, November 19, 2008

Friday, November 14, 2008

Distributed Agile Practices

Finished reading Distributed Agile Development at Microsoft patterns & practices

Excellent paper! Focused on agile development, lists proven practices that led to better development results in various distributed development teams:
  • Focus on Communication
  • Plan to Travel
  • Team Distribution
  • Focus on Coaching the Team
  • Distribution of Work
  • Build the Team over Time
  • Provide the Right Tools
All practices are great (more or less intuitive) Ideas and Ideals , the interesting part are the hints to their efficient set up in practice.

Writing down some of them possibly for future use:

Focus on Communication: plan communication, pair buddy, parking lot system for issues raised during meetings, etc.

Distribution of Work: special attention for asymmetric teams

Focus on coaching: an experienced coach in each of the distributed teams

Friday, October 24, 2008

Iterative Posts

I tried for my first Post to make it as complete as possible before publishing: spell checking, ensuring that the important words have external links, structure, etc.

It may seem natural, a post may virtually have a large number of readers, readers that may know or not the author. The post may become quoted or may be used in a form or another, isn't it?!

For me, trying to reach perfection before publishing something has become very frustrating!

Why? Because I have an agile background. I am an adept of the XP Driving Metaphor, where adapting to real feedback is everything. My designs are stirred by my customers, why not my post to be driven in the same way?!

I decided to go agile even with ideas published in posts, it may work! Even if the real customer will be also me :)

So, this post is a nice first draft to be published! Agree?! :)

Friday, October 17, 2008

A Unit Testing Presentation

I had a couple of days ago a unit testing presentation (see bellow) to my development group. The topic & the short description (Vocabulary, Styles & Toys) lead to a vast audience, almost every developer attended, also managers!

The Goals were simple and some of them classical:
  • Share common vocabulary in all extended team (Unit Test, Stub, Mock, Test Double, FIRST)
  • Grow appetite for Mocks
  • Grow appetite for further reading
  • Show the problems Integration Tests may induce.

The goals were reached partially: - at least now, everybody knows what a mock is, everybody knows what stubbing is, everybody knows frameworks "easier" than jMock are available.

Some interesting questions were raised during this presentation:

Are acceptance tests philosophical? How do they integrate in an hypothetical automated tests classification?

If Unit Testing is strictly related to source code, how do we name functional tests written to test in isolation a single GUI element (let's say a table)? Don't we need more words in the testing language puzzle?!


Wednesday, October 15, 2008

Good OOD Axioms

Every application written in an object oriented programming language has a design.

No design is design, procedural code in one God Class and a myriad of Data Classes is design, the list can grow and grow.

The above mentioned application contains a number of objects (enforced by the language) that collaborate to produce the application's outcome(s). Reverse engineer any application and you will be able to visualize a form of design.

Object Oriented Design from methodology to exact science

OOD has evolved in the last decade from simple methodology and heuristics towards exact science: the science of building good object oriented designs!

Vague expressions like "thinking in terms of objects", "responsibilities & collaborations",
were gradually replaced by more structured approaches:
  • Good and Poor designs in terms of implementation and maintenance costs
  • well structured books & trainings
  • principles and laws
  • patterns
  • tools that can aid a design process
I'm not only discussing waterfallish design, but also agile design.

Axioms

Time & practice lead to well structured information about Good Designs.
Similar to an exact science, OOD should now define it's axiomatic roots!

Sets of statements like:
  1. My design goal is to minimize my future work.
vs.

1. I must minimize coupling.
2. I must grow cohesion.

vs.
I must respect:
1. Open Closed
2. Interface Segregation
3. Liskov Substitution
4. Low of Demeter

may share the same goal, may become in OOD what parallel axiomatic systems represent in modern mathematics and physics.

Different opinions? ;)

Friday, October 10, 2008

TDD is vague

I was asked recently about TDD:

What is it exactly? What's the difference between it and Test First Programming?

The questions were raised by one of my colleagues in a Test related activity we had. (Simple curiosity about a handy acronym heard somewhere some time ago and if applicable to what we were doing)

My quick answer: "Test Driven Development is not only about writing your test first! It implies you also see the system as a tester/user. In TDD you ask yourself questions like: What can go wrong? What other scenarios must be considered? Guidance from a preventive QA team would be welcomed in this process... "

Context : we were developing(peering) a new feature - new GUI and related functionality in a TDD manner, writing quickly the functional test (called by us "GUI test") before, and trying to keep the green bar afterward.

After some reflection I realized that TDD is a vague acronym. Why? Because "Development" is also vague.

Development examples :
  • explore a simple idea: It might be possible to create this new method that will save us from this amount of code duplication.
  • explore a new technology, use it in the application: Can we use hibernate? Yes. We need to use these annotations. Data is persisted.
  • design a number of classes with complex behavior: We have performance related problems - we need to cache previously computed results. We must be able to invalidate the cache.
  • design a number of classes with complex structure: For the given primary inputs, we must be able to compute and save intermediate results.
  • build business structure: Make this "Foo" editable, you did the same for "Bar"
  • build business behavior: We have to create these Business rules.
So TDD could mean:
  • Test Driven Exploring (driven by learning oriented tests)
  • Test Driven Design (driven by design oriented tests)
  • Test Driven Structure Implementation (driven by GUI oriented tests)
  • Test Driven Behavior Implementation (driven by acceptance criteria oriented tests) - thank god we already have a name for this : BDD
  • ...
So, answering TDD is not easy, it implies Test First, it implies small steps, various external preoccupations on a case by case basis: what may break my design, what other GUI interactions may work wrong, when can we say acceptance criteria passed, ..

It's been a while since I wrote this post. Reached a very nice post about another TDD meaning:
  • Test Driven Refactoring (driven by refactoring oriented tests)
Reached another nice post regarding TDD & Test First: TDD does not mean Test First. "TDD does lead to better code - test first does not." Really enjoyed the formulation!