I stumbled across websites as graphs a couple of days ago, lots of fun. Even a small one like www.allankelly.net looks good. Try a big site (no I won’t mention any incase I get into trouble) for more fun.
This blog is now at: https://www.allankelly.net/blog/ You should be redirected shortly. If you have any problems with it please let me know.
Wednesday, April 23, 2008
Monday, April 21, 2008
1-day Agile Project Management Course
I mentioned Liz Sedley in my last post and she noticed! She’s asked me point out that she still has places left on her 1-day Agile Project Management course in London this Friday.
What’s more she promises a discount to anyone who mentioned my name when booking.
What’s more she promises a discount to anyone who mentioned my name when booking.
Sunday, April 20, 2008
ACCU 2008 sessions now on line
Back on topic now.
I have uploaded my sessions from ACCU 2008 to my website. I did one session with Liz Sedley entitled: The Developer, The Customer and Their Requirements and another solo session entitled: Managers: What are they good for?
As usual I did I post conference write up of my session and the notes are freely available.
An innovation this year - Liz’s idea - was to provide attendees with a one page summary of the session. I did one for both sessions and both are online, please let me know what you think.
I have uploaded my sessions from ACCU 2008 to my website. I did one session with Liz Sedley entitled: The Developer, The Customer and Their Requirements and another solo session entitled: Managers: What are they good for?
As usual I did I post conference write up of my session and the notes are freely available.
An innovation this year - Liz’s idea - was to provide attendees with a one page summary of the session. I did one for both sessions and both are online, please let me know what you think.
Heathrow part 2 – a major learning failure
I’m really disappointed, for years I’ve been pointing to Terminal 5 construction as a great example of lean ideas at work. It gets delivered on schedule and then what? Mess. Seems everyone will forget it was on time and remember the opening week nightmares.
How come after being an exemplar of Lean techniques during construction Terminal 5 was such a mess at opening?
To recap: BAA decided that T5 was such a big project, and so strategically important, that they couldn’t follow “traditional” construction practice and outsource it to the cheapest bidder. (A quick look at the Wembly Stadium debacle is enlightening.) So, BAA more or less re-invented construction project management along lean principle and delivered their new terminal on time and on budget.
Then BAA handed over T5 to British Airways who messed it up. Weeks of passenger delays, cancelled flights, lost baggage and humiliating publicity which some have called a “National disgrace”.
Most of the problems seem to have been on the BA end but BAA is not in the clear. BAA treated T5 construction as a project, the project (mostly) ended when T5 was given to BA. At that point the bad management, sloppy thinking, and lack of customer respect endemic in the rest of BAA came to T5.
The BAA side of things is an example of how the Project Approach is wrong. BAA should have taken a Product Approach. The product needs to be fully in use, product development continues.
Lesson for software companies: It is a Product, Not a Project.
Now to BA.
From the reports I have read BA has confrontational management. Managers were scared to report problems up the chain so senior managers never heard of problems.
Lesson for software companies: Managers need to stay in contact with what happens on the ground. How actual employee are doing their jobs. Macho management is bad management.
Moving into T5 stretched BA’s resources. Staff from T1 had to move to T5 and find their way around a new terminal with new machines. They had only had limited time to familiarise themselves with the terminal and equipment. In fact, during the learning process they needed more time than usual.
Lesson for software companies: Allow time for learning, don’t skimp; over-staff your departments when big changes are happening. The time of change is not the time to extract savings. That comes later.
Not only is BA confrontational but it has poor employee relations. I suspect the flow of ideas between employees and managers is poor. Employees probably aren’t willing to trust managers and give extra performance. Why should they be?
Lesson for software companies: Trust your employees, help them trust you.
Rightly BA didn’t attempt to move all their flights in one go. However, they did move an awful lot in one wave, and at the same time moved other flights from Gatwick to Heathrow. This wasn’t an incremental delivery.
Lesson for software companies: Incremental delivery means many small deliveries. Not two big ones.
It seems we have a major learning failure at T5. BAA construction teams learned completely new ways of working to deliver on time. But this learning failed to cross the boundary to BAA operations and BA. How often have we heard that before?
How come after being an exemplar of Lean techniques during construction Terminal 5 was such a mess at opening?
To recap: BAA decided that T5 was such a big project, and so strategically important, that they couldn’t follow “traditional” construction practice and outsource it to the cheapest bidder. (A quick look at the Wembly Stadium debacle is enlightening.) So, BAA more or less re-invented construction project management along lean principle and delivered their new terminal on time and on budget.
Then BAA handed over T5 to British Airways who messed it up. Weeks of passenger delays, cancelled flights, lost baggage and humiliating publicity which some have called a “National disgrace”.
Most of the problems seem to have been on the BA end but BAA is not in the clear. BAA treated T5 construction as a project, the project (mostly) ended when T5 was given to BA. At that point the bad management, sloppy thinking, and lack of customer respect endemic in the rest of BAA came to T5.
The BAA side of things is an example of how the Project Approach is wrong. BAA should have taken a Product Approach. The product needs to be fully in use, product development continues.
Lesson for software companies: It is a Product, Not a Project.
Now to BA.
From the reports I have read BA has confrontational management. Managers were scared to report problems up the chain so senior managers never heard of problems.
Lesson for software companies: Managers need to stay in contact with what happens on the ground. How actual employee are doing their jobs. Macho management is bad management.
Moving into T5 stretched BA’s resources. Staff from T1 had to move to T5 and find their way around a new terminal with new machines. They had only had limited time to familiarise themselves with the terminal and equipment. In fact, during the learning process they needed more time than usual.
Lesson for software companies: Allow time for learning, don’t skimp; over-staff your departments when big changes are happening. The time of change is not the time to extract savings. That comes later.
Not only is BA confrontational but it has poor employee relations. I suspect the flow of ideas between employees and managers is poor. Employees probably aren’t willing to trust managers and give extra performance. Why should they be?
Lesson for software companies: Trust your employees, help them trust you.
Rightly BA didn’t attempt to move all their flights in one go. However, they did move an awful lot in one wave, and at the same time moved other flights from Gatwick to Heathrow. This wasn’t an incremental delivery.
Lesson for software companies: Incremental delivery means many small deliveries. Not two big ones.
It seems we have a major learning failure at T5. BAA construction teams learned completely new ways of working to deliver on time. But this learning failed to cross the boundary to BAA operations and BA. How often have we heard that before?
T5 disappointment - Heathrow part 1
A slightly off topic look at another industries problems...
Why should I blog about airports? – this blog is about the business of software development. Well I could argue that its all business and within remit but I’m still its stretching it a little.
The reason to blog about terminal 5 (T5) is because past I have held it up as an outstanding example of lean practices in action.
• Compare and contrast: Terminal 5 and Wembley Stadium
• Terminal 5 is Lean
T5 is part of Heathrow airport, and Heathrow is owned an operated by BAA. In the past I’ve talked about T5 in isolation but, as all good system thinkers know, we have to look outside the immediate to understand the whole.
I think there are some interesting lessons to be learned from the recent mess at T5 and at Heathrow in general over the last few years. Some of these lessons might just help software developers.
Lets start with the re-occurring horrors that are Heathrow airport – well talk about the T5 opening mess another day. Take some examples:
• Disruption and Flight backlogs
• Reoccurring delays
• Baggage handling problems and cancellations
• Knock on problems elsewhere
• General unhappiness with the airport - I agree, I live close enough to it to make it pointless trying to use another and the experience is ghastly.
The paradox at Heathrow is that while T5 has been an exemplar case-study in Lean Thinking the rest of Heathrow shows many of the faults of traditional thinking non-lean thinking.
Travelling through Heathrow is an exercise in queuing: Lean Thinking tells us how to manage queues. Heathrow is an operating at the absolute limit of capacity, therefore it is highly efficient but prone to disruption. The slightest problem and everything is messed up.
While BAA managers have claimed that the opening of T5 would solve the problems they ignored changes on the existing terminals that would make real improvements for passengers. They have looked for a single big fixed (T5) over a myriad of smaller fixes.
For example:
• Why not strip out some shops and provide more seating? Why not strip out some shops and make popular ones bigger? OK I know why, because they make more money, we’ll come to that.
• Why not copy Liverpool airport and give people the option to pay for fast-track security? People who have a genuine choice will be more accepting.
• Why not give free water bottles for people who have their water taken off them at security?
• Why make it worse for passengers with petty, pointless rules? - the one that caught me last year was taking a cup of coffee (bought airside) with me to the departure gate. This is not allowed. Why not?
(By the way: has anyone noticed the one place at Heathrow where you can’t by a Grande Cappuccino? – The baggage hall, waiting for a case which may, or may not, appear is devoid of shops. Yet it’s the place where I’m usually most gasping for a drink, chocolate or newspaper to read while I wait.)
Part of the reason BAA has gone for the one big fix is because the myriad of small fixes requires staff co-operation, and it turns out Heathrow is a bastion of confrontational management, highly unionised workforce and prescribed working practises.
Customers have very little choice: BAA control the three biggest airports in the London area. Once you are at the airport BAA control everything you can do – doubly once you get through security.
So what are the lessons for software developers?
• Lean/Agile has its limited: No matter how lean T5 construction was the rest of the airport is a disaster. One group doing lean will not automatically infect everyone else.
• Pay attention to your customers: if you treat them badly they will start to find ways to buy competitor products, or simply stop buying (travelling). Vendor lock-in will eventually be broken.
• Queues work, they make you more efficient but they reduced your ability to react and change. Nobody likes queues, they make us all miserable. The fact that many software queues are hidden is no better.
• Management need to co-operate with those who do the work. They need to accept that a million small solutions can be as worthy as one big one.
• Short term gain (all those shop rents) detracts from long term improvement and customer experience. Sometimes the bottom line has to take second place.
Fundamentally the economics of Heathrow (and BAA and BA) are just wrong. I might go into that some other time, for the moment I’ll refer you to the Economist. Their analysis and solution is spot on. The objectives of BAA, shop holders, Government security, airlines and passengers are at odds. Nobody seems to benefit.
Perhaps the biggest problem is the business models of BAA and British Airways (which dominated Heathrow and is dominated by the airport) are utterly dependent on squeezing as many people through the airport as possible. This is not good for our national economy – let along London – but because BAA and BA carry so much political clout they are able to keep the Heathrow economic-fantasy protected. Making Heathrow responsive to real economics (as we did with coal mines, ship yards, steel factories and car companies) would actually solve the problems.
So the last lesson: It’s the Economics, stupid.
Software companies, unlike Heathrow, live in the real economic world. In the short run a company may be able to run a business model which harms its customers but customers have choice. So you’ve got to get the economic incentives aligned. If you are developing software make sure your economics benefit everyone: what is good your customer should be good for you.
Why should I blog about airports? – this blog is about the business of software development. Well I could argue that its all business and within remit but I’m still its stretching it a little.
The reason to blog about terminal 5 (T5) is because past I have held it up as an outstanding example of lean practices in action.
• Compare and contrast: Terminal 5 and Wembley Stadium
• Terminal 5 is Lean
T5 is part of Heathrow airport, and Heathrow is owned an operated by BAA. In the past I’ve talked about T5 in isolation but, as all good system thinkers know, we have to look outside the immediate to understand the whole.
I think there are some interesting lessons to be learned from the recent mess at T5 and at Heathrow in general over the last few years. Some of these lessons might just help software developers.
Lets start with the re-occurring horrors that are Heathrow airport – well talk about the T5 opening mess another day. Take some examples:
• Disruption and Flight backlogs
• Reoccurring delays
• Baggage handling problems and cancellations
• Knock on problems elsewhere
• General unhappiness with the airport - I agree, I live close enough to it to make it pointless trying to use another and the experience is ghastly.
The paradox at Heathrow is that while T5 has been an exemplar case-study in Lean Thinking the rest of Heathrow shows many of the faults of traditional thinking non-lean thinking.
Travelling through Heathrow is an exercise in queuing: Lean Thinking tells us how to manage queues. Heathrow is an operating at the absolute limit of capacity, therefore it is highly efficient but prone to disruption. The slightest problem and everything is messed up.
While BAA managers have claimed that the opening of T5 would solve the problems they ignored changes on the existing terminals that would make real improvements for passengers. They have looked for a single big fixed (T5) over a myriad of smaller fixes.
For example:
• Why not strip out some shops and provide more seating? Why not strip out some shops and make popular ones bigger? OK I know why, because they make more money, we’ll come to that.
• Why not copy Liverpool airport and give people the option to pay for fast-track security? People who have a genuine choice will be more accepting.
• Why not give free water bottles for people who have their water taken off them at security?
• Why make it worse for passengers with petty, pointless rules? - the one that caught me last year was taking a cup of coffee (bought airside) with me to the departure gate. This is not allowed. Why not?
(By the way: has anyone noticed the one place at Heathrow where you can’t by a Grande Cappuccino? – The baggage hall, waiting for a case which may, or may not, appear is devoid of shops. Yet it’s the place where I’m usually most gasping for a drink, chocolate or newspaper to read while I wait.)
Part of the reason BAA has gone for the one big fix is because the myriad of small fixes requires staff co-operation, and it turns out Heathrow is a bastion of confrontational management, highly unionised workforce and prescribed working practises.
Customers have very little choice: BAA control the three biggest airports in the London area. Once you are at the airport BAA control everything you can do – doubly once you get through security.
So what are the lessons for software developers?
• Lean/Agile has its limited: No matter how lean T5 construction was the rest of the airport is a disaster. One group doing lean will not automatically infect everyone else.
• Pay attention to your customers: if you treat them badly they will start to find ways to buy competitor products, or simply stop buying (travelling). Vendor lock-in will eventually be broken.
• Queues work, they make you more efficient but they reduced your ability to react and change. Nobody likes queues, they make us all miserable. The fact that many software queues are hidden is no better.
• Management need to co-operate with those who do the work. They need to accept that a million small solutions can be as worthy as one big one.
• Short term gain (all those shop rents) detracts from long term improvement and customer experience. Sometimes the bottom line has to take second place.
Fundamentally the economics of Heathrow (and BAA and BA) are just wrong. I might go into that some other time, for the moment I’ll refer you to the Economist. Their analysis and solution is spot on. The objectives of BAA, shop holders, Government security, airlines and passengers are at odds. Nobody seems to benefit.
Perhaps the biggest problem is the business models of BAA and British Airways (which dominated Heathrow and is dominated by the airport) are utterly dependent on squeezing as many people through the airport as possible. This is not good for our national economy – let along London – but because BAA and BA carry so much political clout they are able to keep the Heathrow economic-fantasy protected. Making Heathrow responsive to real economics (as we did with coal mines, ship yards, steel factories and car companies) would actually solve the problems.
So the last lesson: It’s the Economics, stupid.
Software companies, unlike Heathrow, live in the real economic world. In the short run a company may be able to run a business model which harms its customers but customers have choice. So you’ve got to get the economic incentives aligned. If you are developing software make sure your economics benefit everyone: what is good your customer should be good for you.
Wednesday, April 16, 2008
Speaking in Cambridge: BCS, IIBA and Cambridge Examination
I’m speaking in Cambridge at the end of the month – evening of 30 April to be exact. This is a join event between: the British Computer Society, Cambridge Examinations and the International Institute of Business Analysts. To be honest, I’m a little intimidated by these three heavy weight organizations, they are all quite serious…
The subject is the role of Business Analysts in Agile development. I’ve entitled my bit “Agile Practices go better with Business Analysis.” I believe the event is open to all comers more details at:
Basically I’ll be making my ‘bottleneck has moved’ argument and describing how product owners (whether business analysts or product managers) can keep things moving along. Much of this derives from lean thinking: its not enough to do things better, we need to do less of the wrong things. Along the way I’ll also be touching on the ‘alignment trap’.
Hope to see you there!
The subject is the role of Business Analysts in Agile development. I’ve entitled my bit “Agile Practices go better with Business Analysis.” I believe the event is open to all comers more details at:
Basically I’ll be making my ‘bottleneck has moved’ argument and describing how product owners (whether business analysts or product managers) can keep things moving along. Much of this derives from lean thinking: its not enough to do things better, we need to do less of the wrong things. Along the way I’ll also be touching on the ‘alignment trap’.
Hope to see you there!
Monday, April 14, 2008
The Trouble with Retrospectives
The Agile Journal has published one of my articles - The Trouble with Retrospectives can be read for free. This months issue has several other pieces on retrospectives which I’m looking forward to reading.
Friday, April 11, 2008
Presentation, exercises and results from SPA 2008
At SPA 2008 conference a few weeks ago now I ran a workshop with Lise Hvatum on the subject of ‘Closing the Knowing Doing Gap.’ I’ve now posted the details on my website. These include: our presentation, the dialogue sheets we used to facilitate the discussion and a summary of the results from the three teams.
Everything is here - ‘Closing the Knowing Doing Gap’
I hope to get my presentation and output from the ACCU 2008 conference up in the next few days.
Everything is here - ‘Closing the Knowing Doing Gap’
I hope to get my presentation and output from the ACCU 2008 conference up in the next few days.
Sunday, April 06, 2008
More comments on ACCU conference
Some more comments, observations and thoughts about, and provoked by, the ACCU conference. No particular linking theme.
Jobs and banks
There were a lot of bankers at the conference this year - or rather developers who work in banks. In truth this is always the case but this year I think there were more. It also gave the opportunity to find out what was happening in the financial job market.
Before Christmas I think many people were expecting a shake-out similar to that of 2001/2002 but it seems the effect of the crisis or credit crunch is very mixed. I observed a few weeks ago that one effect has been to push up rates and while some banks do seem to be shedding staff others are still hiring and demand is strong. I talked to someone from one (American) bank which had drastically cut back staff, while people at another (English) bank were still hiring lots, and another (Scottish) bank which recently bought another (Dutch) bank is having to hire lots of people to help integrate the systems of the two banks.
Lies, Damned Lies and Statistics
I’ve had a downer on metrics and statistics for a long time. But I’ve also been aware that getting the right data and measuring the right numbers is often the key to success. Tom Gilb is firmly in the numbers and metrics camp and argues a good case for measurement and targeting. I was lucky enough to spend lots of time listening to Tom and talking to him.
It seems that, as with so many other things in life, the key is doing it right. It is very easy to set the wrong targets, to measure the wrong thing and produce side-effects you don’t want. But when you look at the right numbers, measure the right thing, and set the right targets you can get great results.
But it isn’t easy, most people get it wrong.
Tom is a fascinating guy, if you ever get the chance to hear him speak do so. A lot of his ideas come directly from Deming - who he knew personally. I don’t think it is too much of an exaggeration to say Tom may be the Software World’s own Deming. If nothing else Tom interprets Deming’s message for software development.
Software development success
In an aside Tom also pointed out that the UK now has Royal Academy of Engineering and that they (not so) recently produced a report on software development. Its a shame that you can’t down load the report, I’d like to read it.
I notice the comment that “only around 16% of IT projects can be considered truly successful”. That 16% seems very close to the figures given in the MIT Sloan Review piece on the IT alignment trap last year. That report said 7% of companies had effective IT departments which delivered on business objectives and another 8% who were effective but were not aligned with the business.
Unfortunately that means 85% of us are working on failing projects. Depressing.
The 1968 wrong turn reconsidered
I’ve been heard to say that somewhere about 1968 the software industry took a wrong turn. We went down the route of engineering, planning and tools rather than people and learning. But the conference made me wonder, maybe it wasn’t such a wrong turn, maybe it was a diversion we needed to take so we could solve some problems. Now those problems are kind of solved we need to refocus on the people.
Maybe.
Product Managers
I have long claimed that UK business do not get Product Managers, this might now be changing. The term Product Manager was in wide use and more people seemed to have a Product Manager on their team.
Lets hope I’m right.
Still, there are too few Product Managers, too few of them are really good, their role is still misunderstood and there is not enough training for them.
Next years conference
I’m no longer on the committee for the conference but I still have conversations about it. It is already taking shape in peoples heads and promises to be an even better conference. For better or worse the conference is unlikely to get any bigger. If it were to get bigger it might loose some of its flavour.
I think the next 2-3 years will be an interesting time in the UK and European conference scene. The arrival of the profit making QCon is having an effect and I know there is some debate about the future, style, content and so on of other conferences. At a guess I think you might see one or two new conference appear and others (perhaps) disappear or change.
My book
It was good to see Changing Software Development selling, and fun to sign copies!
Latest figures say it is selling well, yippee!!!
This Blog
I met several readers of this blog at the conference. Seems they want shorter entries. I’ll try my best. But I’ve said this before and failed!
Jobs and banks
There were a lot of bankers at the conference this year - or rather developers who work in banks. In truth this is always the case but this year I think there were more. It also gave the opportunity to find out what was happening in the financial job market.
Before Christmas I think many people were expecting a shake-out similar to that of 2001/2002 but it seems the effect of the crisis or credit crunch is very mixed. I observed a few weeks ago that one effect has been to push up rates and while some banks do seem to be shedding staff others are still hiring and demand is strong. I talked to someone from one (American) bank which had drastically cut back staff, while people at another (English) bank were still hiring lots, and another (Scottish) bank which recently bought another (Dutch) bank is having to hire lots of people to help integrate the systems of the two banks.
Lies, Damned Lies and Statistics
I’ve had a downer on metrics and statistics for a long time. But I’ve also been aware that getting the right data and measuring the right numbers is often the key to success. Tom Gilb is firmly in the numbers and metrics camp and argues a good case for measurement and targeting. I was lucky enough to spend lots of time listening to Tom and talking to him.
It seems that, as with so many other things in life, the key is doing it right. It is very easy to set the wrong targets, to measure the wrong thing and produce side-effects you don’t want. But when you look at the right numbers, measure the right thing, and set the right targets you can get great results.
But it isn’t easy, most people get it wrong.
Tom is a fascinating guy, if you ever get the chance to hear him speak do so. A lot of his ideas come directly from Deming - who he knew personally. I don’t think it is too much of an exaggeration to say Tom may be the Software World’s own Deming. If nothing else Tom interprets Deming’s message for software development.
Software development success
In an aside Tom also pointed out that the UK now has Royal Academy of Engineering and that they (not so) recently produced a report on software development. Its a shame that you can’t down load the report, I’d like to read it.
I notice the comment that “only around 16% of IT projects can be considered truly successful”. That 16% seems very close to the figures given in the MIT Sloan Review piece on the IT alignment trap last year. That report said 7% of companies had effective IT departments which delivered on business objectives and another 8% who were effective but were not aligned with the business.
Unfortunately that means 85% of us are working on failing projects. Depressing.
The 1968 wrong turn reconsidered
I’ve been heard to say that somewhere about 1968 the software industry took a wrong turn. We went down the route of engineering, planning and tools rather than people and learning. But the conference made me wonder, maybe it wasn’t such a wrong turn, maybe it was a diversion we needed to take so we could solve some problems. Now those problems are kind of solved we need to refocus on the people.
Maybe.
Product Managers
I have long claimed that UK business do not get Product Managers, this might now be changing. The term Product Manager was in wide use and more people seemed to have a Product Manager on their team.
Lets hope I’m right.
Still, there are too few Product Managers, too few of them are really good, their role is still misunderstood and there is not enough training for them.
Next years conference
I’m no longer on the committee for the conference but I still have conversations about it. It is already taking shape in peoples heads and promises to be an even better conference. For better or worse the conference is unlikely to get any bigger. If it were to get bigger it might loose some of its flavour.
I think the next 2-3 years will be an interesting time in the UK and European conference scene. The arrival of the profit making QCon is having an effect and I know there is some debate about the future, style, content and so on of other conferences. At a guess I think you might see one or two new conference appear and others (perhaps) disappear or change.
My book
It was good to see Changing Software Development selling, and fun to sign copies!
Latest figures say it is selling well, yippee!!!
This Blog
I met several readers of this blog at the conference. Seems they want shorter entries. I’ll try my best. But I’ve said this before and failed!
Friday, April 04, 2008
At ACCU conference
I am at ACCU conference this again, tonight is the last night so we have the speakers dinner. As usual the conference is very good. As usual there is little C# or Java but C++ is by no means dominant, in fact there are more sessions on functional programming languages (Haskell, Erlang and Lisp) than C++.
Its always troubled me that we don’t have more Java and C# but I think I understand now. The kind of people who come to ACCU like a certain type of programming challenge, you find this in C++ but not so much in Java or C#, this is partly because Java and C# do there job well and partly because they are, well, shall we say, a little boring. They do what they are supposed to. Because of the way C++ has developed, and the type of applications it is used for includes more of these challenges.
(Having said that, I had a conversation the other day which started: Java is not as interesting as C++, in fact Java is boring, but reflection is interesting. And annotation. And the libraries, and ....)
It seems functional languages too have these challenges. People here are very excited about all things functional. Already it looks like next year will have plenty of Haskell, Erland, Lisp etc.
There are also lots of other interesting sessions - my own sessions on management went well, I’ll post details soon.
Some other high lights:
• Tom Gilb’s sessions on management and EVO have been great
• Gail Ollis and Dirk Haun have done really good sessions and shown themselves to be up and coming C-list presenters
• Sean Parent hide a hard core C++ talk inside an excellent session on the Adobe Source Libraries - libraries which look well worth checking out.
• Roman Pichler ‘Is the project manager an endangered species?’ was more of a ‘Quick introduction to SCRUM’ but still interesting and useful
• Simon Peyton-Jones showed himself to be an entertaining speaker and really excited the audience with his keynotes on parallelism and functional languages
Oddly, for the first time ever I’ve found myself with spare time on my hands at the conference. Not a lot but the odd session were I was not interesting in anything - although there were more sessions were I wanted to be in two places at once. I think this is more a reflection on myself, I’m increasingly post-technical and the technical session here are hard core. There were plenty of management sessions but I didn’t want to go to them all.
Right, to dinner!
Its always troubled me that we don’t have more Java and C# but I think I understand now. The kind of people who come to ACCU like a certain type of programming challenge, you find this in C++ but not so much in Java or C#, this is partly because Java and C# do there job well and partly because they are, well, shall we say, a little boring. They do what they are supposed to. Because of the way C++ has developed, and the type of applications it is used for includes more of these challenges.
(Having said that, I had a conversation the other day which started: Java is not as interesting as C++, in fact Java is boring, but reflection is interesting. And annotation. And the libraries, and ....)
It seems functional languages too have these challenges. People here are very excited about all things functional. Already it looks like next year will have plenty of Haskell, Erland, Lisp etc.
There are also lots of other interesting sessions - my own sessions on management went well, I’ll post details soon.
Some other high lights:
• Tom Gilb’s sessions on management and EVO have been great
• Gail Ollis and Dirk Haun have done really good sessions and shown themselves to be up and coming C-list presenters
• Sean Parent hide a hard core C++ talk inside an excellent session on the Adobe Source Libraries - libraries which look well worth checking out.
• Roman Pichler ‘Is the project manager an endangered species?’ was more of a ‘Quick introduction to SCRUM’ but still interesting and useful
• Simon Peyton-Jones showed himself to be an entertaining speaker and really excited the audience with his keynotes on parallelism and functional languages
Oddly, for the first time ever I’ve found myself with spare time on my hands at the conference. Not a lot but the odd session were I was not interesting in anything - although there were more sessions were I wanted to be in two places at once. I think this is more a reflection on myself, I’m increasingly post-technical and the technical session here are hard core. There were plenty of management sessions but I didn’t want to go to them all.
Right, to dinner!