Posts Tagged ‘dev/ops’
The Gat/Highsmith Joint Seminar on Technical Debt and Software Governance
Jim and I have finalized the content and the format for our forthcoming Cutter Summit seminar. The seminar is structured around a case study which includes four exercise. We expect the case study/exercises will take close to two-thirds of the allotted time (the morning of October 27). In the other third we will provide the theory and practices to be used in the seminar exercises and (hopefully) in many future technical debt engagements participants in the workshop will oversee.
The seminar does not require deep technical knowledge. It targets participants who possess conceptual grasp of software development, software governance and IT operations/ITIL. If you feel like reading a little about technical debt prior to the Summit, the various posts on technical debt in this blog will be more than sufficient.
We plan to go with the following agenda (still subject to some minor tweaking):
Agenda for the October 27, 9:30AM to 1:00PM Technical Debt Seminar
- Setting the Stage: Why Technical Debt is a Strategic Issue
- Part I: What is Technical Debt?
- Part II : Case Study – NotMyCompany, Inc.
- Exercise #1 – Modernizing NotMyCompany’s Legacy Code
- Part III: The Nature of Technical Debt
- Part IV: Unified Governance
- Exercise #2 – The acquisition of SocialAreUs by NotMyCompany
- Part V: Process Control Models
- Exercise #3 – How Often Should NotMyCompany Stop the Line?
- (Time Permitting – Part VI: Using Technical Debt in Devops
- Exercise #4 – The Agile Versus ITIL Debate at NotMyCompany)
By the end of the seminar you will know how to effectively apply technical debt techniques as an integral part of software governance that is anchored in business realities and imperatives.
Outline of the Technical Debt Seminar at the Cutter Summit
Pictured above are speakers of the forthcoming Cutter Summit. Between the seventeen of us we will cover a broad spectrum of IT topics such as Agile, Enterprise Architecture, Business Strategy, Cloud Computing, Collaboration, Governance and Security. Inter-disciplinary seminars, panels and case studies will weave all those threads together to give participants a clear view of the unfolding transformation in IT and of the new way(s) companies are starting to utilize IT. Click here for a details.
As Jim Highsmith and I continue to develop our joint seminar on technical debt for the summit, I would like to give readers of this blog a sense of where we are and ask for feedback. Right now we are considering the following building blocks for the seminar:
- The Nature of Technical Debt
- Technical Debt Metrics
- Monetizing Technical Debt
- Constructing Roadmaps for Paying Back Technical Debt
- Risk Assessment and Mitigation
- A Simple Software Governance Framework
- Schedule in the Simple Governance Framework
- Enlightened Governance
- Baking in Quality One Build at a Time
- How Often Should the Project Team Regroup?
- Multi-Level Governance
- Extending Technical Debt Techniques to Devops
- Use of Technical Debt Techniques in Agile Portfolio Management
- The Start Afresh Option
- Technical Debt as an Integral Part of a Value Delivery Culture
In the course of going through a subset of these building blocks, we will cover the latest and greatest from the October issue of the Cutter IT Journal on technical debt, present two case studies, and conduct a few group exercises.
From Vivek Kundra to Devops and Compounding Interest: Cutter’s Forthcoming Special Issue on Technical Debt
Source: http://www.flickr.com/photos/wallyg/152453473/
In a little over a month the Cutter Consortium will publish a special issue of the Cutter IT Journal (CITJ) on Technical Debt. As the guest editor for this issue I had the privilege to set the direction for it and now have early exposure to the latest and greatest in research and field work from the various authors. This short post is intended to share with you some of the more exciting findings you could expect in this issue of the CITJ.
The picture above of the debt clock is a common metaphor that runs through all articles. The various authors are unanimously of the opinion that one must measure his/her technical debt, embed the measurements in the software governance process and relentlessly push hard to reduce technical debt. One can easily extrapolate this common thread to conjecture an initiative by Vivek Kundra to assess technical debt and its ramification at the national level.
Naturally, the specific areas of interest with respect to technical debt vary from one author to another. From the broad spectrum of topics addressed in the journal, I would like to mention two that are quite representative:
- One of the authors focuses on the difference between the manifestation of technical debt in dev versus its manifestation in devops, reaching the conclusion that the change in context (from dev to devops) makes quite a difference. The author actually doubts that the classical differentiation between “building the right system” and “building the system right” holds in devops.
- Another author derives formulas for calculating Recurring Interest and Compounding Interest in technical debt. The author uses these formulas to demonstrate two scenario: Scenario A in which technical debt as % of total product revenue is 12% and Scenario B in which technical debt as % of total product revenue is 280%. The fascinating thing is that this dramatic difference (12% v. 280%) is induced through much smaller variances in the Recurring Interest and the Compounding Interest.
I will blog much more on the subject when the CITJ issue is published in October. In addition, Jim Highsmith and I will discuss the findings of the various authors as part of our joint seminar on the subject in the forthcoming Cutter Summit.
Stay tuned!
Technical Debt Meets Continuous Deployment
As you would expect in a conference entitled velocity, and in a follow-on devops day, speeding up things was an overarching theme. In the context of devops, the theme primarily manifested itself in lively discussions about the number of deploys per day. Comments such as the following reply to my post Ops Driven Dev were typical:
Conceptually, I move the whole business application configuration into the source code…
The theme that was missing for me in many of the presentations and discussions on the subject was the striking of a balance between velocity and quality. The classical trade-off in process control is between production rate and product quality (and safety, but that aspect [safety] is beyond the scope of this post). IMHO this trade-off applies to software just as it applies to mechanical or chemical processes.
The heart of the “deploy early and often” strategy hailed by advocates of continuous deployment is known deployment state to known deployment state. You don’t let the deployment evolve from one state to another before it has stabilized to a robust state. The power of this incremental deployment is in dealing with single-piece (or as small number of pieces as possible) flow rather than dealing with the effects of multiple-piece flow. When the deployment increments are small enough, rollback, root cause analysis and recovery are relatively straightforward if a deployment turns sour. It is a similar concept to Agile development, extending continuous integration to continuous deployment.
While I am wholeheartedly behind this devops strategy, I believe it needs to be reinforced through rigorous quality criteria the code must satisfy prior to deployment. The most straightforward way for so doing is through embedding technical debt criteria in the release/deploy process. For example:
- The code will not be deployed unless the overall technical debt per line of code is lower than $2.
- To qualify for deployment, code duplication levels must be kept under 8%.
- Code whose Cyclomatic complexity per Java class is higher than 15 will not be accepted for deployment.
- 50% unit test coverage is the minimal level required for deployment.
- Many others…
I have no doubt whatsoever that code which does not satisfy these criteria might be successfully deployed in a short-term manner. The problem, however, is the accumulative effect over the long haul of successive deployments of code increments of inadequate quality. As Figure 1 demonstrates, a Java file with Cyclomatic complexity of 38 has a probability of 50% to be error-prone. If you do not stop it prior to deployment through technical debt criteria, it is likely to affect your customers and play havoc with your deployment quite a few times in the future. The fact that it did not do so during the first hour of deployment does not guarantee that such a file will be “well-behaved” in the future.
Figure 1: Error-proneness as a Function of Cyclomatic Complexity (Source: http://www.enerjy.com/blog/?p=198)
To attain satisfactory long-term quality and stability, you need both the right process and the right code. Continuous deployment is the “right process” if you have developed the deployment infrastructure to support it. The “right code” in this context is code whose technical debt levels are quantified and governed prior to deployment.
Devops: It is Not About ITIL, It is About Proficiency
As you would expect, the Information Technology Infrastructure Library (ITIL) topic was brought up in the devops day held last Friday in a LinkedIn facility in Mountain View, CA. We, of course, had the expected spectrum of opinions about ITIL in the context of devops – from “ITIL will never work for a true continuous development shop” to “well, you can make ITIL work under such circumstances.” Needless to say, a noticeable level of passion accompanied these two statements…
IMHO the heart of the issue is not ITIL per se but system management proficiency. If your system management proficiency is high, you are likely to be able to effectively respond to 10, 20 or 50 deploys per day. Conversely, if your system management proficiency is low, ops is not likely to be able to cope with high velocity in dev. The critical piece is alignment of velocities between dev and ops, not the method used to manage IT systems and services. Whether you use ITIL, COBIT or your own home-grown set of best practices is irrelevant. Achieving alignment of velocities between dev and ops is a matter of proficiency in system management.
Technical Debt at Cutter
No, this post is not about technical debt we identified in the software systems used by the Cutter Consortium to drive numerous publications, events and engagements. Rather, it is about various activities carried out at Cutter to enhance the state of the art and make the know-how available to a broad spectrum of IT professionals who can use technical debt engagements to pursue technical and business opportunities.
The recently announced Cutter Technical Debt Assessment and Valuation service is quite unique IMHO:
- It is rooted in Agile principles and theory but applicable to any software method.
- It combines the passion, empowerment and collaboration of Agile with the rigor of quantified performance measures, process control techniques and strategic portfolio management.
- It is focused on enlightened governance through three simple metrics: net present value, cost and technical debt.
Here are some details on our current technical debt activities:
- John Heintz joined the Cutter Consortium and will be devoting a significant part of his time to technical debt work. I was privileged and honored to collaborate with colleagues Ken Collier, Jonathon Golden and Chris Sterling in various technical debt engagements. I can’t wait to work with them, John and other Cutter consultants on forthcoming engagements.
- John and I will be jointly presenting on the subject Toxic Code in the Agile Roots conference next week. In this presentation we will demonstrate how the hard lesson learned during the sub-prime loans crisis apply to software development. For example, we will be discussing development on margin…
- My Executive Report entitled Revolution in Software: Using Technical Debt Techniques to Govern the Software Development Process will be sent to Cutter clients in the late June/early July time-frame. I don’t think I had ever worked so hard on a paper. The best part is it was labor of love….
- The main exercise in my Agile 2010 workshop How We Do Things Around Here in Order to Succeed is about applying Agile governance through technical debt techniques across organizations and cultures. Expect a lot of fun in this exercise no matter what your corporate culture might be – Control, Competence, Cultivation or Collaboration.
- John and I will be doing a Cutter webinar on Reining in Technical Debt on Thursday, August 19 at 12 noon EDT. Click here for details.
- A Cutter IT Journal (CITJ) on the subject of technical debt will be published in the September-October time-frame. I am the guest editor for this issue of the CITJ. We have nine great contributors who will examine technical debt from just about every possible perspective. I doubt that we have the ‘real estate’ for additional contributions, but do drop me a note if you have intriguing ideas about technical debt. I will do my best to incorporate your thoughts with proper attribution in my editorial preamble for this issue of the CITJ.
- Jim Highsmith and I will jointly deliver a seminar entitled Technical Debt Assessment: The Science of Software Development Governance in the forthcoming Cutter Summit. This is really a wonderful ‘closing of the loop’ for me: my interest in technical debt was triggered by Jim’s presentation How to Be an Agile Leader in the Agile 2006 conference.
Standing back to reflect on where we are with respect to technical debt at Cutter, I see a lot of things coming nicely together: Agile, technical debt, governance, risk management, devops, etc. I am not certain where the confluence of all these threads, and possibly others, might lead us. However, I already enjoy the adrenaline rush this confluence evokes in me…
It starts with Agile – The Pragmatic Cloud
In the podcasts around here and Israel’s posts we often talk about using cloud computing as a tool to deliver better software – indeed, to better the software delivery process. Those two angle on cloud computing are what I tackled in a recent presentation (given as a keynote at the Philly Emerging Technologies for the Enterprise conference last week). As I said in the talk Agile development thinking is a great start for figuring out how to take advantage of cloud computing.
You can see a rehearsal recording of the talk over at my blog (or click play on the above) or hear an audio-only recording of the actual talk over at the Chariot TechNetCast, here’s the slides.
How to Initiate a DevOps Project
Source: 17th/21st Lancers c. 1922-1929 “THE FIGHTING SPIRIT!”
Agile consultants on a development project often start by helping the team construct a backlog. The task is sufficiently concrete to get all stakeholders (product management, project management, development, test, any others) on a collaborative track through the creation of a key artifact. The backlog establishes a base line for the tasks to be carried out in the project.
For a DevOps project, start by establishing the technical debt of the software to be released to operations. By so doing you build the foundations for collaboration between development and operations through shared data. In the DevOps context, the technical debt data form the basis for the creation and grooming of a unified backlog which includes various user stories from operations.
Apply the same approach when you are fortunate to be able to include folks from operations in the Agile team from the very beginning. You start with zero technical debt, but you track it on an ongoing basis and include the corresponding “fix-it” stories in the backlog as you accrue the debt. Running technical debt analytics on the source code every two weeks is a good practice to follow.
As the head of development, you might not be comfortable sharing technical debt data. This being the case, you are not ready for DevOps.
dev/ops with John Allspaw – The Agile Executive #08
Guest co-host Andrew Shafer and Coté talk with John Allspaw (now at etsy) about the dev/ops idea and, more interestingly, cultural and process needs and changes.
To listen to this podcast, download the podcast directly, subscribe to the blog/podcast feed in iTunes (or whatever), or click play below to hear it:
Show Notes
- Check out the video of the Velocity talk we reference frequently. It has some actual meat when it comes to biting off a dev/ops culture, practices, and process.
- John opens up by speaking to tools vs/& culture
- I ask John how his org got over the hump of “we’re a special snow-flake” – resistance to change .
- Effecting cultural change by speaking to problems solved and benefits of the new culture.
- What are some major changes in ops and dev process/culture? Continuous deployment (pushing small changes, often).
- Getting beyond the culture of no – change management tends to be really “no management.”
- You have to have a good track record to do this (MTTR, MTTD) – don’t crash the car. What’s deployment to incident ratio?
- The role of metrics (monitoring) becomes important.
- Physical vs. virtual stuff in operations, EC2 use, etc. People use public cloud stuff for best-of-breed solutions, like SmugMug usage.
- Taking flickr from 25th most popular web property to the 5th.
- Coté is glad John’s at Etsy, cause it fuels the best blog du jour, regretsy.
The Agile Executive 