A month has passed since I joined Ad Coelum Technology and it's been great to sit down with law firms and discuss the merits (and challenges) of cloud computing. One thing we have covered at length is the notion of continuous delivery and the opportunity it presents for delivering a significantly better experience to customers.
To help explain why I will be making continuous delivery a key aspect of our cloud-based Matter Management service, but let's quickly change gears and talk about...cars.
The car in front is a Toyota (but why?)
In the 1950's, American quality guru W. Edwards Deming set out to help Japan rebuild its manufacturing industry in the wake of the second world war. His 'Plan-Do-Check-Act' philosophy centered around the notion of continuous iteration and the importance of early feedback in the engineering process. This agility gave Japanese manufacturers such as Toyota a distinct quality edge over the traditional production processes of western counterparts, allowing them to dominate manufacturing through the late 70's and 80's.
This is the single most important lesson we can learn when it comes to quality and engineering.
In 1991 James P. Womack coined a new term for this approach following a $5m study of Toyota. He called it 'Lean'.
The software industry, perhaps distracted by the looming millennium bug, took a further decade to catch on...
'Agile' - easy to say, hard to do
The Agile Manifesto (2001) marked a turning point in software development and a much needed departure away from waterfall as the dominant approach. We have since attempted to apply all the great lessons of Japanese car building to software development. KANBAN, Kaizan, Just-In-Time - you name it, we found a home for it, most recently under the banner of 'Lean Software Development'.
The problem however, is that all too often we still revert to waterfall because it feels easier and safer. It is almost always the path of least resistance - exec sponsors feel safer because they can see a well defined plan and manage through conformance to it. Customers can't object to the requirements or design because they aren't involved, and reputations can't be damaged because no early software is released for feedback.
Fortunately, opportunities to revert to type are being eroded by the nature of cloud-computing.
If we fix a bug, ALL customers benefit from that fix as soon as it is deployed to the cloud. In most cases, a vast percentage of users will not even notice/be impacted by the change.
If we add a new feature ALL customers can make use of it as soon as it is deployed to the cloud. We will also offer customers/users the choice of how they adopt major new features:
I'm not about to commit to any kind of release cadence at this stage, but every 3-4 weeks for new features is where we need to be to ensure our development efforts are fully aligned with the needs of our customers.
Make no mistake - putting continuous delivery at the heart of our philosophy will bring a whole new set of pressures and challenges. It requires a development operations rethink that will push the quality bar to new levels and inject much needed intensity and pressure into the development process.
Paul Payne, CTO.
@paulpayne1
To help explain why I will be making continuous delivery a key aspect of our cloud-based Matter Management service, but let's quickly change gears and talk about...cars.
The car in front is a Toyota (but why?)
In the 1950's, American quality guru W. Edwards Deming set out to help Japan rebuild its manufacturing industry in the wake of the second world war. His 'Plan-Do-Check-Act' philosophy centered around the notion of continuous iteration and the importance of early feedback in the engineering process. This agility gave Japanese manufacturers such as Toyota a distinct quality edge over the traditional production processes of western counterparts, allowing them to dominate manufacturing through the late 70's and 80's.
This is the single most important lesson we can learn when it comes to quality and engineering.
In 1991 James P. Womack coined a new term for this approach following a $5m study of Toyota. He called it 'Lean'.
The software industry, perhaps distracted by the looming millennium bug, took a further decade to catch on...
'Agile' - easy to say, hard to do
The Agile Manifesto (2001) marked a turning point in software development and a much needed departure away from waterfall as the dominant approach. We have since attempted to apply all the great lessons of Japanese car building to software development. KANBAN, Kaizan, Just-In-Time - you name it, we found a home for it, most recently under the banner of 'Lean Software Development'.
The problem however, is that all too often we still revert to waterfall because it feels easier and safer. It is almost always the path of least resistance - exec sponsors feel safer because they can see a well defined plan and manage through conformance to it. Customers can't object to the requirements or design because they aren't involved, and reputations can't be damaged because no early software is released for feedback.
Fortunately, opportunities to revert to type are being eroded by the nature of cloud-computing.
Continuous delivery, enabled by the cloud
At Ad Coelum Technology we have the luxury of no legacy software, no existing processes and no existing culture. This represents the perfect opportunity to adopt continuous delivery from the get go. Building on a cloud PaaS like Windows Azure means that the deployment issues surrounding on-premises deployments are a thing of the past:
At Ad Coelum Technology we have the luxury of no legacy software, no existing processes and no existing culture. This represents the perfect opportunity to adopt continuous delivery from the get go. Building on a cloud PaaS like Windows Azure means that the deployment issues surrounding on-premises deployments are a thing of the past:
If we fix a bug, ALL customers benefit from that fix as soon as it is deployed to the cloud. In most cases, a vast percentage of users will not even notice/be impacted by the change.
If we add a new feature ALL customers can make use of it as soon as it is deployed to the cloud. We will also offer customers/users the choice of how they adopt major new features:
- Early adopter? Great! You can use preview versions of the feature as soon as it is deployed and help us to improve functionality through continuous delivery and feedback.
- More conservative? No problem. You will only receive the feature once it has been fully tried and tested
I'm not about to commit to any kind of release cadence at this stage, but every 3-4 weeks for new features is where we need to be to ensure our development efforts are fully aligned with the needs of our customers.
Make no mistake - putting continuous delivery at the heart of our philosophy will bring a whole new set of pressures and challenges. It requires a development operations rethink that will push the quality bar to new levels and inject much needed intensity and pressure into the development process.
But these are good pressures and exciting challenges. Continuous delivery has started...
Paul Payne, CTO.
@paulpayne1
No comments:
Post a Comment