Walled Garden == Padded Cell

From a recent podcast on Asterisk and VoIP I heard this quote:

"There is not much difference between a walled garden and a padded cell"

Though humorous and accurate in the context incumbent telephone operators, I think it has more broad relevance. Having just finished an insightful book on mistakes and self justification, it is clear that there are a whole host of potential problems associated with closed groups, isolation and protectionism.
Longer term, I guess walled gardens are just doomed to stagnation which of itself is enough to drive one mad!.

Collaboratory - latest new word

Some days it nice to see progress reflected in the written language through the acceptance of new words. This one will be a humdinger as every R&D lab embraces open innovation that is enabled by the combination of pervasive computer networks and the social acceptance of computers as a communications mechanism.

Druid Leaves me speechless…

The subject matter is harrowing, prepare to be moved. Lucy Caldwell script is so in tune, the reality and inevitability of scenes emerge from our own experiences. But most of all it is the complexity of emotions and the completeness of character portrayal that make the evening so special. I will never forget “I only came up to tell you the dinner was ready”. Where there is love there is life and where there is theatre like this, life is better.

When clever is just too much..

This quote from The Elements of Programming Style by Brian Kernighan and P.J. Plauger resonates:
Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

Be remarkable

Marketing guru Seth Godin gives an informative and fun talk at google. New stuff (product) has to be remarkable in the true sense of the word. People need to want to pass remarks about it. This starts the process of word-of-mouth marketing which is the key to awareness and interest.
The bottom line is that conversation is the key, you need to cause conversations about your product or service to take place. To start conversations you need to target the message at people who want to know such that they will want to participate.

What does it mean to be an Agile software developer?

The principals of agile software development are well documented and extensive. On the ground, day to day, what does it mean for a group of engineers?
I think there are two simple attributes that really matter:

• Clear short term focus on adding value
• Willingness and capability to change focus

The clear short term focus on adding value is well understood. It follows from a good user(customer) story that breaks down into tasks. The focus is collectively and iteratively on design, implementation, testing and documentation to make the customer requirement a valuable reality, adapting to requirements changes as necessary. The appreciation of value as perceived by the end user rather than the engineer is also important.

The willingness and capability to change focus is a little more subtle. Willingness is important, without it there is no hope of agility, but more important is the capability to change. The capability must be learned because it is embedded in the context of the team and workplace. Consistency is key I think. Consistency in engineering practices across teams around things like build systems, code style, development and design tools. Consistency and simplicity allows individual developers to change focus because the underlying infrastructure does not change (too much). With consistency, moving from one task to another or from one team to another is not only possible, it is fun.
I understand that rigid restrictions are often considered the antithesis of creativity but they have their place and can be beneficial. Consider:

• Constraints often provide the motivation for innovation.


• Discipline predicates habit, habits allow our conscious mind to focus more freely on the task at hand.

Helping a FOSS project tip over the technology adoption curve

When does a new FOSS project take-off, become really popular and move in the main stream?
What are the necessary pre-conditions or attributes of the project that allow it to tip-over the adoption curve?
I will hazard a guess at a few relevant attributes:

• Useful: the project must do something useful. Either it is a better or novel solution to a known problem or it is a new solution to a new problem. Whatever the case, it must help solve some problem. This is a necessary, if not obvious, pre-condition.



• Honest: honesty is important because it builds trust. Trust is important because it is the basis for an on-going relationship and the basis for a technology adoption decision. Honesty is easy to achieve. It is about simply ensuring that the project 'does what it says on the tin'. That it is fit for the purpose for which it is intended. If the project is a first step in the direction of a solution with a bunch of explicitly identified known-limitations, that is ok also. The key point is that there is no world domination marketing blurb, no spin, no claims about un-tested or un-implemented features, no ifs or buts etc.
  Honest revelation is important for two reasons. First, because it is the truth and because it forces identification and analysis of the current reality. Second, because you can be found out. The source is open and the truth is in the code. The type of people an early FOSS project needs to attract can and will read the source-code.
  If a FOSS project is honest, the users first impressions will be a valid reflection of the project. There can be no disappointment. If the intent is perceived as useful, the user can decide to adopt, track changes or get involved. In essence, the project stands solely on its 'usefulness' merits.



• Extensible: The architecture of participation is important. Successful projects get this right from the beginning. Outsiders are presented with clear opportunities to contribute to the project.