A busy month, before a busy month
I haven't had the time or presence of mind to post for the past few weeks. Burton Group had its annual North American conference in San Francisco June 12-16, so I was heads-down preparing and presenting. June also saw a trip to Orlando (IBM Rational Developers Conference), which was informative, but not so much fun without the kids (caught in the Disney trap).
I've just come up for air to write a short post before heading off on vacation later this week. It has been a rush to get things done so I can relax for a week. I'll leave the family at the cottage for a few days and fly to Europe to present at a Financial Services conference in the UK. I suspect I'll have several other meetings both in the UK and on the continent...a whirlwind that I enjoy. At a minimum, I'll be meeting with Ivar Jacobson's people in London to talk about the Essential Unified Process.
So, I've been loading up with books on London history, and making travel arrangements. When I travel somewhere, I like to have a deeper perspective on where I am. It helps to shake off the floating feeling you often get when wandering around as a tourist. My kids make fun of me for studying maps, but that's how I create my mental model of a place...takes some of the stress off figuring out where you are and where to go.
In the UK, I'll be presenting on a few topics: 1) a keynote address on Inertia and Innovation in financial services software development (focus on User Experience); 2) platforms (including discussion of mainframe migration strategies) and 3) Thin Clients (emphasis on RIA and Smart Client architecture). The presentations have been fun to put together, and should be informative.
The more time I spend thinking about these issues, the more I am aware that the solutions are to be found in the history of humans and their technology. There is much to be learned by studying how people have solved problems in the past, despite the tool in their hands. In many ways, software engineering is at a transitional stage from artisan to engineer. Best practices are still emerging out of the tacit knowledge of the artisan practitioners. It's just that the pace of change is much faster.
I've just come up for air to write a short post before heading off on vacation later this week. It has been a rush to get things done so I can relax for a week. I'll leave the family at the cottage for a few days and fly to Europe to present at a Financial Services conference in the UK. I suspect I'll have several other meetings both in the UK and on the continent...a whirlwind that I enjoy. At a minimum, I'll be meeting with Ivar Jacobson's people in London to talk about the Essential Unified Process.
So, I've been loading up with books on London history, and making travel arrangements. When I travel somewhere, I like to have a deeper perspective on where I am. It helps to shake off the floating feeling you often get when wandering around as a tourist. My kids make fun of me for studying maps, but that's how I create my mental model of a place...takes some of the stress off figuring out where you are and where to go.
In the UK, I'll be presenting on a few topics: 1) a keynote address on Inertia and Innovation in financial services software development (focus on User Experience); 2) platforms (including discussion of mainframe migration strategies) and 3) Thin Clients (emphasis on RIA and Smart Client architecture). The presentations have been fun to put together, and should be informative.
The more time I spend thinking about these issues, the more I am aware that the solutions are to be found in the history of humans and their technology. There is much to be learned by studying how people have solved problems in the past, despite the tool in their hands. In many ways, software engineering is at a transitional stage from artisan to engineer. Best practices are still emerging out of the tacit knowledge of the artisan practitioners. It's just that the pace of change is much faster.
posted by chris howard at 8:46 PM
1 Comments:
I completely agree with you about solution to most challenges rely outside of the tool used. My favorite analogy for this? If you wrote poorly understood drivel on paper, having Microsoft Word only provided a way to write neater, poorly understood drivel; Email allowed you to distribute the drivel widely to an audience known to you; and a blog allowed you to post it for any stranger to see. To write a cogent, well thought-out piece, you still need basic English skills, rational thinking, and the ability to string thoughts together in a way others will understand. These facilities haven’t changed much since Shakespeare first put pen to paper.
Post a Comment
<< Home