A nice little read during the holidays was Rich Gold book: The Plenitude: Creativity, Innovation, and Making Stuff (Simplicity: Design, Technology, Business, Life) . It got me thinking about quite a few issues, of which I would like to share one with you: the four hats of creativity.

Usually the focus of software development is on the engineering part. Wearing the hat of the engineer, and expecting others to do the same, makes it very hard to make optimal use of our creativity. We all have heard a lot on the goings-on at Apple as a side-effect of Steve Jobs' death, and one of the things we should be aware of is the prominent position of the designer at Apple. In fact, the lead positions with Apple are taken by designers. Not engineers. Not project managers.

The other two hats are not less important either. The hats of the artist and scientist have something in common, that the engineer and designer, with their focus on "customer satisfaction", lack: a certain wilfulness, or obstinacy, the drive to pursue a venue just because it is there and fills your dreams, the vision that is larger than you are.

Build a team, and try to incorporate something of these four hats, to create a balance that nurtures creativity. I sometimes use inspiration from other sources to think about team member characteristics, which I want to share with you here.

One is from Marinus Knoope. Unfortunately I know not of an English translation of his work. He is a Dutch physicist gone psychological, and his book "De Creatiespiraal" (English: The Creation Spiral) is a nice additional view on the subject of creativity that Rich Gold talkes about, and his book provides very practical guidelines for applying this concept on teams and organisations.

Another source of inspiration is the Medicine Wheel from the native American traditions, which uses the four directions of the compass and links these with basic psychological attributes (in this case for example wisdom, justice, courage and temperance). There are many other possible sources: the wheel of astrology is one I also use often.

All of these models, or thinking matrices, have something in common. They describe a "wholeness", and attempt to achieve "whole-sightedness" (see Mirror Worlds: or the Day Software Puts the Universe in a Shoebox...How It Will Happen and What It Will Mean ). This is something we not only should attempt to accomplish in our organisation, but also in our products. It functions as an antidote of ant-sightedness, which is endemic in society as well as in software development. I often talk about the importance of realising that there is not so much difference between the way you should organise your product or the team that produces that product. These sources helped me through the holidays, and set a nice tone for me in the coming year.

Happy and creative 2012!

From: Automatiseringgids, 16 November 2011: Sourcing verdeelt geesten (Article in Dutch).

"One of the most remarkable findings is that the satisfaction about outsourcingrelations seems to depend on the level of the respondent within the organisation. Managers on strategic levels are generally (83 percent) satisfied or more, but on tactical/operational levels this is only true for about 58 percent of the managers. "The higher in the tree, the happier the monky", summarises research leader Guus Delen."

This is a citation (translated from Dutch) from the article, which reports on a research project called Symbiosis which is a joint research from the University of Amsterdam and some other Dutch universities, together with ICT Consultancy firm Verdonck, Klooster & Associates.

The article correctly mentions the discrepancy, partly in perception but also in awareness, between the strategic and tactical/operational levels in organisations. Interestingly enough the discrepancy was also detected in the outsourcing partners, not only in the outsourcing parties themselves.

I think this discrepancy is more problematic than is usually reported, and deserves much more attention. I have encountered situations where the strategic level seemed to live on a different planet from the operations floor.

One of the problematic situations is that the strategic level does not get the "real" picture from what is happening because they only receive their information from the immediate levels below them. They set procedures in place to help them get more trust in the provided information but this usually creates the well-known problem of "squashing the middle-manager": squashed between his manager who demands almost impossible results, and the team under him, racing to meet those expectations but unable to communicate the problems they encounter to their boss.

Architecture is a process I envision as a helper in this dilemma. Because the process focusses on the quality of the work, it can be somewhat easier to use as a vehicle of communication that provides better, and certainly more impartial, information to the strategic levels.

Compare the iPhone and Android.

The iPhone is a closed platform. Apple dictates the programming language and frameworks to use for developing software for the thing. It even maintains strict control over the deployment process through the App Store. Plus it forks one third of the revenue stream to go to itself.

The Android is a so-called open platform. Every developer is free to select their preferred programming language and framework, while Google provides their preferred solution in the form of a Python and Java SDK. There is an app store for the Android called Android Market, but developers are not hindered in any other approach for their users to obtain their software. I call the platform semi-open because it lacks a characteristic I am especially fond of: run-time access for not only the source code (including being able to modify it), but also to do all that while the software is running. As Smalltalk systems have been providing since 1972. 

Some unrest has been created by the visible impact (that is, banning from the Apple AppStore) of the enforcing of certain clauses in the license agreement all developers need to sign in order to get access to iPhone development.

This license agreement has been in the news earlier. It is an interesting license agreement, since part of the agreement is that the agreement itself may not be publicly discussed (section 10.4). In fact posting this blog about it may itself be interpreted as a violation of the agreement and result in all my iPhone/iPad development being banned!

The banning of the Scratch app, based on section 3.2.2 of said agreement, has also created quite a buzz in the developers community. The ESUG mailing list (ESUG is the European Smalltalk Users Group, and a representative of a large part of the Smalltalk programmers community, Smalltalk being a programming language that seems to be violating section 3.2.2 of the license, and consequently cannot be used to program any software for the iPhone) sent some heated mails around. But this response in itself may be brought to court based on this paragraph!

A large part of the discussion is invisible to the public, because it takes place (from necessity since discussing it in the open may have undesirable repercussions…) on the Apple developers forums. To get access to these forums you need to sign the agreement!

All in all this seems a very undesirable situation, in dire need of clarification. Even the legal basis for the entire agreement may not be correct.

I suppose it can never be the intention of the license to ban freedom of speech, which can be a possible interpretation of these events. Fortunately the EFF seems to take the matter seriously.