- Agile Leadership Development
- Product Owner
In many software circles, refactorings are behavior-preserving modifications that target the patterns of the domain. If we write patterns of management or pedagogy, then why not write refactorings that help people prepare their environments for disruptive change? An interesting question comes to mind: what does it mean for a change to a management system to “preserve behavior”? This seems like a very cool avenue for some thought, even if it hits a dead end.
“Preserving behavior” in software seems to come down to keeping the interface the same. Or, to put it another way, keeping the inputs and outputs the same while changing the design of what happens in the middle. In that respect, introducing something like Scrum is a refactoring of the software development process: money goes in and software comes out, but the process in the middle works better. Making small changes that preserve the behavior of some larger part of the system might be a good way to think about introducing that larger change. I need to think more about that…
Martin Fowler writes this morning about a problem he sees with the way continuous integration is practiced today:
Once you are happy with your work you commit it to the repository, and then build it on the build machine (either manually for with a CI server like CruiseControl).The problem lies if your commit is bad, anyone who updates will get failing code until you fix it.
I have two thoughts on this…
(1) While the problem is a real one, it’s not really a problem with continuous integration. On the contrary, continuous integration takes a problem that exists on any software development team that uses source control—bad code at the head—and makes it immediately visible. On teams that don’t use continuous integration, bad commits can be buried.It’s much better to fail fast, stop the line, and keep the source repository clean.
(2) Fortunately, continuous integration can provide the solution to the bad head problem. As Fowler notes, the private branch and promotion solution he likes in the Smalltalk source control system, Envy, is cumbersome in most of today’s source control systems. Subversion is reasonably good at handling branches, but still I don’t think I’d want to manage such a setup. Tags (or labels, depending on the system) are a good alternative. Simply have the continuous integration script tag the head LATEST at the end of a successful build. The head may not always be good, but anyone can grab the LATEST tag to get the last known good source code. When this is combined with a stop the line discipline, the LATEST tag should usually lag behind the head by only a version or two, if at all.
I recently found out that my experience report, “XP and Junior Developers: 7 Mistakes (and how to avoid them),” was accepted for the Agile 2007 Conference. I had a great time presenting at Agile 2006, and I’m looking forward to doing it again.
Thanks to all who attended my presentation tonight to the University of Colorado ACM chapter! As promised, you can download my slides here: CU Presentation.pptx (1.19 MB). If you don’t have PowerPoint 2007, you’ll need the viewer.
I referenced the following websites and books:
Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series) by Kent Beck
Agile Software Development: The Cooperative Game (2nd Edition) (The Agile Software Development Series) by Alastair Cockburn
The Art of Possibility: Transforming Professional and Personal Life by Benjamin Zander and Rosamund Stone Zander
The Manifesto for Agile Software Development
Software Development as a Cooperative Game – article by Alastair Cockburn
I discovered Edsgar Dijkstra’s 1972 gem, “The Humble Programmer,” today. Some of my favorite quotes…
On TDD (before it was called that, of course):
Today a usual technique is to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence. The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness. But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmer’s burden.
On the contrary: the programmer should let correctness proof and program grow hand in hand. Argument three is essentially based on the following observation. If one first asks oneself what the structure of a convincing proof would be and, having found this, then constructs a program satisfying this proof’s requirements, then these correctness concerns turn out to be a very effective heuristic guidance. By definition this approach is only applicable when we restrict ourselves to intellectually manageable programs, but it provides us with effective means for finding a satisfactory one among these.
On the influence of tools on thinking (and, therefore, the need for agile to be more sensitive to tools than the Manifesto would suggest):
I observe a cultural tradition, which in all probability has its roots in the Renaissance, to ignore this influence, to regard the human mind as the supreme and autonomous master of its artefacts. But if I start to analyse the thinking habits of myself and of my fellow human beings, I come, whether I like it or not, to a completely different conclusion, viz. that the tools we are trying to use and the language or notation we are using to express or record our thoughts, are the major factors determining what we can think or express at all! The analysis of the influence that programming languages have on the thinking habits of its users, and the recognition that, by now, brainpower is by far our scarcest resource, they together give us a new collection of yardsticks for comparing the relative merits of various programming languages. The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.
On the challenge of programming and the need for humility (this is why I’m starting to love Ruby):
We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers.
Great stuff. Read the whole thing!
The website for the 2007 Front Range Code Camp launched today. From the website: “Code Camps are grassroots technical conferences run by local developers for local developers. They have been successful all over the country. Last year was Denver and the Front Range’s first code camp and we are excited to announce the second Front Range Code Camp!“
This year’s event will be on Saturday, May 19 at Metro State College in Denver.
Visit the website to find more info or propose a session.
When we pulled into the garage the other day after running some errands, my 6 year old piped up, “Dad, when we get in can I use scissors?”
“To do what?”
“I just want to cut.”
For an adult, scissors are a tool to make something else happen. For a 6 year old, scissors are an end in themselves. Whatever he does with them, it’s enough that he’s using scissors.
I just finished reading Made to Stick: Why Some Ideas Survive and Others Die, which talks about the Curse of Knowledge, the idea that “once we know something, we find it hard to imagine what is was like not to know it.” The Curse of Knowledge means that the way I use certain tools or practices (say, TDD or continuous integration) is now so familiar to me that I can sound like my son when I’m coaching a new team.
I need to remember what it was like to see these things for the first time and what it was that initially won me over because it’s different from what matters to me now.
Last year, I gave a presentation at the Front Range Code Camp titled “Continuous Integration in Under an Hour.” Here’s the abstract:
Automating software builds and tests using continuous integration can improve the quality of a software project, reduce risk, and make it possible to quickly move from development to release. But all the different tools and scripts involved in setting up CI can make the process seem too overwhelming for most projects to try. In this session, Richard Lawrence develops an application and continuous integration scripts from scratch in less than an hour.
With a 2007 Front Range Code Camp in the works, I’m not sure how long the 2006 session materials will stay up at the Code Camp website, so I’m mirroring them here. There are slides, samples, and templates included.