Haiyan Explodes into 190 mph Monster — Now World’s Strongest Hurricane Since 1980

November 7, 2013 by

Haiyan Explodes into 190 mph Monster — Now World’s Strongest Hurricane Since 1980.

Something a little bit magic: and the mountains echoed

September 25, 2013 by

Something a little bit magic: and the mountains echoed.

PROJECT TWO: 2013: The Year of Suggestions

December 29, 2012 by

PROJECT TWO: 2013: The Year of Suggestions. Any suggestions for my daughter?

Man flu made me think

March 15, 2009 by

Three weeks ago I got flu. Serious flu. 103F flu. I took three days off work, but took 18 days to stop blowing my nose. And, even now, I’m run down with a couple of ailments. (That’ll teach you to ask me “How are you?”)

I’ve not been as effective as normal. Or have I? It’s been harder to engage. It’s been harder to structure a long string of thoughts. I’ve attended fewer meetings. I’ve dominated fewer conversations.  My little world did not stop turning on its axis. I’ve not been haring around with ten hours of back-to-back meetings and calling it work.

Instead people have approached me with their issues. “How do I best approach Purchasing to get something done?” “Should we even think about this one off piece of software?” “How do we go about boiling down a few thousand free text responses to a questionnaire?” “This component isn’t acting as I expected, can I just chat it through?”

Their issues. But presented to me not in a “you boss you set agenda you take decision” but in a “I could do with some help and I think you’re quite good at this” way.

Yes, some of this is about shifting the agenda from the formal to the informal. But I noted two generalisations:

  • There were a lot of  “should we’s?” I was being approached on “are we doing the right things?” (Ok, I grant I’m an unlikely person to approach to ask “am I doing this the right way?” But I’d rather focus on my strength for a moment.)
  • There were a lot of “how do we simply?” In the face of a mass of confusion where did we leave Occam?

So, in terms of my strengths as others perceive them, I was used to simplify, strategically and tactically. I wasn’t asked what the best process to do something was. I wasn’t asked to design processes. I wasn’t asked to review budgets. I was asked to simplify, remove steps, boil to the essence. I was asked how cut to the chase and cut through the crap.

In this pay forward, play to strengths, era, this has me thinking – if that’s the value people seek from me spontaneously, should I emphasise this more?

If you were ill and slightly under the weather for a while – and let down your guard a bit – what do you think your “oh, while you’re not too busy” value added be?

Religion and bigotry in software development

March 5, 2009 by

I don’t really regard myself as an IT person, so I am a bit surprised to find myself pontificating about software development again. For the record, I spent 13 years as an IT professional, before crossing over to the business side where I have, pretty much, been running or consulting on large change programmes for the last 14 years. These programmes have invariably been IT enabled. My distance from how the IT people do what they do has varies, depending on the inherent risks and issues.

If my intuition tells me there is a problem brewing with something IT related, I am going to go digging until I am comfortable. Right now, I am working on something that has provoked me to look at the approach we are taking to developing software. The first project on this particular got into all sorts of trouble and I would really like to help the organisation avoid making the same mistakes again.

What I have come up against is religion and bigotry. In the organisation I have in mind, there are two religions: “Waterfall” and “Agile”. The followers of Agile believe that those who do not follow or understand their beliefs are deluded individuals who live in a past that no longer works. The followers of Waterfall tend to be older than the young Agile radicals. They have seen it all before and have seen many false religions proclaimed, only to fall by the wayside when tested in what they refer to as “the real world”. There is no common ground. Each regards the other as heretical. I believe that there are good elements in each depending on the situation. I also believe there are good things in other religions that are no longer widely worshipped.

The history of software development is littered with “methodologies” that bear all of characteristics of religions. A very smart, charismatic person finds that the dominant religion of the time does not do not bring the salvation that was promised in their situation. They explore new ideas. The experiment with those ideas and refine them. They begin to discuss their ideas with critically minded individuals. Some of those individuals become disciples and spread the word. But then, crucially, as with all religions, the disciples interpret what the guru has said and write it down. The written word becomes the law, especially for new recruits who have no direct access to the guru. The original context is lost and now there is only the law and zealots.There is a ton of good stuff in “Agile” and I have already referenced Ken Schwaber’s excellent video in an earlier post. But as I continued on my dig, much of the stuff I read by Agile acolytes uses the terms “must” and “always” far too often for my comfort. Every new religion believes that it the only truth path. Actually, software development is often more like fashion that religion. I seem to recall experiencing.

  • Structured Programming (notably Djkstra)
  • Jackson Structured Programming
  • Structured Systems Analysis (De Marco et al)
  • Functional Decomposition (Yourdon et al)
  • Spiral Model of Development (Boehm)h
  • Information Engineering (IE)
  • 4th Generation Languages (4GL’s such a Natural)
  • Mathematically provable software (e.g.Z)
  • Finite State Modelling
  • Application Generators (e.g Telon)
  • Rapid Prototyping
  • Evolutionary prototyping
  • Joint Application Development (JAD)
  • Business Process Modelling (BPM)
  • Object Orientation (OO) – does anyone really use inheritance?
  • Object Oriented Analysis and Design (OOAD)
  • Unified Modelling Language
  • Architecture Driven Development
  • Unified Process
  • Dynamic Systems Development Method
  • Service Oriented Architecture – functional decomposition in disguise?
  • Scrum
  • Agile
  • Extreme Programming (XP)

I am sure you could add to the list.

Some of the above were progression from other son the list. Others discarded what had come before. But all have something to offer in the appropriate situation. Why not dip in and see what a Data Flow Diagram of the problem space might reveal? Or perhaps consider whether your off-shoring behemoth could be delivered in discrete working increments? Or could the problem be solved with a Finite State Machine? And so on.

If you need religion then how about being a software Buddhist. See your principles as guiding your journey but let other religions fulfil other complimentary needs as well?

Death by PowerPoint

February 25, 2009 by

Picture the scene: Barack Obama walks to the middle of the stage and taps a key on a laptop.

Obama Powerpoint 1

“My fellow Americans, most of you probably know who I am by now but just in case not, I am Barack Obama and I am your new president. I’ve invited you here, so that I can run through about 30 or so slides that set out the aims of my presidency. And of course to have some drinks.”

Obama pauses, steps forward and taps a laptop key.

Obama PowerPoint 2

No of course it didn’t happen. The most engaging political speaker of his generation doesn’t do PowerPoint slides. Nor for that matter does Tom Peters or any number of business or political speakers. In fact, the video clip on my previous entry shows a technical but terrific presentation powered only by a felt tip marker and a whiteboard.

So why do speakers within our organisations, such as I suffered this evening,  persist in subjecting us to slide after slide of bullet points, designed to assist the speaker rather than the audience. Of course, styles vary. Some people simply read out the bullet points, extemporising as the fancy takes them. Others don’t even refer to the the bullet points, leaving us to wonder whether we should be reading or listening and failing to do either.

“It is a about time we did an update for the troops,” says the boss.

“Absolutely, communication is so important,” says Bob.

“So what shall we talk about?” asks the Boss.


The boss is forced into action. “Bob, you can talk about Project Nectar, we haven’t done an update on that for a while.” Bob nods with a tight lipped smile. “Laura, you can talk about the strategic roadmap for the global capability outsourcing initiative. And Dave, you can talk about the work we have been doing on vales and behaviours.”

“Great”….”Sure no problem”….”Look forward to it”.

“So,” says the boss, “that means that you need to get your slides to me for review by close tomorrow, OK?”

And the steamroller is off and running. Each prepares about 10 slides, mostly in bullet points with one or two existing graphics – time is too short to do anything more creative.

Now, I reckon it take a minimum of 2 minutes to get through a slide, even if one just reads it out. So 30 slides equals a minimum of 60 minutes of being talked at. Now consider that a feature film, packed with pyrotechnics and tricks, needs to be pretty good to keep your attention for 60 minutes. It is going to feel like a long afternoon for the audience.

Not everyone can be Barack Obama when it comes to oratorical skills but everyone can learn from him

  • Tell an interesting story
  • Relate it to your audience’s experience
  • Determine the 3 key things you want people to remember
  • Learn to use rhetorical devices – say things in memorable ways
  • By all means use pictures and graphs if they enhance rather than repeat what you are saying
  • Use notes if you need reminders – no one minds
  • Bring it up a level from the level of detail you think is needed – no-one is as interested the detail as you
  • Keep it short – people reach saturation point after about 20 minutes

For help with the above, I strongly recommend Lend Me Your Ears: All You Need to Know About Making Speeches and Presentations

Agile and all that

February 22, 2009 by

In my previous post, I banged on about the need to deliver things “incrementally”.  Well here is a great to talk to a team at Google that really sets out the essence of the approach. It is an an hour long but if you are in software development, you’ll find that the the time zaps by.

Software requirements, risk and offshoring

February 22, 2009 by

One of my clients is an organisation whose business is managing risk. Unsurprisingly, aversion to risk pervades their corporate culture, including software development.

About 18 months ago, they decided to use a world-leading offshore software development organisation for a major new project. It was a long time since they had done anything as large, so they were keen to get the “requirements right”, especially as the development work was going to be done offshore. Unfortunately, this meant that they spent a very long time writing the requirements in enormous detail.

I say unfortunately because my experience is that that trying to write a  “perfect”  set of requirements is self-defeating. The approach resulted in a huge volume of paper which had to be signed off by a large number of people. Not only did this take a long time but with such a large volume of paper, it was expensive and things got missed. Needless to say, once the requirements went offshore, they were not interpreted in the way that the authors expected.

It is twenty years since Barry Boehm proposed a Spiral Model of development. Since then, we have had a range of approaches that sought to tackle the problem of writing full requirements, including 4GL’s, Rapid Prototyping, JAD, Iterative Development and now, fashionably, Agile.  All recognised that it simply isn’t possible to write perfect requirements. They all devised approaches to reduce the risk through regular deliveries of chunks of the finished, or near finished, software. Usually, this meant that the developers interacted closely with the users and were sometimes co-located.

I think the need for this type of apporach was accepted by 80% of the industry. But then along came offshoring. People compared day rates and skill sets, and concluded that offshore is cheaper. But as the work is being done offshore, the response of many companies was to go back to a waterfall approach, so that the full requirements can be handed off to the offshore team. Offshore companies try to mitigate the risk by having onshore teams but, often, they are not as tightly integrated with the development team as one might think. Cheaper rates do not translate into lower costs if the requirements take forever and the delivered software doesn’t meet the organisation’s real needs, as was the case in this instance.

I am about to help my client embark on the next phase of development. I have advised them to emulate an iterative approach by getting early and regular visibility of designs and developed software. As a minimum, they need to insist on prototypes, wire-frames, models and examples. Ideally, they need to insist that the software is delivered in regular coherent chunks. In adddition, I have advised my client that they need transparency of the supplier’s organisational struture, to fully understand where the supplier’s people fit in. They need to inist that the development orgnisation is directly involved, not just an “Implemetation Team”.

My inuition is that this is not the way the developer works and it is going to be a battle to get them to change. But I believe it is a battle worth fighting and will benefit both client and supplier in the long run.

I have set up a category for the project, named Project O, and will try to post regularly to that category, so that you can see how things turn out.

Engaging contract staff

February 19, 2009 by

A recent entry at Tom Peter’s site about workforce engagement pointed out that, in times of economic downturn, we need to pay attention to the people who remain within our companies. I couldn’t agree more but would point out that this needs to apply as equally to freelance and independent contract staff as permanent employees.

A company that I know of recently cut contract rates for IT staff by 10 to 15% across the board. To some, this might seem like smart management, responding to market conditions. After all, isn’t the role of contract staff to insulate permanent staff when things get tough? Well yes but, perhaps, by shedding labour rather than reducing contractor income.

Contractors know that they will get the chop when things are tough. But the quid pro quo of this is that they get a very good rate when they are in work. Cutting their rate just cuts their commitment to the organisation. And in this particular instance, over 50% of the IT workers are contractors. Many have worked for the company for years rather than months. Others are there because of the specialist skills that they bring. commanding premium rates.

Leaving aside the wisdom of a 50% ratio, across the board cuts are not a great recipe for workforce engagement. Contractors are an essential part of the workforce and need to engaged like anyone else. They also have the characteristic of being more likely to switch organisations than permanent employees. The ones that add the most value may not be able to leave straight away but will do so when opportunities arise, taking knowledge and skills with them.

Creating the pain

February 15, 2009 by

I so agree with the previous entry. I spent a very unhappy six months with one of the world’s largest management consultancies. “What,” I asked my managing partner, “are our key points of view on the issues affecting our target industry?”

I was advised that, “we don’t do points of view,” as if I had suggested something ungentlemanly. Their strategy was to offer help – a great sales technique!

My preference, if I was lucky to get in front of someone senior, was to tell them something they don’t already know. Something like: “from our research, this what we think is going to happen. If you don’t do X then your competitors will.”

They might not agree with what you are saying but if you can make them shift uneasily in their seats, thinking that maybe, just maybe, there is something they need to worry about, then you are on the verge of  a sale. And of course this applies as much to influencing from within an organidation as it does from without.

So if the person you see to influence doesn’t  have pain then maybe you can create it?