The Economy: China to the rescue?

Just watched Panorama ( a BBC documentary), on Gordon Browns 'Economic Miracle'. Apparently what has sustained the longest period of economic growth in recent history has been consumer and public spending. Even with spending, inflation has remained low. Low inflation has been as a consequence of cheap imports form the far east and China. This as allowed us to avoid the boom and bust economic cycle of the past (high spending-> high inflation -> high interest rates -> economic slow down).

The growth of imports as been at the cost of local manufacturing. So we no longer build stuff, but stay afloat by selling things to each other built cheaply else where. And of course there's the growing 'service sector' what ever that is (retail parks, DIY super stores, etc).

I'm no economist, but I know that most people feel pretty insecure at work. Most people are working harder for less. Job stability is a thing of the past, and most people have come to accept short term contracts as part of life. The only thing that seems to produce 'a feel good factor' is house prices - and who knows when that will suddenly come to an end.

The scariest thing that came out of the programme for me, was that once UK manufacturers had moved their production to China, the benefits to the UK economy (lower retail prices) will be realised the once. Once things have settled down, low prices and consumer spending, can no longer be relied upon to sustain future growth. Worst still, without a manufacturing base of our own, we will become sensitive to price inflation in China. Should the Chinese decide to pay themselves more, then that will be reflected in higher prices in the UK.

So after years of protectionist EU trade policies on food. We will suddenly find ourselves dependent on others when it comes to manufactured goods.

What will become of the average man on the street? After all we all can't work in retail parks, and I don't think we're going to loose our appetite for consumer goods any time soon. Maybe the French have the right idea, and it is time to start putting up the barricades!

It really does look like unstable times ahead. Economic power in China, Military power in the US, the Europeans in the middle. Friction between China and the US seems inevitable to me. Some how I feel that the Americans with their vast resources and dynamism, will be able to meet the Chinese challenge. I fear that China's gains will be at the expense of the Europeans, including the UK.

I don't fancy learning Mandarin, so it looks like I need to get myself a Green Card quick!

Software Vision - Creating the Backlog

On the back of my last post. I've come up with an idea. My criteria for envisioning new systems:

• Each release should be take no longer than 3 months and deliver usable value
• The complete vision may take a number of releases to realise
  
• The system/product definition (backlog) should be owned by customer/marketing
• Customer/marketing should decide how much 'traction' is needed between releases

The last point may need some explaining. By traction, I mean the degree of organisational change required to support a release. In circumstances where organisational change is difficult, it may make sense to use a 'low gear' introducing small organisation changes between each release, providing more 'traction', and increasing the possibility that the organisational change will stick. Conversely if the going is good, then larger changes may be possible, allowing the end vision to be realised sooner.

The point here is that software vision is a skill, and the people responsible need training. So my bright idea is training for customers/marketing people on how to create a product backlog.

Agile development starts with the backlog. But what happens before that? Here is my suggestion:

• A new product idea (instigated by anyone)
• If idea meets some minimal criteria, it enters the project funnel
• Organisation use some criteria to decide which projects to fund and in what order
  
• Funded projects acquire a 'customer team'
• Customer team go through some training on creating 'product backlog'
• Customer team create first pass backlog
  
• Development team work with customer team to refine and realise backlog

I'm going to give some thought to the training and assistance 'product' teams need to envision a good product backlog (product definition). I will use the term 'product team' instead of customer team as it is consitent with 'Product backlog' and SCRUM.

Hopefully I can come up with some good guidelines.

Anyway watch this space.

Software Vision

Alan Cooper and Kent Beck debate XP vs Interaction Design. Alan Coopers' book The Inmates are Running The Asylum describes Interaction design.

Not sure what 'interaction Design' is, but from the article it appears to be some type of business analysis that occurs prior to software development. The assumption is that users need 'help' in deciding what it is they want built. Rather than just automating what is, we should be designing something better. Sounds similar to the Business Process Re-engineering ideas of the late Nineties.

In my post on software as art, I point out that there isn't much guidance available on how best to envision new software systems. I'm not sure whether having a middle man between customers and developers is the right idea though.

It is all well and good, if your Interaction Designers are good at what they do and add value, but how do you test this? Also how do you keep the customer accountable for how he chooses to spends his money?

All sounds a bit naive to me.

Envisioning should be a customer/marketing responsibility, with developer input on feasibility and cost.

I'm with Kent Beck on this one.

The Verdict - NLP is Mumbo Jumbo

Past experience has taught me humility. Hence my criticism of NLP has been somewhat guarded.

Having looked up NLP on Wikipedia, I am pretty convinced that NLP is pseudo science. If the lives of the inventors of NLP are anything to go by, then NLP is definately dubious to say the least. On wikipeadia, there are links to several critiques of which this one is typical.

What does NLP say about our society? Why is everyone looking for a quick route to "success"

I'm of Jamaican decent. In Jamaica, especially in rural areas, old west african values still hold. People are a lot more relaxed about life, a lot more social, and a lot happier. In the town however, (kingston) european values tend to dominate. In a small island, the two cultures sit uneasily together.

When visiting Jamaica, it is clear to me what we in the west have lost. It is also clear how global economics is forcing much of the world down the same path.

People need to ask who is benefiting from this trend? Certainly not the majority of the worlds population. Where will it end? 1 billion chinese are about to join the rat race in earnest - can the planet support this?

Frankly I find it worrying.

Materialism, Spirituality and NLP

Been reading more about NLP. From the moment I was introduced to NLP, I've been a bit uncomfortable with it. In my last post on NLP, I questioned whether NLP could help if your desired outcomes where themselves spiritually unforfilling. Well, the answer is sort of. At least from what I've read. In choosing outcomes, NLP suggest that you identify outcomes that 'suite you'. Outcomes that are congruent with all aspects of you. NLP goes on to say that change should be supported by your subconcious.

NLP also describes a concept known as modeling. This is where the behaviour of "successful people" is analysed and copied. In this way NLP believes that success can be taught.

Unfortunately in my reading thus far NLP has not defined what it means by success. From what I've read, the implication is material success.

So if material gain, is the yard stick for success, where does the soul fit in? It seems to me that this focus on materialism turns sprituality on its' head. Rather than seeking contentment, peace and happiness from within, NLP seems to be promoting the search for happiness through external things.

I think this is a sign of our modern times. Production and consumption, is our new God. As human beings we seem to have lost the connection with our own souls, with nature and with God.

NLP seems to be trying to harness the resources of the soul in the service of material gain. If my interpretation is correct, then us in the west are truly lost. Here is a quote:"... In this spiritual confusion, many cults, sects and - issuing also emerge. Both religion and philosophy become materialistic and politicized...". This is taken from Brahma Kumaris

Life is speeding up, and increasingly more materlisitic. In the west, we are less communal, more individualistic and increasingly isolated as individuals. In this all consuming rush for wealth, our humanity itself seems to be the victim.

Creativity, Simplicity and Art

I've been thinking some more about "software as a creative process'. Good software can be a thing of beauty. Simple idioms and patterns repeated to produce something that is both complex, yet simple. Much like the double helix structure of DNA or fractal patterns in maths.

Beauty in software has two main manifestations. Firstly in its' conceptualisation. Knowing what problem to solve, and what the solution should be, is a creative process. One instantly recognises a good solution to a problem. A good solution is often simple, and a good fit for it's intended purpose. When going through open source projects on sourceforge, good project ideas immediately jump out at you. A project that meets a real need, and is simple.

The second manifestation, I think, is in the structure of the solution itself. Object orientated languages offer great scope for efficient, elegant solutions, where functionality is implemented once and once only. Dynamic OO languages like Smalltalk, offer even further scope for elegance and simplicity. A dynamic language can greatly improve productivity, allowing time for trying things out. Learning through discovery, leads to increased beauty.

Unfortunately, the beauty of a software concept, although visible to the business, is often overlooked. Very few business leaders spend time agonising over whether a proposed software concept is beautiful. Software just isn't thought of that way. More important to most business leaders is the projected return on investment. I've never calculated ROI, but I'm sure that it is a difficult thing to predict. Also I would hazard a guess that projects that actually do provide a good ROI are both beautiful and simple in concept.

Worst news is that the beauty of the final implementation is not visible to the business at all. The first the business becomes aware that a software solution may be less than beautiful, is when bugs begin to emerge, or when maintenance is more difficult and expensive than anticipated. The developers know when a software solution is ugly, but unfortunately, the business hold the purse strings and make the final decision.

Implementing beautiful software is a creative skill that can be taught. Much like painting or playing a musical instrument. The art of software development is well established, and there is a gamut of practices and disciplines for developers to draw upon. Agile development recognises the creative nature of software development, and promotes practices that support creativity. In contrast software conceptualisation, seems to be less well understood. The nearest I've seen to a disciplined approach to deciding what software to build is the approach outlined by SCRUM, namely keep it small and keep it simple. Beyond this there doesn't seem to be much guidance around unfortunately.

So where is the software industry today?

• Well we've got managers who would like to think of software development as a defined process. Gant charts and LOC estimates, leaving little scope for discovery and creativity.
  
• We've got developers, who tend to be more interested in technology, then delivering business value.
• Where beauty is visible, in conceptualisation, the art is not well understood.
• Where the art is well developed, in software implementation, the resultant beauty is not visible.
• The business care little for conceptual beauty, as they do not appreciate its' importance. Developers can avoid discussing implementation beauty honestly with business people as the implementation is no visible.

It would be interesting to see what business leaders from creative industries like fashion and music would make of the software industry. I'm sure they could teach us a lot.

Coaching and NLP

I've not blogged about my agile coaching role for a while. To be honest, I'm a bit disheartened with coaching. Coaching as I understand it places the emphasis on the person being coached to create change. Whilst on the surface this makes sense, it does assume that the person being coached has positive goals and is motivated to achieve them. If this is true, then the coach is a mere assistant showing the way.

Whilst many sports men and women, do have elevated ideals, I don't think the same can be said for the workplace. My experience of the workplace is that of extreme politics. By politics, I mean numerous agendas all vying for supremacy. In my experience, very few of these agendas can be described as noble, aimed at making the world a better place. In my opinion , these competing agendas are responsible for making organisations sub-optimal, and less than ideal places to work and thrive.

Some organisations do manage to maintain lofty ideals, with everyone working towards a common goal. Organisations such as Universities for instance, where an ethos of egality and openness is well established. In such organisations, motives tend to be somewhat different than in the workplace. The pursuit of personal financial security (money), is largely replaced by the desire to gain the respect of your peers.

In the workplace the need to be held in high regard by others can exist too. The success of Japanese companies like Toyota for instance, can largely be put down to the well established clan system that has existed in Japan for many centuries. By fostering clan like loyalty, Japanese companies have managed to achieve a high degree of optimalisim.

In a last ditched attempt to see if coaching can really address the problems in the modern work environment, I've started looking into NLP (Neuro Linguistic Programming). NLP is a psychological science touted by many in the coaching profession as the theoretical under pinning for what they do.

NLP is an interesting mix of eastern leaning philosophy, spiritual awareness, and modern western psychology. NLP proclaims that we can better achieve our desired outcomes, by re-programming the way we think, speak and behave, and in so doing become successful. In NLP, the role of the coach is to help people 're-program' so that they can succeed.

As someone who is well versed in eastern Buddhist philosophy, and who believes in the power of meditation (directed thought), a potential flaw in NLP jumped out at me straight away. NLP starts with the desired outcomes of the practitioner, but very often, it is these desires, that are at the root of the problem.

To explain this last statement fully, would take more time than is warranted here. But in short, it is what we desire (our intended outcome), that is often what leads to our unhappiness in the first place. For example, many of those who desire 'financial security' still find themselves feeling 'insecure' and desperately unhappy, even when they have acquired more than adequate wealth.

People caught like this do not fully understand their own motives. They are consumed by their surface desires, unable to see what lays underneath. Often their desires stem from uncomfortable human emotions, such as fear, jealousy, low self esteem etc. Free of the need for a quick fix, they are more able to see what ever it is that will make them truely happy. I describe this type of awareness as wisdom.

This is why, I feel that what is needed in the workplace is leaders. People that can lead by example, act as role models and inspire those around them to elevate their thinking and gain wisdom. Such people don't merely facilitate, but set the direction and promote values that others can follow. In my coaching, I make a conscious effort to lead. This can manifest itself in several ways. One important way is establishing congruence between my actions and my words. By this I mean 'walking the talk', practicing what I preach. Through this I manage to gain trust, a commodity that is in short supply in the workplace. Next, I try to limit my tendency to judge others, and to become over critical. This is something that I really struggle with, but when I do achieve it, I find that it increases my ability to influence others. People tend to be more open to you when they feel safe from personal attack. Finally, when necessary, I'm brutally honest, and unequivocally is saying what I feel is needed. After a while, when people feel safe and that they can trust me, they become open to taking my lead. I find that when I talk, most people are willing to listen, especially when I take the time to listen to them.

Despite my personal achievements in persuasion and leadership, I find myself in scenarios, where a positive coarse of action is being blocked by someone with higher authority. In most cases this person has sanctioned my role, but has chosen not to consult me on a decision that affects my ability to do my job. They are happy to pass on responsibility whilst reserving control for themselves, leaving me powerless.

This in my opinion, is a failure in leadership. Most often triggered by fears. For such people, what is missing is the ability to lead themselves. To conquer their fears and self doubts. Leaders aren't born in my opinion, but made. The concept of leadership is well established, and many cultures have established ways of ensuring that they foster good leaders. With a good leader a coach becomes a useful tool, helping the leader and their team(s) become the best they can be. The sports men and women, who use coaches to achieve their goals are a good example of this. A sports person, who does not pursue excellence, or who is not motivated to do the hard work needed, will not be helped by a coach.

So whilst the role of coach is significant, what I feel the workplace really needs is good leaders. Not being a captain of industry myself, I have limited my ambitions to leading my own life. NLP may help me get to where I'm heading faster, but if I'm heading in the wrong direction does NLP help?

I would love to hear from soneone with real experience with NLP.

NASA finally sees the light

It looks like common sense has finally prevailed at NASA. You have to give them credit:

Space shuttle replacement

Meanwhile the Russians are having a quiet chuckle, whilst planning their own future:

Russia in Space

In my last entry, I couldn't remember the name the Russians gave their rockets. Well it is Soyuz.

BTW the russian Soyuz rockets date back to the 1960s, and hence are over 40 years old in lineage. Apparently, the Russians have made monumental leaps in rocket technology, eclipsing the early achievements of German pioneers. So perhaps it was abit unfair of me to imply that their current Soyuz rockets are based on German WWII designs - sorry.

The space shuttle in trouble again

Not wanting to annoy any Americans out there, but the latest episode in the Space shuttle saga, is evidence if we needed it that complexity should be avoided.

Space travel, like software development is inherently risky. So why compound that risk, by devising a space vehicle miles more complex than it needs to be?

The Russians seem able to put people into space, a lot more reliably and at a fraction of the cost. So what is their secret? Well a simple rocket design, inherited from the Germans after World War II, is still used by the Russians today.

This simple design has its' advantages, the dangerous fuel tank, that makes up the bulk of the vehicle, is behind the capsule where the astronauts reside. The cockpit capsule can be ejected from the rest of the vehicle, protecting lives in a catastrophe. In contrast, the space shuttle design, has the astronauts sitting on top of a massive fuel tank and adjacent to two solid rocket boosters, with no escape route.

From a safety view point, the space shuttle design is ludicrous. In terms of complexity, the shuttle is significantly more complex then the rockets the Russians use so successfully.

So why? Oh yes, the space shuttle comes back to earth, this as got to be an advantage. Well no, the Russians manage to travel to space at a fraction of the cost, even though they have no reusable parts.

So what is the real reason? Well if I was to hazard a guess, I would say ego. The same reason why so much software is much more complicated than it needs to be. Having a space vehicle that looks like it came out of a "Buck Rogers" movie is more flattering to the ego, than a plain old rocket as depicted in a bugs bunny cartoon.

I'm sure that national ego, will keep the shuttle program going, when all involved must know that the basic design is fundamentally flawed. I've seen this type of "group think" before, often in companies. Compound a bad decision, by ignoring it, glossing over the facts, and pouring good money after bad. After all we don't want to admit that we got it wrong, do we?

I've been learning Ruby lately, and I've taken a look at Rails. I find Ruby an elegant and productive language (when compared to Java), and for most web apps I've built, I'm sure that Rails would have done the job in a fraction of the time (and cost).

So why are people still building web applications using EJBs, JNDI, XML, JSP, CSS, JavaScript etc, etc? For some, mastering this soup of TLAs is an ends in itself. Being able to do this stuff just makes them feel good. It plays to their ego.

As for me, I get my kicks by knowing that I've produced something useful. Something, that will make someones life easier, better, less stressed etc. So with all this press about the space shuttle, I like to think of the Russians - brushing the dust off their 1945 designs, and knocking rockets together with bits of old metal. Its' not glamourous, but they are still luanching multi-million dollar satelites into space.

Agile Development - Learning from Tommy Hilfiger

I've allways seen software development as more of a creative process than a science. A couple of recent experiences has convince me even more of this.

The first incident occurred when I was explaining story writing to a BA. "Oh" she said, "a story board." "It sounds just like the story board we'd put together when working on a new fashion collection." Prior to being a BA she worked for several years in fashion. Apparently, in a fashion boutique someone would come up with a concept for a new range or collection on a story board. A team would then populate the board with ideas: drawings and snippets of fabric building and expanding on the basic theme.

More I thought about her analogy, the more I liked it. After all, in the beginning, the concept for a new piece of software is no less creative than a fashion concept. Stories are nothing more than incomplete snippets that help flesh out the basic vision. Some stories will be accepted, depending on their percieved value, much like ideas in fashion.

The second incident occured whilst watching television. The programm was called "Rich Girls", and followed the life of Tommy Hilfigers' daughter. Tommys' team had come up with a story board for a collection aimed at teenagers. As a way of proving their ideas, Tommy asked his teenaged daughter and one of her friends to come into the office and go through the story board.

His daughter took her "work" seriously, and went to efforts to explain to her friend that "she needed to be honest." If she didn't like something she should say so. "Don't be diplomatic". The scene was an interesting one. The story board taking pride of place in the centre of a large room. Fashion designers huddled in a door way peering in. Tommy leading his daughter and her friend through ideas on the board. Tommys' focus was soley on his daughter and her friend, after all they where the potential customers. The fashion designers were tense, and uncomfortable, as they listened to a severe critique, handed out by two teenagers.

Tommys management technique was interesting. There was only two experts in that room that day, the teenagers. Watching them say, "I wouldn't wear that, or I wouldn't be seen in stripes like those", with everyone listening was amazing. A real lesson in direct customer feedback.

I recently read a post by Rachel Davies where she refers to the lies and half truths that characterise the relationship between development and the business in most organisations.

Tommy Hilfigers management technique seemed miles apart from what I'm use to and what Rachel describes in her blog.

Managing a creative process is different to managing a defined science. Perhaps IT managers could learn a lot from the creative professions. Acknowledging that software development is essentially creative, would be a good first step.

Agile Development - Skill

Knowledge, Understanding and Skill. The three stages of learning (according to Japanese TQM). I have found this to be true. In my opinion a little knowledge can be dangerous, understanding comes only with experience and skill is acquired only after repeated practice in varying conditions.

The theme of learning, has been central to my blogs on Agile development. One of the tenants of the agile manifesto is to value people over process. If you accept that software is a complex non-deterministic, creative discipline, then this primary tenant must be true.

As an organisation, if you value people over process, then it is only logical that you get good at developing people. As an individual you owe it to yourself to improve.

I have been using XP for sometime, and up to now I have reserved judgment on its general applicability. Well I feel that I've learnt enough to come off the fence and offer an opinion.

I don't think XP provides enough guidance on how to get the best out of people. How best to build and develop individuals and teams. XP says go get a skilled team, apply these practices and bingo success. But if the team is not skilled, or worst still, if they think they have the skills, but in reality do not, what then?

In a sense this is an opportunity for people like myself to offer our services as "Coach". Come in, exhibit skill and leave with a fat check. But what happens after we go?

I have been reading Crystal Clear (CC) by Alistair Cockburn. CC advertises itself as a human powered methodology. I prefer to think of it as a people centric approach. It was developed over several years by interviewing sucessful agile teams and asking what worked. The outcome of these interviews has been boiled down into a number of guidelines for success.

CC addresses many of the short comings of XP, by truly focusing on people. I have got my own ideas on how the two approaches could be merged, taking the best from each. I'll save that for another blog. I'll leave you with an omission in XP, that if you think about it is a startling oversight.

How do people improve? People learn from other people, often by example. For this to occur a relationship between teacher and pupil(s) must exist. This relationship is very important and requires mutual respect and personal safety. In the relationship the teacher leads, and the pupil follows. The essential skill of the teacher is leadership. Without good leadership improvement and eventual success is unattainable.


XP does not address the concept of leadership. Instead it assumes that a meritocracy will arise within teams and appropriate leaders will be found at appropriate times. My experience is that what is as likely to occur is that the blind will end up leading the blind. Alternatively, in scenarios where several people have the required leadership ability, uncertainty and confusion can arise as no one knows who to follow.

You only need to look to Sport to see that teams need leaders. Good leaders get the best out their teams.

Agile Development - Understanding

Another entry on my role as agile coach. My last entry on this subject told what happened when I looked for management support to help solve an internal problem. It wasn't a surprise when the management support was not forth coming.

The problem was that some team members did not understand XPs approach to design, and as a consequence were adding technical debt to the project at a rate of knots. Worst still, they did not accept my authority.

What to do? Well in a last ditched attempt I called an impromptu brown-bag session on agile design, and the cost of change. I described the need to "flatten" the cost of change curve when performing agile development, and I used examples from the project to make the point. The session was discussion based, with members of the team asking questions and offering opinions. It became clear very quickly that the team members that were hostile to TDD just did not have an appreciation of the cost of change, never mind how best to address it.

During the meeting I could see knowledge transform into understanding. They had heard the terminology before, some had even skimmed "XP Explained", but this was the first time that they actually understood.

After the meeting, members of the team who had previously said that "they knew it already", asked to borrow my copy of "XP Explained". There is evidently a big gap between knowledge and understanding. Perhaps I should of held the brown bag earlier. Yet I have a feeling that without the pain that the team went through, the less experienced would not have understood. Knowledge and experience leads to understanding. Knowledge on its own is not sufficient.

Consequently my authority in the team has increased. The doubters, doubt a lot less, and are more willing to take my lead.

Thinking through the lessons learned, I've concluded that this episode demonstrates a weakness in XP. How do you ensure that the less experienced developers do not cause too much harm. Especially if they feel that "they know it already"? XP provides no guidance other than to avoid inexperienced developers. I've been reading Crystal Clear - which provides a pragmatic solution to this problem. Let them do non critical tasks, like bug fixes and maintenance.

This idea brings us back to where we started - managing people. As a leader I need to be recognised as such and empowered, but XP does not stress leadership.

In fact XP provides little guidance on people issues. In some ways I find XP a bit de-humanising, reducing software development to a set of rigid disciplines. In contrast, Crystal Clear takes a more people centric approach. I can see myself borrowing from Crystal Clear in the future.

Agile Development - Management

Back to bloging about my experiences as an agile coach. In my last entry I mentioned that we were weeks away from our first release, but that we were also burdened with technical debt.

Well, we have delivered our first release (sort of), but it has been painful. The more experienced developers in the team, are now quite aware of the impact of technical debt, mainly as a consequence of having to refactor large swath's of the system inorder to implement the final few stories.

The technical team lead approached me and asked what to do? Quite frankly I was stumped for an answer. The problem was that some team members were quite convinced that their "up front designs" were playing a vital role. And in their opinion their views where just a valid as mine. After all, common sense dictates that unit testing is about testing, not design right?

By this stage my attempts to persuade them otherwise had failed abysmally. Our team leaders' attempts to assert some influence had failed too. People are complex. The reasons for resisting TDD by some team members are still unclear to me. What was clear though, is that their stance was putting the project at risk, and that management should be informed.

So I penned an e-mail to our manager. It had to be an e-mail, since the only person I could clearly identify as taking direct management responsibility was based in the States (all the team members including myself and the customer assigned team lead are contractors). As a consequence a tele-conference between myself, the technical team lead, the onsite customer assigned team lead, and the offsite manager ensued (if this structure sounds complex, that is because it is!).

Nothing much came of this meeting other than me being told: "Call me back when there is a crisis" by our Manager. So what is the moral of the story? The pointy haired boss is alive and well, even on agile projects.

The cost of software

I've recently watched "The Aviator" on DVD. The movie about Howard Hughes. What an interesting personality. After watching the movie I was keen to find out more about the man.

I found an autobiographical link on the web: http://en.wikipedia.org/wiki/Howard_Hughes read it yourself. My conclusion on Howard, is that he was a man caught up with his own self importance, driven by ego. I couldn't help feeling that perhaps he was a victim. Possibly of a over bearing father who expected nothing less than greatness from his only son. Unfortunately the movie and the online autobiography say very little about his childhood. Apart from his affliction with OCD, the sadness of his life for me was that he spent all his time proving himself, and very little time actually living.

After reading about Howard Hughes, I was keen to explore the lives of other very wealthy people to see if I could find a common link. I looked up Bill Gates http://en.wikipedia.org/wiki/Bill_Gates. I expected Bills' autobiography to contain all the signs of an ego centric megalomaniac (Much like Howard Hughes). But it didn't. Pretty dull actually. Bill Gates appears to be your regular nerd. No vision of grandeur. No big I am. It was when I read his open letter to hobbyist programmers written back in 1976 that I got a real insight into the man: http://www.blinkenlights.com/classiccmp/gateswhine.html

Now Bill Gates is the man we all love to hate (my self included), but reading his letter I realised that he had a point back then. He wanted to produce good software and get it out there to the fledgling personal computer community. What's wrong with that? I found myself asking. To do it he needed good programmers, and good programmers deserve to get paid for what they do. He didn't want people "stealing" his software, especially when they stole and distributed pre-release buggy code - giving him and his software a bad rep.

After reading his letter I now see Bill Gates as the first nerd who cared enough about what he did to elevate software to something valuable, and in common with the producers of other valuable products, he demanded payment.

So how does this sit with the ideals of the open source community? Not sure. I've always seen the common sense in collaboration - working together for the common good. But I always thought that this work should be paid for by the people that benefited from it. For example, a lot of fortune 500 companies could save themselves a lot of money if they worked with each other to generate common software, that they shared (open sourced). They would end up paying the programmers they hired a lot less then they currently pay software vendors like Oracle. The idea of programmers writing code in their spare time for free, and then "donating" it to their employers never made sense to me.

Some people have used open source as a means of bootstrapping a services business, JBoss comes to mind. This is a neat idea, but the few JBoss consultants that actually get paid, are leveraging the work of an whole army of programmers out there that never see a penny. So my question is why do they do it? The programmers I mean. What motivates them?

My guess is that many in the open source community may have more in common with Howard Hughes, then Bill Gates does. The ego boost of having their code used and worshiped by their peers is perhaps payment enough.

Agile Development - Knowledge, Understanding and Skill

As I mentioned in a previous blog, on my current contract I have been performing the role of Agile Coach. I'm not sure that i'm a natural fit for coach, but the project desperately called out for Agile practices, I was the one with agile experience, so I was made coach.

On my previous project, I had the great fortune to be coached by Rachel Davies. Rachel is a very well respected member of the agile community. She is the chair of the extreme Tuesday club in London (www.xpdeveloper.com) and a director on the board of the agile alliance (you know the people that wrote the agile manifesto: http://www.agilealliance.org/home, people like Kent Beck, Martin Fowler, Bob Martin etc). In the Agile community you can't get better credentials than this. Racheal really impressed me in the way she assisted our team in coming to the right answers for ourselves. Never telling, but patiently observing, taking notes, pairing with individual members of the team, and providing input in the most subtle ways. In short Racheal demonstrated a very high level of skill.

In contrast, I'm more of a teller and a doer, not that good at observing and influencing, but inspired by Racheal I resolved to do my best in my new role. Interestingly, my immediate successes where with the Management. Within a short time I was able to demonstrate the power of user stories. The technical management had been having a difficult time in defining the requirements with the users and avoiding scope creep. They where quick to appreciate how stories would help.

Soon we where up and running, boostrapping the XP process by initially writing stories ourselves from the technical specs. We then introduced stories to the testers, who where quick to get on board after months in the dark. The next person on board was the user. He found seeing what he was getting and defining priorities a massive improvement. So much so he cleared space in his diary to be with the team 3 days a week.

The people that proved most difficult to influence was a, the business analyst and b, the developers. The response of the business analysts was somewhat expected. These people have a vested interest in producing paper specs that everyone knew had limited value. We needed to tread careful, coaxing the BAs into realising that stories could be good for them too. Even with the BAs we have had some success, with one or two of them being quite keen to write stories instead of continually revising specs.

The difficulty with the developers came as a great surprise. Some members of the team initially found it extremely difficult being told what to do. I believe the phrase don't teach me how to suck eggs' was quoted more than once. I had to go to great lengths to stress that I was merely identifying an alternative way of working, which in no way invalidated the way they had worked in the past. The experienced developers were quick to see the benefits of XP practices even though the practices were not familiar in themselves. The less experienced developers in the team however, found it more difficult to see past what they already knew. For example, TDD is still seen by some as primarily a unit testing technique (as opposed to a programming and design approach).

NIH (Not Invented Here) and ego centric technical debates soon engulfed the team. Unnecessary complexity was added to the code base, and technical debt began to grow. Worst still I was in danger of becoming the main protagonist in these technical debates. People wanted to prove that I was wrong, and that they knew better. This situation called for swift action. I decided to take a back seat, stopped leading from the front and allowed the team to make decisions for themselves. That iteration no stories were delivered, instead people bussed themselves with technical tasks, making "improvements" to the core architecture.

After the experience of zero velocity, many in the team realised for themselves that Agile development required discipline. My next step was to clarify my role, by suggesting that we needed a technical lead. Fortunately we had a good candidate in the team, who was keen to take on the role. For a couple of iterations velocity soared under our new lead.

Now we are potentially weeks away from our first release. Unfortunately the technical debt incurred during earlier iterations still needs to be paid. It will be interesting to see how things work out.

Agile Development - Whats' in a language?

Since my last entry things for me have changed. In my current contract I am performing the role of "Agile Coach". Interesting in itself (I take my hat off to people like Racheal Davies, coaching is not easy), I won't be blogging about it today. No what I want to blog about is programming languages, and languages that support agile development.

For a while I have been hearing people in the Agile camp say things like: "dynamic languages are the way to go". Untyped (risky) and Interpreted (slow) both bad things right? Well in my coaching role I've been taking a closer look at test driven development - and of course having to practice what I preach, I have been doing a fair amount of TDD recently. For TDD there are two things you definately need - a good test framework (JUnit) and a good refactoring IDE (Eclipse).

The more refactoring I have been doing, the more I have taken the refactorings available in Eclipse for granted and the more refactoring facilities I want. Surely there should be a button to do this or that refactor, and if not why?

Both of the tools I rely on for TDD have a common heritage: JUnit descends from sUnit, Eclipse refactorying is inspired by The Smalltalk Refactoring Browser. In search of a better environment to support TDD I dug up my old copy of the purple book and went on a quest on the internet to find The Smaltalk Refactoring Browser.

The first thing I noticed was that the Smalltalk community is still alive allthough a bit muted. The impact of Java has definately taken its' toll though. A quick search on jobserve for Smalltalk vacancies identified only 10 or so and they appeared to be for maintance work. It looks like the remaining Smalltalkers are using Smalltalk just out of interest or just for fun in their spare time. With the exception of one or two German Consultancies, most of the Smalltalk related websites were either academic, or open source related - very few businesses.

The second thing I noticed is that you can get commercial quality smalltalk for free. I remember the days when a VW Smalltalk license ran well over a thousand pounds. Finally I found Squeak. A free implementation of Smalltalk by the founder Alan Kay.

The first thing that happend when I started using Smalltalk again was that I immediately fell back in love with the syntax. I first taught my self Smalltalk back in the early nineties as a way of learning OO programming. Learning OO and learning C++ at the same time was proving too difficult, so I decided to learn OO without C++. It worked a treat. OO expressions are built on sending messages to objects. The Smalltalk syntax mimicks natural language: An object is a "subject" and a message is a "verb", parameters are "complements" and expressions end in a full stop.
For example:

bunny moveForward: 5.

Tells the bunny object to move forward 5 pixels.

The reflectiveness of Smalltalk and the focus on late binding opens up tremendous possibilities for tooling. Where Eclipse struggles to make Java self aware, Smalltalk positively encourages tools to inspect this, or discover that or refactor this or rewrite whatever...

So where are the Smalltalk tools? Well the old Smalltalk favorites are still there - Browser, Inspector etc. Interestingly these 30 year old tools compete pretty well with their modern counterparts like Eclipse. Eclipse is ahead in some areas (e.g code completion) , but the Smalltalk tools are just so much more accesible and easy to use. I also found some newer tools, for example GLORP is a Object Relational Mapping framework for Smalltalk. If you are familiar with Hibernate you should take a look at GLORP, OR mapping without xdoclet, XML or bite code manipulation. The power of making everytning an object (including classes) is that adding new object types and extending behavour is easy. For example GLORP has a class for a TableMapping, a OneToManyMapping etc and ofcourse overloading 'new' and extending its behavour is a synch. Object queries using GLORP look remarkably like SQL, yet they are standard Smalltalk expressions. No need for a special query language like HQL.

By this stage I was pretty smitten with Smalltalk. For Agile development this has got to be the way to go. The slogan of XP is "Embrace Change". Thinking about the recent changes to Java: dynamic proxies, annotations, generics etc all of these have required changes to the core language (JVM and compiler). All these features either allready existed in the orginal Smalltalk-80 or have been added without the need to change the language at all. Thinking about changes (refactorings) to exisiting apps, Smalltalk tools like the Refactoring Browser and the code rewriter have yet to be surpassed in the Java world (and probably will never be surpassed without further fundamental changes to the Java language).

But Smalltalk is untyped? With test driven development who cares? A compiler can only ensure the type assertions made by the programmer. What does that mean? Well it could mean that your program is self-consistently wrong. Besides you have to type in all that type info so that your compiler can do the checks (what a chore). With TDD you make assertions about the correctness of your code with respect to its' use. These tests are enforced each time you build. So if you've got unit tests who needs type safety?

Alan Kay, the inventor of Smalltalk allways envisioned that computers would become easier to program. So easy in fact children could do it. In this view of the world, the interface to a computer is its' programming language. So a graphical user interface becomes a programming language for end users.

I got to put this idea to the test the other day. Whilst playing with Squeak, my girlfriend decided to pop herself on my knee and took a look at what I was doing. I was playing with the Alice framework port (Alice.org). Alice is a3D graphical framework which allows you to create a 3D world populated by Actors. On the screen was a pink bunny rabbit wearing dark glasses and carrying a drum and a mallet. I entered a few Smalltalk expressions asking the system to 'do-it' each time, and watched my girlfriends expression as the bunny respond to my every command. She soon caught on, and started entering commands of her own: "bunny head turn." Getting bored I was about to issue "bunny destroy" when she stopped me. "No you can't do that to such a cute bunny, make it beat the drum instead". At this point she grabbed the keyboard an typed "bunny beatDrum", but the system responed with: " bunny didNotUnderStand".

Within 5 minutes with no instruction from myself, my girl friend was coding in Smalltalk. Maybe Alan Kay was right! The didNotUnderstand message was a bit of a bummer though. What would she need to do to make the rabbit beat the drum? Well the following expression may work: "bunny mallet beat" or there could be another sequences of messages that would work. If not she would have to define and implement a message her self. This is were things would become difficult. How do you make a bit mapped representation of a mallet move in 3D on a 2D surface? You would have to calculate the position and colour of a lot of bits. This would require a lot of maths. Perhaps there is an intermediate abstraction that could help, like the Morphic framework. Even so you would still need to know a lot to use it effectively. So much for simplicity and end user programming.

I've recently read an interview on the web by Alan Kay, where he was somewhat despondent on the direction computer languages have taken over the last couple of decades. His feeling is that good enough short termism has allways won out over good sound engineering principles. He is right, but I do think he missed something. Computers do very simple things very quicky. To do something meaningful (like beat a drum) the computer needs to perform a very large number of very simple operations in a pre-determined sequence. Here in lies the complexity. Abstracting can hide the complexity some what. For example, the bunny responds to a small number of simple messages, pretty simple, but when the appropriate abstraction does not exist, complexity raises its' head once more.

Because of this complexity the world cares very little for programming. Its' too hard and requires far too much skill. Instead people hire other people to do their programming for them. All they care about is whether the solution is performant, functional and affordable. It is the programmers problem to "talk" to the computer. For the programmer his main concern is that he can get work (using a language that he knows and is popular) and that the solution is "good enough". Untill users are aware of the long term costs of "good enough" solutions nothing will change. So there we have it. Looks like I'll be using Java for some time to come then (Is there anyone out there with a lot of money who fancies marketing Smalltalk? No? I didn't think so).

Making programming pay

Making programming pay

Hi All,

My first blog. Not sure what this is going to mean to me. My first thought is that this is a nice way to express my feelings and ideas. You know, kind of like a diary - personal. So I apologies for not providing lots of information about me.

Perhaps in time I'll get use to the idea of sharing my life with a load of people I've never met. I guess at that time I'll say more about myself, but for now, I am a graduate with 15 years software development experience behind me.

In that 15 years I've been everything from a junior programmer, to a line manager. Currently I'm contracting as a Java developer in the J2EE market.

In my time I've often been frustrated at the inefficiencies present in most large organizations. I have found it difficult living with the ineffective way that companies exploit technology, very often providing little value to the business and impoverishing the lives of developers. It was these frustrations that lead me to contracting.

The contractors motto is "keep quite do what your told, and count the money". But does this approach really pay? Perhaps you can do it for a few years grab the money and run (my dream is to run a bar on a beach somewhere in the Caribbean), but is this approach a long term alternative? I think not!

That is why I named this blog "Making programming pay". I am using the term pay in its' broadest sense. What I really mean is finding fulfillment in creating software. Finding value and purpose in your work. I have a friend who is an housing officer, and to hear her talk about the value she adds to her clients lives and their appreciation and the fulfillment she gets from her working day - just serves to remind me of how un-rewarding programming can be, especially for the experienced programmer who has spent more then his fare share of time in the trenches.

I have tried several approaches to making my work more rewarding. For me, working for myself offers the greatest opportunity for rewards. As a contractor I have just come through lean times, what with the burst of the internet bubble and the looming menace of Bangalore - at times I thought my career as a programmer was up. In adversity I decided to launched my own software development business. Ultimately this failed, hence my return to contracting, but the experience taught me a lot.

Everyone is beginning to wake up to what experienced programmers have known for ages. Software development is about people. The Agile movement , in particular SCRUM stresses the importance of allowing good people to do what they do best, namely get on an produce code the best way they see fit.

In this movement I see the opportunity for good developers to finally get paid. Small highly skilled, self-organised teams with the freedom to do what they know will work. There is clear evidence that the offshore experiment has failed, I think Agile is the next thing the industry will turn to in an attempt to reduce costs and improve value.

I also believe that Agile practices and values can create the type of working environment, where most programmers would feel fulfilled and valued. Work that pays. The type of working environment that didn't make me feel embarrassed when I hear other proffesionals talk about their working lives.

I don't see traditional organisations responding quickly to the opportunity Agile values and thinking provides - instead I hope that small independent "7 plus or minus 2 sized" software businesses will emerge to meet the demand. Due to the high communication bandwidth needed for agility - these businesses will need to work very closely with their clients, possibly embedding themselves within the client organization. And I don't mean consultancies like Thoughtworks that allow themselves to grow to a size where they end up as political as the traditional consultancies they hope to replace.

Another model is small software businesses producing off the shelf software. Such software could be leased/sold over the internet or sold in a more traditional fashion. Such companies could target vertical markets delivering value to small and medium sized clients who cannot afford bespoke software, or the general public. In fact I have ideas for a couple of products that fit this model. I will develop this theme in future blogs.

Akin to improving the way software is developed, I also believe that there is a culture change required to improve the way software is envisioned and commissioned. Again SCRUM offers a "human scaled" model for envisioning how to add value to an organisation through software development over time. SCRUM advocates small teams working on independent projects and sharing stable components where possible. Shared stable infrastruture is mined button up, through constant refactoring, and application teams constantly communicating.

I have seen ambitious "enterprise scale" projects fail due to this lack of human scaled vision. How many business analysts or Systems architects are willing to say, that they do not know what the entire enterprise wide architecture should be? But the reality is that they don't know, and if they do invest the time and money trying to find out, buy the time they are finished their enterprise wide blue print is out of date and life as moved on. So much for top down SOA. How many organisations are courageous enough to stop the "big" project juggernaut once its' gained momentum? Better still, how many organisations are wise enough to avoid the "big" project all togetner and to adapt and grow systems bottom up? I will blog more on this subject in the future too. Needless to say that better project vision and scope would add tremendously to the quality of programmers lives.

I will end for now other than to say that if there are other like minded contractors out there wanting to get paid in the full sense of the word, please comment with your views.

Regards all,

Paul.