Archive for the ‘Podcasts’ Category
SPaMCAST 112 – Israel Gat, Technical Debt
http://www.flickr.com/photos/pumpkinjuice/229764922/
Click here for my just published interview on Technical Debt. Major themes discussed in the interview are as follows:
- The nature of technical debt
- Tactical and strategic effects of technical debt
- How the technical debt metric enables you to communicate across levels and functions
- What Toxic Code is and how it is related to Net Present Value
- The atrocious nature of code with a high Error Feedback Ratio
- Cyclomatic complexity as a predictor of error-proneness
- Use of heat maps in reducing technical debt
- Use of density of technical debt as a risk indicator
- How and when to use technical debt to ‘stop-the-line’
- Use of technical debt in governing software
To illuminate various subtle aspects of technical debt, I use the following metaphors in the interview:
- The rusty automobiles metaphor
- The universal source of truth metaphor
- The Russian dolls metaphor
- The mine field metaphor
- The weight reduction metaphor
- The teeth flossing metaphor
Between the themes and the metaphors, the interview combines theory with pragmatic advice for both the technical and the non-technical listener.
Making code reviews not suck
Not all Agile teams practice strong code reviews, but one of the original Agile practices (sort of long forgotten, it seems) of paired programming was all about code review. As such, I thought I’d cross-post these two videos going over what one RedMonk client, SmartBear, does to help make code reviews suck less. –Coté
Yesterday SmartBear released version 6.0 of CodeCollaborator, the popular code reviewing tool. They’ve added in numerous features, of course, with highlights like handling asset as an item to review (like a Word doc), enhancements to the Eclipse plugin, and integration with VisualStudio. Check out the 6.0 feature list for more details.
I discussed the new features with them in the below interview and then got a quick demo:
New features interview
You can download the video directly as well.
Also, a full transcript of the video:
Michael Coté: Well, hello everybody! Here we are in lovely Austin, Texas, at what we have dubbed the SmartBear studio. This is Michael Coté, of course, of RedMonk. And today I am joined by a guest to go over a new release that SmartBear has out. You want to introduce yourself?
Gregg Sporar: Thank you, Michael. Yes, my name is Gregg Sporar. I have a face made for radio, but yet we are going to record this on video.
Actually, that was the great thing about doing the podcast, because it’s a podcast and it’s just my voice.
Michael Coté: …[the podcast] on code reviewing.
Gregg Sporar: But then, you took this giant picture of me and put that on the blog, and I am thinking, dude, more of a Gravatar. We don’t need — here, we are. We are talking about Code Collaborator v6.0.
Michael Coté: That’s right. Just to give us like a really quick introduction, like what does CodeCollaborator do for people who don’t know off the top of their head?
Gregg Sporar: CodeCollaborator’s sole goal in life is to automate the grunt work parts of the peer code review process. So the collecting of the files and making them available on a central location. Coordinating the communication between the review participants and tracking what everybody says and where defects are found and that kind of thing, and then reporting the statistics at the end.
Michael Coté: What release number is this one?
Gregg Sporar: We are talking about version 6.0.
Michael Coté: So in 6.0, so tell us what the new features are? What’s going to get people excited about this release?
Gregg Sporar: There are several things. Let’s back up for just a second to version 5.0 last year, when we added support for reviewing materials other than just source files. The reason for that was, because a lot of our customers, you are dealing with a software development team, but there are other people on the periphery as well, that might want to be involved in the review. If you’re building embedded software, it might be that the firmware guys or the hardware design guy, he wants to be involved and he wants to see his schematic in that.
Michael Coté: Right.
Gregg Sporar: Then we also had just regular software development teams coming to us saying, well, this is great, but I would like to add the design document to the review and look at it and reference it from within the same tool.
So last year we added support for PDF files, for example, and for image files, for JPEGs, and PNGs, and GIFs, and that kind of thing.
Michael Coté: And that allows you to add in all the commentary and the usual meta information on a piece of code?
Gregg Sporar: Exactly! So whenever I would show the PDF feature to people, they would say, well, that’s great, but I would really like to do this with a Word document.
Michael Cote:: Sure.
Gregg Sporar: So there is a plug-in that Microsoft makes available to create a PDF off of a Word document, but people don’t want to do that. They just want to take their document and put it in place. So that’s one of the key features in 6.0.
The way we actually implemented that is kind of interesting. We built a Windows printer driver, because, again, at the end of the day, we just need to be able to render something and paginate it and put it into the tool. The best way to do that really in that environment is a printer driver. So it’s not just Word, it’s not just Microsoft Office apps, it’s any Windows app that can render paginated output.
Other major features. A significant enhancement to our Eclipse plug-in, which we have had for a few years now. In the past it was limited to just being able to show you or actually just being able to create a review or add materials to a review, and now we have actually brought the entire review experience directly into the IDE.
Another thing that we have gotten a lot of request for is for Visual Studio. Not everybody uses Eclipse, believe it or not. So what we have done is just sort of an initial entrée into the Visual Studio world, we have essentially got functionality equivalent to what we had in our old Eclipse plug-in.
So again, I don’t have that ability to bring the review experience in, like I have done now and with the guys that built for our Eclipse plug-in, but it’s a start. It gets you partway there.
Again, to let you stay within your working context, to at least be able to create the review or add materials to that.
Then there are what I call Red Meat features. Not RedMonk, Red Meat. This is the real type stuff, because these are features that you don’t have to be an Eclipse user or Visual Studio user, this is something that’s going to affect everybody.
This is, for example, one of the things that a lot of people have asked for, for a long time, the ability to delete a comment after you put it in to the tool. We are not actually going to allow you to delete, we are going to allow you to redact the comment.
Michael Cote:: Right.
Gregg Sporar: I will show that to you during the demo. The reason for that is, we can’t really completely remove it, because it would break the IM type paradigm for our real-time track capability. I mean, think about it, if you were IMing with somebody —
Michael Cote:: And it just disappeared.
Gregg Sporar: And it just disappeared while you were reading it, that would kind of freak you out. That breaks that paradigm.
Michael Cote:: It’s kind of like that email recall feature, which is a little strange in its own right.
Gregg Sporar: Which is a little strange in its own right. Then the other issue of course is, we have a lot of customers who, auditability, traceability, that kind of thing, is really important. Nothing can ever be deleted.
Michael Coté: Sure.
Gregg Sporar: So we are going to allow you to redact a comment. We have changed the way that we display defects within the file comparison window. We have added, again, some of these usability type features that affect everybody.
We have made some enhancements to our ClearCase Integration. We have also put in some pretty important enhancements to our integration at the other end of the spectrum to Git and Mercurial.
Michael Coté: And how many version control systems do you guys work with now?
Gregg Sporar: 16.
Michael Coté: 16? That’s pretty nice.
Gregg Sporar: That’s a rather large number.
Michael Coté: That’s probably more than most people could name off.
Gregg Sporar: So a fun drinking game is to get a couple of beers in me and then try to get me to list the 16 in reverse alphabetical order, because I can do it in alphabetical order, but reverse alphabetical order is a little more difficult.
One last [thing], maybe, to mention really quickly. We did, and this is again something that you can’t appreciate unless you are an existing user of the product, we have significantly enhanced some of our reporting capabilities. That’s kind of that third pillar of what it is we do.
For the customizable reports, where the user can build their own query, we have added some additional fields that they can now filter on and select and that kind of thing.
Then we put a lot of effort into adding what we call user-oriented reports. So we have always had review-oriented reports and defect-oriented reports, that again, primary key is information about the review overall or primary key is, tell me about the defects that were found, but now we have added a third category, which is, tell me what I have been doing.
Michael Coté: I always think of that as self-micromanagement. Sort of optimize your own self.
Gregg Sporar: So one of the features, it is the ability for me to come in after the fact into the tool and find out, well, what reviews did I work on during the last week? I had a guy at a customer site explain to me this feature, because when he is doing his weekly status report, he knows he typically spends about 10-20% of his time during a week doing code review. Well, he wants to know, what reviews he did.
Michael Coté: Yeah.
Gregg Sporar: So again, user-oriented reporting.
Michael Coté: Well, great! Well, let’s check out a demo of those features and see what we get to see.
Demo
You can download the video directly as well.
There’s also a nice wrap-up of posts detailing features on the Smartbear blog.
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.
Putting Agile Infrastructure into Practice – Agile Executive Episode 007
In this episode, we’re joined again by Andrew Shafer to talk about Agile Infrastructure (or “Agile Operations” as some folks call it).
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:
- The in problems in IT that cause us to start wanting Agile Infrastructure. The high-level problem is enabling change (that works) more often: configuration drift, intentional complexity, walls of confusion everywhere, hero-driven incentives. Israel also mentions the theory that you have to change up your incentive structures often so that people don’t get locked into incentive-driven thinking vs. “doing the right thing,” so to speak.
- Leading us into the practices, Israel asks Andrew about including the operations folks in the Agile team, just as you do developers, QA, documentation, and so on. This gets into a discussion on “fractal teams.” We then get into other practices and technologies that help with Agile Infrastructure:
- Version control – getting beyond .bak files. You need some kind of version control system. What do you put in there? All your configuration files, to start with. Perhaps your scripts next. Puppet and other tools can help do more. The tools, really, can be the same as used in development: git, subversion, CVS, and so on. In fact, Andrew says you should really use whatever development is using for consistency.
- Always ship trunk
- “Dark launches” – staging the release of features to test back-end tasks before exposing it to the user, and then finally giving the user access to the new system. This lets you test out the impact of the “background” tasks in the production system of new features without exposing it to users.
- An over-arching theme here is to reduce the fixed cost of deployment, trying to get it to zero as much as possible.
- Some other practices: test-driven infr, deploy early/deploy often, tagging everything with who/what/when, time synchronizing, and a few more.
The Agile Infrastructure cultural change problem – Agile Executive #06
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:
As part two in our (planned to be) three part or so series, Israel Gat, Andrew Shafer, and I get back together to discuss the idea of Agile Infrastructure. See part one for an overview of what “Agile Infrustructure” aims to be in the first place.This time, we talk about the difficulty of cultural change to make a more Agile IT process possible. We spend much time on “motherhood and apple-pie” topics as always happens when it comes to discussions of organizational change management, but drawing on our experiences in both small and very large companies, we start to pull apart the tactics for not only implementing a change to Agile IT, but coping with the friction that occurs during any change, esp. something as dramatic as changing to a more Agile way of delivering software and business services.
Here’s a feel for what’s in the episode:
- I start out by asking how organizations start the process of changing to more Agile IT operations.
- Andrew says that change starting at a grass roots level, bottom-up, and is far from wide-spread.
- Israel speaks to one anecdote with 20% from the top and 80% from the bottom.
- What’s the process for change? What’s the context for trying to get people to change?
- Andrew says that people have to care – they must be interested in doing more than passing the time and getting paid for it, as I put it. Ideally, champions can start to “manage upwards” too, as needed. Also, having an expert on Agile available for internal assistance and answering questions is key.
- Israel adds in his “Agile Executive” view. He speaks to using people’s desire to do better, but figuring out a window (or time and environment) in which it’ll succeed.
- Using small successes to build the room to do large successes.
- This discussion leads Andrew to remember a talk by Lisa Crispin where the testers and others began to understand the “business,” or the larger context they were operating in.
- I ask Andrew and Israel why it’s important for IT employees to rise above being someone who “just works here.”
- We then discuss how changing to the more role-fluid nature of Agile conflicts with the static nature of jobs in organizations, where people are assigned a specific role and aren’t expected to go outside that role.
- When it comes to knowing how well you’re doing, Andrew introduces the Dunning-Kruger effect, wherein people are bad at evaluating themselves, esp. when their context is limited to their own group or organization.
- Reflect and adapt… making sure you do this in Agile. Israel connects this back to building confidence and moral in the organization as a way to enable change and Agile. This relates to one of those group psychology studies that’s always fascinating, namely, people preferring confidence over expertise.
Delivering Valuable Software, guest Jim Highsmith – Agile Executive #5
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:
In this episode, Israel and I talk with Jim Highsmith. We center the discusion around the new edition of Jim’s book, Agile Project Management, but this pulls in all sorts of general discussion about Agile:
- How did Jim get into Agile? Going from traditional software development to Agile.
- How does Rapid Development compare to Agile? Tools in RAD vs. tools in Agile.
- Pivoting on a mention of Jim being in China, I ask him about cultural differences of applying Agile, for instance, based on geo-cultural differences.
- What’s new in the new edition that leads into larger applications of Agile? Release planning, “scaling” self-organizing teams, governance issues, and measuring.
- How does Agile work in a systems, or hardware plus software situation.
- Israel asks Jim for some advice on synching up software developed in an Agile fashion with hardware folks. There’s primarily more coordination and dependency management between teams and features.
- Release planning – most Agile teams focus on iteration planning, without peaking up to concerns at the release level, e.g., budgeting, timing, and marketing concerns.
- How can “the business” get involved with the process to make sure focus is kept on the release?
- What’s this “scaling” business? Scaling a team up in size, or scaling a team out in a distributed process.
- Israel and Jim then dig into distributed scaling, adding in off-premise teams and collaboration.
- Tracking and measuring things from a (business) strategic orientation. This hits on keeping track of value (will this software make us money?), quality and other “metrics” over time. Who is that determines this “value” ongoing? Getting people to figure out “value points.”
- Israel then asks Jim for a retrospective on where we’ve been and are after the Agile Manifesto.
Also, see Jim’s sum-up of the new content in the book.
Between Agile and ITIL
You do not need to be an expert in Value Stream Mapping to appreciate the power of speeding up deployment to match the pace of Agile development. By aligning development with deployment, you streamline “production” with “consumption.” The rationale for so doing is aptly captured in the first bullet of the Declaration of Interdependence:
We increase return on investment by making continuous flow of value our focus.
As pointed out in previous posts in this blog, Flickr and IMVU seem to be doing an exceptionally fine job streamlining the flow of value: every thirty minutes and every nine minutes respectively. A recent presentation in Velocity 2009 by John Allpsaw and John Hammond adds color how development and operations at Flickr cooperate to accomplish “10+ deploys per day.”
What does such fast pace mean to the business? In a nutshell, much of the guess work as to what features are really needed is eliminated when you develop, deploy and collect customer feedback in ultra fast manner. Consequently, the company’s business design is likely to be transformed. Click here, here, and here for more detailed discussions how the business design gets transformed.
Michael Cote, Andrew Shafer and I have been pondering about aligning development and operations for quite sometime. On the one hand, we are painfully aware of the traditional desire to minimize change in IT operations. On the other hand, we are of the opinion Agile principles are quite applicable to operations. We often wonder whether the obstacles between Agile and ITIL are real or imaginary. We actually believe the {development –> operations} theme is an important instantiation of Dean Leffingwell‘s recent thoughts about applying Agile/Lean principles to other knowledge work.
The three of us – Michael, Andrew and I – decided to do a few podcasts to explore what stands between Agile and ITIL. The first of these podcasts will be published this month (July 2009).
Stay tuned…
Agile Roots, Agile Operations, & Agile Clouds, Agile Executive Podcast 003
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:
After having some coffee here in Austin, Israel Gat and I braved the Texas heat a little while longer to record a conversation about the recent Agile Roots conference, how Agile has spread in recent years, and some of the potentials that cloud computing plus Agile might bring.
We go over the Agile Roots conference that Israel was currently at: one of the themes, Israel says, was a sort of retrospective on the Agile Manifesto (put out in 2001). Also, as Israel points out many times, there was a good mix of people that made the “hallwaycon” enjoyable. Part of this, it seems was due to the somewhat unconference-y feel of the event: while it had a formalized agenda, there was room for less structured, unconference-style sessions and discussions.
Based on this, I then ask Israel to summarize what his and other’s people take was on where Agile is today. In my words, it seems like Agile thinking has, largely, gone main-stream. In fact, as I chime in, large corporate development tool vendors like Microsoft with VisualStudio and IBM with the Rational line are bringing in and using significant Agile principals and practices.
Next, we get into the “Agile Operations” conversation folks from Reductive Labs have been having of late. Esp. when cloud computing technologies (like virtualization, automation, and SaaS-think) are brought into the operations side of the house, Agile principals seem especially well positioned to take advantage of cloud technologies. This gets us into a discussion of how cloud delivered software (SaaS, pretty much) might help free up some time and resources in the traditional software delivery process, primarily, by not having to support many different versions, but also (some what paradoxically to that) allowing bette customizations per customer.
From here, I lay out the theory that with cloud computing, there seems to be some efficiency gains that make it possible for smaller teams to develop and sell software instead of having to hook-up with larger software companies to get efficiencies of scale. While this discussion, as Israel gets to, has been happening a lot in the startup world (startups need less capital up-front to buy hardware and such, and thus, need less funding), it hasn’t been reflected on much in the plain old ISV world. Israel lays out an interesting “out source (most) everything” model for software companies.
Dean Leffingwell – Agile Executive Podcast 002
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:
In this Agile Executive podcast, I talk with Dean Leffingwell. We start out going over Dean’s background both in the software and Agile world (check out his bio for more).
Since Dean worked at Rational for some time (after his company was acquired by Rational, Requisite, makers of RequisitePro), I ask Dean the broad question, what was up with RUP? That is, what went wrong there? In retrospect, it seemed like a flexible enough process, but it got applied as One Big Honking Thing, as The Poster, if you will.
Pulling from Dean’s work at, as his book would put it, Scaling Agile, I ask Dean how large companies go about applying Agile to, large, existing code-bases, like version 10 of a product. Put another way, how does Agile apply when you’re dealing with legacy code. His answer is the usual, crisp and pragmatic Agile approach, “let’s worry about the new code” and then move on to the old stuff when we have time. The other side of that comment is interesting as well: the old code “works” already, so try not to mess with it. At the time, I should have asked him how to deal with developers endless desire to refactor the code, which buts up against the “let sleeping dogs lie,” as it were.
Connected to this, I ask Dean to tell us what the “enterprise” in “enterprise Agile” means. We also discuss what Agile implementations seem to fit in enterprise situations. My perpetual questions here is: how do you fit in product management, sales, marketing, training, support and all that? Dean says that the strength of the Project Office (or the “PMO”) is the lynch pin here. We also get into using a sort of Facade approach to reporting and interfacing with the organization in the old ways while changing to Agile in-flight.
Also, touching on my interest in IT Management and Dean’s experience running a SaaS-y company with Agile, I ask Dean what he’s seeing in the way of “Agile Ops.” Dean points out that while “Agile” as developers know it doesn’t have big mind-share in operations, those folks tend to have very similar structure and goals to their process: quickly running, doing small things, and tracking all that.
Finally, we close out with the never-ending question when it comes to Agile Leadership, how do you get the organization to want to do it? As always, the approach is to use small successes to establishing credibly early on and then snow-ball those successes into larger ones.
Clarke Ching – Agile Executive Podcast 001
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:
Kicking off our Agile Executive podcast series, I talk with Clarke Ching. We start out discussing two of Clarke’s books Rocks Into Gold and a longer version he’s working on. We then discuss the relation of Goldratt’s The Goal.
I ask Clarke to talk to his point that breaking things into smaller chunks end ups costing less. He says:
- In bigger projects (vs. smaller ones), we end up building more low-priority things, thus “wasting” time
- With a focus on delivering small chunks that work we get higher quality, rather then wiring up lower quality stuff
After this, I ask Clarke how he’s sorted out the boot-strapping problem of getting Agile started in organizations. He recommends:
- The Weetabix Sell – selling the benefits, not the ingredients or “process”
- Set expectations that it’s going to be hard work
- find quick wins, preferably “without doing anything”
Finally, I ask Clarke to give us a report on the Agile scene across the pond, which he does nicely.
The Agile Executive 