Pyxis

If you want to hear about a real example of pure meritocracy, you should listen to Tarus Balog on Linux Link Tech Show episode 343. This guy has truly understood how to lead an open source project, and a number of really interesting things such as Open Source Marketing are discussed. (VCs who want to invest $2,000,000 in a company are also welcomed to listen to the podcast episode).

If you have a (possibly good) product that you have open sourced, but without being able to gather a community around it, then I urge you to listen to the episode.

Tarus Balog, keep up the good work, you clearly have understood what a number of supposedly open-source companies totally miss  ! Good work pays in the long run !

Martin Fowler published an informal survey of version control tools among Thoughtworkers. Of course, the big winner is git, and anyone who has been going through the effort of learning it correctly would confirm.

BTW, if you want some help convincing people that git is better, do not hesitate to take a look at why git is better than X.

On a related note, you might want to listen to FLOSS weekly 111 podcast (direct link here), where CMake lead developer talks about his wonder build tool (I’ll never ever use autoconf again if I need to write some C any day) that is now developed using git.

As I explained in a previous post, Domain-driven Design (DDD) is a design principle I strongly believe in.

With more and more evidence of systems/companies switching to NoSQL for scalability reasons, creating a rich  domain model becomes less and less of an option if you don’t want to shoot yourself in the foot. Indeed, while traditional applications sometimes often rely on the database to enforce integrity and referential constraints, this is no longer an option with NoSQL because of the CAP theorem.

So, this means enforcing constraints becomes the sole application’s responsibility, which is, IMHO, a good thing. Validation naturally belongs to the domain layer, and once you go through the trouble of transforming your POJOs/anaemic domain model into a rich domain model, you will certainly start adopting more and more DDD principles.

Responsibilities thus become clear : the storage layer handles the (possibly distributed) persistence, and the domain layer handles the domain-specific business rules and validation.

Mettre de la pression sur le système pour faire apparaître le gaspillage

Afin de faire apparaître les goulots d’étranglement dans le processus de réalisation d’une équipe fonctionnant en Kanban, j’ai proposé de réduire les limites du WIP¹

Lors de la mise en place, l’équipe a fixé des limites confortables pour le WIP. Après deux semaines d’utilisation du tableau, l’équipe n’a pas identifié de goulot d’étranglement.
Lorsque j’ai fait ce constat, j’ai proposé au coordonnateur, lorsqu’il a remodelé le tableau à la réception du nouveau tableau, de réduire la capacité de certaines colonnes en plus des modifications prévues lors de la rétrospective.

Cela va bientôt faire trois mois que le tableau Kanban est en place et deux mois que les limites ont été baissées, et nous avons observé des difficultés telles que les suivantes :

1. Des cartes sont bloquées depuis plusieurs jours et il ne reste qu’un espace disponible dans la colonne pour passer des nouvelles demandes.
2. Il y a deux cartes dans une case.
3. Une case ‘blocage spécial’ à été crée pour sortir une carte qui est bloquée et qui n’est plus prioritaire.

En discutant avec l’équipe, il apparaît que la baisse des limites a eu l’effet escompté, puisque avant cette baisse, il y avait suffisamment de place libre pour que de nouvelles cartes puissent passer même si d’autres étaient bloquées.

Content de ce résultat, je comptais proposer à l’équipe de réduire le nombre global de cartes présentes dans le tableau, car actuellement, les limites établies permettent d’avoir un nombre que « je » juge trop important d’items en cours simultanément.
En effet les limites sont établies par étapes du flux de travail, mais les mêmes personnes travaillent sur plusieurs étapes et cela ne force pas les items à sortir le plus vite possible, certains restant même plusieurs jours dans le backlog.

Mais je me suis ravisé car mes solutions ne seront jamais meilleures que celles de l’équipe.
Alors, au lieu de proposer ma solution de réduction du nombre de cartes dans le tableau, j’ai proposé à l’équipe de travailler sur la notion de gaspillage lors d’une rétrospective.

À la suite de cette rétrospective, après avoir identifié l’attente (une carte est souvent en attente dans le tableau) comme l’un des plus gros poste de gaspillage, l’équipe a commencé à mesurer le temps passé par les cartes dans les différentes phases du processus à l’aide de la méthode proposée dans l’article « Flow. Discover Problems and Waste in Kanban ».
J’espère que ces mesures permettront à l’équipe de trouver « ses » solutions pour éliminer le gaspillage, solutions qui rendront la mienne obsolète.

Quels sont les mécanismes que vous mettez en place pour contraindre le système ? Quels sont les résultats que vous obtenez ?

GeoTools developers have released the 2.6.2  version. GeoTools contains an incredible amount of utilities related to GIS and I am totally impressed by the feature set.

To give an example of its use, here is some sample code from gisgraphy-java-client ( a simple Java client I am writing for the open source GISgraphy project).  It calculates the orthodromic distance between two coordinates :

    public double distance(GisFeatureGeography o, Unit unit) {
           Unit targetUnit = (unit != null) ? unit : SI.METER;
           com.vividsolutions.jts.geom.Geometry me = location;
           com.vividsolutions.jts.geom.Geometry other = o.getLocation();
           try {
                   return  SI.METER
                          .getConverterTo(targetUnit)
                          .convert(JTS.orthodromicDistance(
                                 me.getCoordinate(),
                                 other.getCoordinate(),
                                 DefaultGeographicCRS.WGS84));
           } catch (TransformException e) {
                   throw new RuntimeException(e);
           }
   }

Please note that the code makes use of two excellent libraries : JTS for geographical types, and JScience for units. And for your information, WGS84 is a friendly name to refer to the GPS coordinate system (x,y,z).

There is a constant about Software Developers : they love debating and arguing about every single aspect of the development process. Moreover, they will most likely debate forever, because there is usually nothing that can serve as a reference to tell good and bad practices apart. Want to know why ? Well.. everyone is making his own opinion based on his own vision of the truth. There is no axiom that is taken for granted and that serves as the basis for further discussion.

“In traditional logic, an axiom or postulate is a proposition that is not proved or demonstrated but considered to be either self-evident, or subject to necessary decision. Therefore, its truth is taken for granted, and serves as a starting point for deducing and inferring other (theory dependent) truths.”

The rest of the mathematical logic is based on these axioms, and given these axioms, everything else can either be proven right or wrong. While it is certainly impossible to create universal axioms and reasoning principles that cover the foundation of software development, I believe we should at least mimic the approach : decide of which design, architectural and coding principles we believe on, and then use these axiomatic principles as the foundation for decision making. Of course, the outcome of your next project will depend on the  quality of these axioms, but at least you will be able to move forward and take consistent decisions throughout the lifecycle of the application.

As far as I am concerned, I tend to base my reasoning on a set of axiomatic principles that are based on the opinion of respected and talented people in the software industry. Even though nothing is perfect, I believe that listening to these experienced people will more likely lead to successes than listening to any lambda developer’s opinion. This is my bet, and the rest of this post is a first draft of the main design and architectural principles that I consider my axioms.

• Domain Driven Design, Specifications pattern, Layered design.
• Principles of OOD, and in particular, the S.O.L.I.D. principles
• Clean code: A Handbook of Agile Software craftmanship.
• Implementation Patterns
• Implementation of the right Enterprise Integration Patterns that best describes a given integration issue
• Defensive Programming (also see Defensive programming in Java) and its derived principles : Design by contract, Assertions,  Immutability, Copy-On-Write, Immutable collections.
• Inversion of Control
• Declarative Programming, and in particular Functional Programming-style collection manipulation and Command/Query separation, side-effect free methods.
• No premature optimization.
• Lessons learnt from UNIX programming.
• Tell don’t ask.
• Robustness principle : Be conservative in what you do, be liberal in what you accept from others.
• Do not reinvent the wheel.

The people behind these principles are smart, experienced, and potentially more intelligent than you and me together. So let’s just follow these principles for now, and once we master every single aspect of them, we will be able to help create the next generation of design and coding principles. In the meanwhile, I take these principles for granted.

It is a pleasure to hear that some open source projects are conducting usability reviews :

• Wikipedia : Usability and Experience Study
• OpenStreetMap: UX Review
• any other ?

Usability reviews are of uttermost importance if you want to learn how your end users use your product. I initially thought that conducting usability reviews was complex, and involved lots of steps, but Jean-Francois Proulx definitely convinced me of the approach when I attended one of his usability talks a few months ago.

To me, this is clearly a better investment than having your market-team meet during long hours in front of screenshots trying to shape the next version of your website

Gartner studied the market and attempt to predict trends in their latest report: Predicts 2010: Agile and Cloud Impact Application Development Directions.

As organizations seek to improve productivity and reduce application operating and maintenance costs, we will continue to see an evolution of software development tools, platforms and practices. To take advantage of this, organizations must shift structures and practices while embracing new technologies — a challenging proposition.

Gartner’s analysts (Thomas Murphy and David Norton) predict that by 2012 “agile development methods will be utilized in 80% of all software development projects”. The authors explain that although Scrum will continue gaining in popularity over the coming years, organizations will not be successful in their transition unless they move toward a team-focused culture. As was mentioned in their previous report, very few organizations use a pure-Scrum approach and most rely on an hybrid approach (waterfall and Agile).

The report highlights that organizations struggle to implement true collaboration in the context of globally distributed teams. A situation that has amplified in recent years with outsourcing and off-shoring of software development projects.

In the other hand, the report confirms that teams who have successfully moved to Agile do see productivity improvements especially in “the flexibility of the development team to respond to shifting requirements”. This is especially true for web-based application developments where rapid responses to a changing environment is critical.

The authors point out that organizations need to properly invest in such a transition in order to achieve success.

Organizations that do not make use of key agile practices and do not invest in training and supportive tools’ infrastructure will find that a shift to pseudoagile, while potentially delivering a short-term productivity bump, will end in long-term declines in quality and productivity (…) the promise of four times the improvements in overall productivity has been and will be achieved by select organizations.

Gartner’s report highlights that “development organizations have been making a shift toward agile methods, but this is still slow to move beyond development, and often is a mixture of waterfall practices utilizing an agile or iterative project cycle”. The authors also recommend to “look for opportunities to utilize agile development practices, but recognize that it requires changes and commitment on the part of business and IT”.

Gartner concludes with a few recommendations to help organizations maximize their return from an Agile transition.

• Recognize the cultural changes that are at the heart of agile.
• Don’t allow agile excitement to drive cowboy-coding practices.
• Agile requires discipline.
• Recognize that scrum is only a partial solution, and focus on a collection of practices.
• Find tools that enable collaboration and help automate repeatable, consistent practices.

Related documents:

• Don’t Let Short-Term Agile Create Long-Term Pain
• The Current State of Agile Method Adoption

You might be interested in these related posts:

1. Forrester Reports “Agile Development: Mainstream Adoption Has Changed Agility”
2. You have the best BI application. Great! Do your users know?
3. Nobody is interested in Agile

As you may have noticed in the Executable Specification and build integration post, build system integration is an area where GreenPepper shines. Most teams having good automated build practices also use a continuous integration (CI) server. We provide more comfort to those teams by allowing them to look at their GreenPepper execution results directly from their CI server user interface, we have developed integration with two major CI servers: Bamboo and Hudson.

Bamboo Build View :

Hudson Build View :

If you would like us to develop an integration with your favourite CI server, let us know.

This new release includes a new plugin for Hudson (a continuous integration server), support for Jira4, a better use of accented characters in specifications, many improvements to the core and much more…

See the release notes for more details…