Apple's man page for curl can be found here if you want to see what options are available.
Thursday, August 29, 2013
Use curl as an alternative to wget on Mac OS X
Mac OS X does not come with the wget command so I needed to find an alternative. It's pretty simple really. Basically, you use curl instead. Darian Brown has a nice writeup on how to do this.
Monday, August 26, 2013
Not All Debts Are Equal (Part 1)
This is the first of a series of posts that I will be making in preparation for a panel discussion on Technical Debt at SPLASH 2013 which will held in Indianapolis, Indiana from October 26-31, 2013.
Does having different interpretations of the Technical Debt metaphor mean that it suffers from semantic diffusion or does it simply provide evidence of its linguistic evolution and not necessarily its diminished usefulness? In this series of posts, I will explore the different things that Technical Debt has come to mean throughout the industry and whether these different meanings make the metaphor more or less useful.
+Martin Fowler coined the phrase "Semantic Diffusion" to describe how the meaning of a word or phrase can weaken as its use spreads through the wider community. For example, the terms "agile" and "refactoring" have arguably suffered from semantic diffusion over the years as people use them in different contexts and apply them to things for which they were perhaps not meant to apply.
Fowler posits that semantic diffusion is more likely to occur with things that are broad concepts rather than hard technologies. Technical Debt seems to be one such broad concept whose meaning has been morphed and applied to a wider range of circumstances than was originally intended.
I have to admit that prior to this writing, I had an entirely different idea of what constituted technical debt. I thought that technical debt was anything that slowed you down: messy code, poor designs, misunderstood or missing requirements, lack of security, poor performance, and pretty much any other technical issue.
I'm not really sure how or why I had settled on this divergent and arguably incorrect definition of technical debt. I can only speculate that it stemmed partly from my lack of insight into the original meaning--Ok, I admit I was too lazy to look into it in depth--but more likely from a healthy dose of "assume" (we know what happens when you do that) and a generous coating of personal bias from past experiences of being hampered by technical issues.
I do know for sure that I'm not the only one who had this view of technical debt. Note that I wrote "had this view." I'll explain more about that later.
First, let's establish a baseline understanding of the term as originally proposed by +Ward Cunningham. It's important to understand the original meaning so we have a basis for comparing other, perhaps divergent, meanings.
Ward mentioned the debt metaphor in a 1992 OOPSLA experience report. He also explains the debt metaphor in a YouTube video and a transcription of it can be found on Ward's wiki. He relates how he coined the term as a way to explain the refactoring being done on the WyCash financial product he was working on at the time. It stands to reason that he would choose a financial concept to explain the technical choices they made while developing a financial product. Had the product been of a different nature, we might have ended up with a different metaphor altogether but as chance would have it, Ward chose debt. The rest, as they say, is history.
Let's take a closer look at what Ward says in the video and try to identify different analogies that we can derive from the debt metaphor.
Ward says, "With borrowed money, you could do something sooner than you might otherwise."
Let me add a little bit of nuance to that. Borrowing money allows you to benefit much sooner than it would be possible without money. With borrowed money, you can buy a car or a house, go on vacation, or start a business. Likewise, charging purchases to a credit card allows you to avail of goods and services well in advance of actually paying money for them. Presumably, having or doing these things is beneficial to you. Therefore, borrowing is a way for you to reap a benefit sooner rather than later.
Ward compares borrowing money to rushing software out the door before it reflects a full understanding of the system. Doing this allows you to get some experience with the program and learn more about it sooner. It's interesting to note that it really doesn't matter that the software is still conceptually incomplete or that the problem is not completely understood. You're not really concerned with that at this point. You're only interested in the opportunity to use what you currently have to explore and learn more about what should be the correct and complete solution. When this is the case, you benefit by going into technical debt as a way to gain experience and understanding sooner.
When you borrow money, you assume the obligation and responsibility to pay someone back. When you take out a loan, you have to pay the lender back. When you charge purchases to a credit card, you're obligated to pay the credit card company.
But what is the currency of technical debt and what obligation and responsibility comes with borrowing it?
Of paying back borrowed time, Ward says "you would repay that loan by refactoring the program to reflect your experience as you acquired it." That is, you fulfill your obligation to pay back borrowed time by spending time to refactor and update the program so that it reflects a clearer and more complete understanding of how it should behave.
When you assume the obligation to pay back borrowed money, you also assume an obligation to pay back slightly more than the amount that you borrowed. This, of course, is the interest that you pay on the loan and it represents a cost to you, the borrower.
Problems with debt arise when borrowers start defaulting on their loans. When you don't make regular payments on a loan, you can get socked with fees and increased interest rates. The longer you default on your loan, the more trouble you get into. If you stay in default long enough, you'll eventually find yourself in an untenable position where any amount you pay will only be enough to pay down the interest and fees and none of the original amount you borrowed. So instead of owing less, you end up owing more and more over time.
Ward explains the parallels with technical debt this way:
After carefully studying Ward's explanation of the metaphor and reading between the lines a bit, I have changed my opinion of what Technical Debt means. If I understand Ward's original intent, it all boils down to "a lack of understanding of the software."
As a metaphor, I think that it's really more important to view technical debt as something you choose to do rather than as something that you have. That is, thinking in terms of "going into debt" rather than in terms of "having debt" is more useful and I think Ward may have even alluded to this somewhat in his video.
Going into technical debt is not so much a problem as it is a conscious choice and commitment. At least that's the way it should be. Just as borrowing money so you can benefit sooner is a good thing, taking on technical debt so you can benefit from using the software sooner is also a good thing. You just have to be responsible and remember to pay back your debt by refactoring the program to reflect any learning you acquired from using the software sooner. Diligently paying back your debt helps you stay out of trouble and allows you to make the debt metaphor work to your advantage.
In this post, I went over the debt metaphor as originally proposed by +Ward Cunningham. I identified several analogies that can be derived from the metaphor. I proposed that going into technical debt is really not so much a problem as it is a choice and commitment that you make so you can benefit from using working software to gain more understanding about a problem and the software itself. It is also important to remember that you have an obligation and responsibility to repay your debt by reflecting any learning you acquire back into the program.
Does having different interpretations of the Technical Debt metaphor mean that it suffers from semantic diffusion or does it simply provide evidence of its linguistic evolution and not necessarily its diminished usefulness? In this series of posts, I will explore the different things that Technical Debt has come to mean throughout the industry and whether these different meanings make the metaphor more or less useful.
"You keep using that word. I don't think it means what you think it means." -- Inigo Montoya, The Princess Bride
+Martin Fowler coined the phrase "Semantic Diffusion" to describe how the meaning of a word or phrase can weaken as its use spreads through the wider community. For example, the terms "agile" and "refactoring" have arguably suffered from semantic diffusion over the years as people use them in different contexts and apply them to things for which they were perhaps not meant to apply.
Fowler posits that semantic diffusion is more likely to occur with things that are broad concepts rather than hard technologies. Technical Debt seems to be one such broad concept whose meaning has been morphed and applied to a wider range of circumstances than was originally intended.
A Quick Confession
I have to admit that prior to this writing, I had an entirely different idea of what constituted technical debt. I thought that technical debt was anything that slowed you down: messy code, poor designs, misunderstood or missing requirements, lack of security, poor performance, and pretty much any other technical issue.
I'm not really sure how or why I had settled on this divergent and arguably incorrect definition of technical debt. I can only speculate that it stemmed partly from my lack of insight into the original meaning--Ok, I admit I was too lazy to look into it in depth--but more likely from a healthy dose of "assume" (we know what happens when you do that) and a generous coating of personal bias from past experiences of being hampered by technical issues.
I do know for sure that I'm not the only one who had this view of technical debt. Note that I wrote "had this view." I'll explain more about that later.
First, let's establish a baseline understanding of the term as originally proposed by +Ward Cunningham. It's important to understand the original meaning so we have a basis for comparing other, perhaps divergent, meanings.
Ward Cunningham's Debt Metaphor
Ward mentioned the debt metaphor in a 1992 OOPSLA experience report. He also explains the debt metaphor in a YouTube video and a transcription of it can be found on Ward's wiki. He relates how he coined the term as a way to explain the refactoring being done on the WyCash financial product he was working on at the time. It stands to reason that he would choose a financial concept to explain the technical choices they made while developing a financial product. Had the product been of a different nature, we might have ended up with a different metaphor altogether but as chance would have it, Ward chose debt. The rest, as they say, is history.
Let's take a closer look at what Ward says in the video and try to identify different analogies that we can derive from the debt metaphor.
Analogy #1: Reaping a benefit sooner
Ward says, "With borrowed money, you could do something sooner than you might otherwise."
Let me add a little bit of nuance to that. Borrowing money allows you to benefit much sooner than it would be possible without money. With borrowed money, you can buy a car or a house, go on vacation, or start a business. Likewise, charging purchases to a credit card allows you to avail of goods and services well in advance of actually paying money for them. Presumably, having or doing these things is beneficial to you. Therefore, borrowing is a way for you to reap a benefit sooner rather than later.
Ward compares borrowing money to rushing software out the door before it reflects a full understanding of the system. Doing this allows you to get some experience with the program and learn more about it sooner. It's interesting to note that it really doesn't matter that the software is still conceptually incomplete or that the problem is not completely understood. You're not really concerned with that at this point. You're only interested in the opportunity to use what you currently have to explore and learn more about what should be the correct and complete solution. When this is the case, you benefit by going into technical debt as a way to gain experience and understanding sooner.
This leads to the first analogy of the debt metaphor:
This kind of reminds me of a quine, a program with no input but whose output is the source code of the program itself. There's a hint of this recursive nature when you use a program to help you make improvements to the program itself. It's also reminiscent of the saying "You need money to make money" but in this case it becomes "You need working software to make working software."Getting working software out the door so you can get some experience with it sooner is like borrowing money so you can reap some benefit sooner.
Analogy #2: Assuming an obligation to pay
When you borrow money, you assume the obligation and responsibility to pay someone back. When you take out a loan, you have to pay the lender back. When you charge purchases to a credit card, you're obligated to pay the credit card company.
But what is the currency of technical debt and what obligation and responsibility comes with borrowing it?
Time is the currency of technical debt. Specifically, you are borrowing time with which to use working software so that, as already noted, you can learn and understand more about the problem and the solution. The obligation that comes with borrowing time is the same that comes with borrowing money: you must pay it back.
Of paying back borrowed time, Ward says "you would repay that loan by refactoring the program to reflect your experience as you acquired it." That is, you fulfill your obligation to pay back borrowed time by spending time to refactor and update the program so that it reflects a clearer and more complete understanding of how it should behave.
This is the second analogy of the debt metaphor:
The obligation to make the program reflect what you learned on borrowed time is like the obligation you have to pay back borrowed money.
Analogy #3: Interest Payments
When you assume the obligation to pay back borrowed money, you also assume an obligation to pay back slightly more than the amount that you borrowed. This, of course, is the interest that you pay on the loan and it represents a cost to you, the borrower.
Ward notes that borrowing money so you can do something sooner is a good idea but "until you pay back that money, you'll be paying interest."
Thus, Ward reasoned that if they "failed to make the program align with what was then understood to be the proper way to think about financial objects," then they would "continually stumble over that disagreement" and this would slow them down.
This again indicates that time is the currency of technical debt. Getting slowed down is a cost that is measured in terms of the time it takes to get things done. The longer it takes to pay a lender back in full, the more interest you will have pay over time. Likewise, the longer it takes for you to reflect new learnings into the software, the longer it will take for you to get things done.
This leads us to the third analogy of the original debt metaphor:
This again indicates that time is the currency of technical debt. Getting slowed down is a cost that is measured in terms of the time it takes to get things done. The longer it takes to pay a lender back in full, the more interest you will have pay over time. Likewise, the longer it takes for you to reflect new learnings into the software, the longer it will take for you to get things done.
This leads us to the third analogy of the original debt metaphor:
Making slower progress because you didn't reflect learnings back into the software is like paying more interest on an outstanding debt.
Analogy #4: Defaulting on a loan
Problems with debt arise when borrowers start defaulting on their loans. When you don't make regular payments on a loan, you can get socked with fees and increased interest rates. The longer you default on your loan, the more trouble you get into. If you stay in default long enough, you'll eventually find yourself in an untenable position where any amount you pay will only be enough to pay down the interest and fees and none of the original amount you borrowed. So instead of owing less, you end up owing more and more over time.
Ward explains the parallels with technical debt this way:
"People rush software out the door but never put learning back into the program. This is like borrowing money thinking that you'd never have to pay it back. If you do that eventually all your income goes to interest and your purchasing power goes to zero. If you develop a program ... and never reorganize it to reflect your understanding... eventually the program does not contain any understanding and all efforts to work on it take longer and longer. In other words, the interest is total and you'll make zero progress."
In short, the fourth analogy of the debt metaphor is:
Not putting learning back into the program is like defaulting on a loan.
A related analogy is this:
A program that does not contain any understanding is like a loan for which you can only afford to pay the interest.
So, what exactly is "Technical Debt" then?
After carefully studying Ward's explanation of the metaphor and reading between the lines a bit, I have changed my opinion of what Technical Debt means. If I understand Ward's original intent, it all boils down to "a lack of understanding of the software."
As a metaphor, I think that it's really more important to view technical debt as something you choose to do rather than as something that you have. That is, thinking in terms of "going into debt" rather than in terms of "having debt" is more useful and I think Ward may have even alluded to this somewhat in his video.
Going into technical debt is not so much a problem as it is a conscious choice and commitment. At least that's the way it should be. Just as borrowing money so you can benefit sooner is a good thing, taking on technical debt so you can benefit from using the software sooner is also a good thing. You just have to be responsible and remember to pay back your debt by refactoring the program to reflect any learning you acquired from using the software sooner. Diligently paying back your debt helps you stay out of trouble and allows you to make the debt metaphor work to your advantage.
Summary
In this post, I went over the debt metaphor as originally proposed by +Ward Cunningham. I identified several analogies that can be derived from the metaphor. I proposed that going into technical debt is really not so much a problem as it is a choice and commitment that you make so you can benefit from using working software to gain more understanding about a problem and the software itself. It is also important to remember that you have an obligation and responsibility to repay your debt by reflecting any learning you acquire back into the program.
Next
In upcoming posts, I'll continue to explore more nuances of the original debt metaphor and other aspects of the analogies that can be derived from it. I'll explore the meaning of the phrase "software that does not contain understanding" and point out gaps in the metaphor that can lead to misunderstanding and weakening from semantic diffusion.
Friday, August 23, 2013
ACM SPLASH 2013: Technical Debt Panel Discussion
SPLASH 2013 (formerly OOPSLA) will be held in Indianapolis IN from October 26 - 31 and out of pure (dumb) luck of being in the right place at the right time, I find myself recruited to be a panelist at the conference for a second time in as many years. Lightning does strike more than once after all. Well, I guess it also helps to work for the same company as the panel organizer and for our company to be one of the conference's major corporate sponsors. I still can't help but wonder why I'm getting invited to do this though.
Last year, I was asked to fill in for a colleague who was unable to make it to Tucson, AZ to be on the Software Tools Research Panel at SPLASH 2012. That was actually kind of fun and I thought I was able to hold my own during the panel discussion. As an added bonus, I got to meet some well-known and respected people in our industry like Jim Coplien and Tryvge Reenskaug, Rebecca Wirfs-Brock, and William Opdyke, among others. There's never a dull moment when Cope is in on a discussion.
This year, I've been asked to participate in the "Technical Debt Panel Discussion," sitting on the podium with Bill Opdyke and others. It's kind of strange to think about sitting up there, a virtual unknown whose bio seems disproportionately thin in substance when compared to those of the other panelists. My only real claim to any kind of celebrity is a "bartender" designation in a volunteer-basis moderator role in an online community for Java developers but I wasn't about to include that in my bio. Don't get me wrong, I'm proud to be a part of a great community and I have a great time volunteering on it but it just doesn't seem to measure up to the kind of credentials the other folks have.
Anyway, my relative anonymity may work to my advantage. I guess I can go there and present myself as the unofficial, self-appointed representative of the average developer who is at that very moment actually fighting his or her way through nasty, debt-ridden code.
If you have some opinions about Technical Debt, it's past, present, and future, please leave a comment or two and let me know what you think the panel should discuss.
I will be posting more thoughts about Technical Debt in the next few weeks leading up to conference and hopefully, with some help from folks who might stumble upon this blog, I will be able to contribute some things of substance to the panel discussion in October.
Thursday, August 22, 2013
How to change the default login shell
The chsh command allows you to change your default login shell.
My default login shell on one server that I used frequently was ksh and having to manually switch to bash got old after a few times. Here's how to make bash the default login shell:
1. Make sure that bash is listed in /etc/shells.
2. Run the chsh command
That's it. The next time you log in, you'll be in the bash shell.
BTW, to see what the current shell is, run this command:
$ cat /etc/shells
/bin/sh
/bin/bash
/sbin/nologin
/bin/ksh
/bin/tcsh
/bin/csh
...
2. Run the chsh command
$ chsh -s /bin/bash
That's it. The next time you log in, you'll be in the bash shell.
BTW, to see what the current shell is, run this command:
$ echo $SHELL
Sunday, October 18, 2009
Agile Adoption: Coping with the Speed of the Game
It's week seven of the college football season, the Buckeyes are on the road and so am I. Although I missed yet another Saturday class of Aikido, I'm not too bummed about it. I met my newly-born nephew yesterday, my sister's and her husband's first child. It's been a while since I've held a baby in my arms and holding Mateo Natan, all six pounds and two ounces of him, felt really good.
After spending the morning at the hospital, we headed out to my sister's apartment to help get things ready for their coming home. Ben and Marvi just moved from uptown Manhattan into a much bigger place in Brooklyn. They got a really sweet deal on an apartment with three bedrooms and a huge living/dining area. They have the baby's room all ready, complete with day bed and a mobile, bassinet, diaper disposal system, baby books, stuffed toys, a dresser full of baby clothes, pictures, posters, alphabet stickers on the wall, a baby floor mat, ...you name it, it's ready. Everything looks good to go.
Just One Thing to Screw It All Up
Of course, anyone who has had a baby will tell you that no matter how ready you think you are, one thing can mess it all up: the baby.
Marvi and Ben, you guys are in for the ride of your lives and it ain't all going to be smooth sailing, no matter how much you try to prepare. Don't get me wrong, there's absolutely nothing wrong with a little preparation. But there comes a point when you just have to go and do it. For Ben and Marvi, that point in time was when Marvi's water broke in the middle of a routine checkup with her Ob/Gyn.
This, of course, got me thinking about Agile, Aikido, and football again.
Just as the baby's arrival does with parenthood, in football, one thing can really screw up all your careful planning and preparation: the game. And what, you might ask, is it that screws up our carefully-laid plans in software development, including Agile? Why, it's the problem you're trying to solve, of course. No matter how well you try to prepare and lay out plans for creating a solution to the problem at hand, the certainty of those plans never really extends far beyond the first line of code written to solve it. From the moment you start actually tackling the problem and trying to create a solution, your plans become subject to change for a myriad of different reasons.
So Much To Do, So Little Time...
You've probably heard football players talk about the "speed" of the game when they go to the next level of play. Whether it's from high school to college or college to pro, players often talk about how much faster the next level is from the last. It's as though they felt like Lucille Ball in the classic assembly line bit: overwhelmed, helpless, and hopeless.
I'm sure many people trying to go Agile feel much the same way. Because just when you think you've got Agile-Scrum down, you realize there's a bunch of engineering practices from Agile-XP (Extreme Programming) that complement it. And then you hear that there's a bunch of things from Agile-Lean that you can do to scale Agile to the enterprise level. And so on. Have you ever seen that poster of a gorilla sitting down, looking really tired and dejected? The caption says "Just when I thought I knew all the answers, they go and change all the questions." Yeah, like that.
So what do you do when, just as you thought you had all your ducks in a row and were ready to take your organization to the promised land of Agile, a bunch of people start asking a hundred different things about what exactly is in store for them in the land of flow and quality and how are you all going to get there? What do you do when, as my colleague Michael so succinctly put it, "The horse is already out of the barn," and you realize that there are still a million different things to do that you didn't put down in your plan?
Too Much On Your Mind
When I started learning Aikido, my partners would often tell me that I was too tense. They could feel me tense up my arms and body whenever they grabbed me or attacked me or whenever they tried to perform a technique on me. In Aikido, tension keeps you from executing techniques properly and it changes the way your partner applies a technique on you. It also makes for a less than enjoyable learning experience for both you and your partner.
What makes you tense up? In Aikido, you tend to tense up when you think too much about what you need to do. When you first learn a technique, you naturally want to do it exactly right. You tend to break it down into all the little things you have to do: watch your footwork, your body position, how you break balance, how you control your partner, etc. Then there's the technique itself.
In football, the players have to deal with lots of things all at once too: the game clock, the play clock, where the line of scrimmage is, where the first down marker is, where the sideline is, where the goal line is, the count, how the other team is lining up, how your team is lining up, etc. And then there's the play itself.
In Agile, well, you already know how much there is to think about in Agile. How can you not tense up with all these things to watch for? What can you do to keep from freezing in your tracks like a deer in headlights in the face of the barrage of concerns people bring up when you tell them you're going to go Agile with them?
First of all, relax. Empty your mind.
My Aikido partners would always tell me one thing whenever they felt me start to tense up in practice: "Relax. I won't hurt you." After a while, I learned to trust my partner and myself. I learned that relaxing made it easier for me to receive the technique when it was performed on me. Relaxing also made it much easier for me to perform the technique. I found that when I didn't think too much about every single thing I needed to do, I could actually do everything better. In Aikido and many other martial arts, it's called "the empty mind." In football, it's that seemingly magical transformation in players that happens when they "settle in" and learn to "slow down" the speed of the game.
In Agile, it seems it's not that simple to just relax. Or is it? Let's see, we have the prioritized backlog. We have the timeboxed iterations. We have the principles of "Doing The Simplest Thing That Could Possibly Work" and "You Ain't Gonna Need It." We have the feedback loop from retrospectives, and sustained incremental delivery of working software, and frequent customer demos of working software. We have the daily standup meeting. We have "Eliminate Waste" and "The Last Responsible Moment." We have the "40-hour work week," and so on.
If we just pause long enough to catch our breath and look hard and understand the intent of the Agile techniques and practices, you'll see that they all add up to humbly accepting one simple truth: "You ain't always gonna get it right the very first time."
Second of all, don't stop.
The other thing I heard a lot during Aikido practice is "Don't stop. Keep going." When you're learning a technique, there's a natural tendency to stop and start over when you realize you did something wrong like turning the wrong way, pointing your foot in the wrong direction, or not breaking your partner's balance correctly. After a while, you realize that making mistakes is a big part of the learning process. That's why you just have to keep going and finish the technique.
Sometimes, it's not what you do that changes the dynamics of execution. In Aikido, we practice with different partners of different ranks. Each one receives the technique differently. What may work for one does not necessarily work for another. But still, you keep going and finish the technique so you can learn to feel the difference.
In football, this is the same as getting YACs, yards after contact. If you're not dragged to the turf on first contact, you keep moving, keep your legs pumping, keep the pile moving, try to break tackles, and fight for every extra yard you can get.
Software development and Agile are no different. No two projects are the same. Why do you think there are so many different accounting systems out there? And the business problem is always changing under you. There's always something that puts us back on our heels, tips us off balance, making us adjust to the new state of things.
The opponent doesn't stop the attack when you mess up a technique. The play doesn't end when that first tackle is made. The game doesn't stop when you turn the ball over. The need for a solution doesn't go away even when your understanding of the problem changes. The business doesn't cease operations just because you're not doing "pure Agile."
If, as apparently the Buckeyes did at Purdue today, you lose a game, you shake off your disappointment, go over the film and learn from your mistakes, and get ready for the next game. If the software isn't doing quite what it's supposed to yet, you write another test, write more code, refactor, and schedule another demo. If your development process isn't delivering all that Agile promises, you have a retrospective, put a process improvement story in your backlog, and get it done in another iteration.
It's all about improvement
There are no promises of a black belt, no promises of a championship title, no promises of development bliss and total customer satisfaction. If, in the end, you do get all that, then that's just a lot of icing on the cake. The whole point really is just doing something and trying to get better at doing it. That's all we can really shoot for, right?
As for Ben and Marvi, well, only time and Mateo Natan will tell you what you guys need to do next. Good luck and remember: relax and just keep doing what you gotta do. You'll be fine. Mazel Tov!
After spending the morning at the hospital, we headed out to my sister's apartment to help get things ready for their coming home. Ben and Marvi just moved from uptown Manhattan into a much bigger place in Brooklyn. They got a really sweet deal on an apartment with three bedrooms and a huge living/dining area. They have the baby's room all ready, complete with day bed and a mobile, bassinet, diaper disposal system, baby books, stuffed toys, a dresser full of baby clothes, pictures, posters, alphabet stickers on the wall, a baby floor mat, ...you name it, it's ready. Everything looks good to go.
Just One Thing to Screw It All Up
Of course, anyone who has had a baby will tell you that no matter how ready you think you are, one thing can mess it all up: the baby.
Marvi and Ben, you guys are in for the ride of your lives and it ain't all going to be smooth sailing, no matter how much you try to prepare. Don't get me wrong, there's absolutely nothing wrong with a little preparation. But there comes a point when you just have to go and do it. For Ben and Marvi, that point in time was when Marvi's water broke in the middle of a routine checkup with her Ob/Gyn.
This, of course, got me thinking about Agile, Aikido, and football again.
Just as the baby's arrival does with parenthood, in football, one thing can really screw up all your careful planning and preparation: the game. And what, you might ask, is it that screws up our carefully-laid plans in software development, including Agile? Why, it's the problem you're trying to solve, of course. No matter how well you try to prepare and lay out plans for creating a solution to the problem at hand, the certainty of those plans never really extends far beyond the first line of code written to solve it. From the moment you start actually tackling the problem and trying to create a solution, your plans become subject to change for a myriad of different reasons.
According to this entry in Wikipedia , it was Helmuth von Moltke the Elder who wrote, "No plan of operations extends with certainty beyond the first encounter with the enemy's main strength," which is sometimes mistakenly simplified to "No plan survives contact with the enemy."
So Much To Do, So Little Time...
You've probably heard football players talk about the "speed" of the game when they go to the next level of play. Whether it's from high school to college or college to pro, players often talk about how much faster the next level is from the last. It's as though they felt like Lucille Ball in the classic assembly line bit: overwhelmed, helpless, and hopeless.
I'm sure many people trying to go Agile feel much the same way. Because just when you think you've got Agile-Scrum down, you realize there's a bunch of engineering practices from Agile-XP (Extreme Programming) that complement it. And then you hear that there's a bunch of things from Agile-Lean that you can do to scale Agile to the enterprise level. And so on. Have you ever seen that poster of a gorilla sitting down, looking really tired and dejected? The caption says "Just when I thought I knew all the answers, they go and change all the questions." Yeah, like that.
So what do you do when, just as you thought you had all your ducks in a row and were ready to take your organization to the promised land of Agile, a bunch of people start asking a hundred different things about what exactly is in store for them in the land of flow and quality and how are you all going to get there? What do you do when, as my colleague Michael so succinctly put it, "The horse is already out of the barn," and you realize that there are still a million different things to do that you didn't put down in your plan?
Too Much On Your Mind
When I started learning Aikido, my partners would often tell me that I was too tense. They could feel me tense up my arms and body whenever they grabbed me or attacked me or whenever they tried to perform a technique on me. In Aikido, tension keeps you from executing techniques properly and it changes the way your partner applies a technique on you. It also makes for a less than enjoyable learning experience for both you and your partner.
What makes you tense up? In Aikido, you tend to tense up when you think too much about what you need to do. When you first learn a technique, you naturally want to do it exactly right. You tend to break it down into all the little things you have to do: watch your footwork, your body position, how you break balance, how you control your partner, etc. Then there's the technique itself.
In football, the players have to deal with lots of things all at once too: the game clock, the play clock, where the line of scrimmage is, where the first down marker is, where the sideline is, where the goal line is, the count, how the other team is lining up, how your team is lining up, etc. And then there's the play itself.
In Agile, well, you already know how much there is to think about in Agile. How can you not tense up with all these things to watch for? What can you do to keep from freezing in your tracks like a deer in headlights in the face of the barrage of concerns people bring up when you tell them you're going to go Agile with them?
First of all, relax. Empty your mind.
My Aikido partners would always tell me one thing whenever they felt me start to tense up in practice: "Relax. I won't hurt you." After a while, I learned to trust my partner and myself. I learned that relaxing made it easier for me to receive the technique when it was performed on me. Relaxing also made it much easier for me to perform the technique. I found that when I didn't think too much about every single thing I needed to do, I could actually do everything better. In Aikido and many other martial arts, it's called "the empty mind." In football, it's that seemingly magical transformation in players that happens when they "settle in" and learn to "slow down" the speed of the game.
In Agile, it seems it's not that simple to just relax. Or is it? Let's see, we have the prioritized backlog. We have the timeboxed iterations. We have the principles of "Doing The Simplest Thing That Could Possibly Work" and "You Ain't Gonna Need It." We have the feedback loop from retrospectives, and sustained incremental delivery of working software, and frequent customer demos of working software. We have the daily standup meeting. We have "Eliminate Waste" and "The Last Responsible Moment." We have the "40-hour work week," and so on.
If we just pause long enough to catch our breath and look hard and understand the intent of the Agile techniques and practices, you'll see that they all add up to humbly accepting one simple truth: "You ain't always gonna get it right the very first time."
Second of all, don't stop.
The other thing I heard a lot during Aikido practice is "Don't stop. Keep going." When you're learning a technique, there's a natural tendency to stop and start over when you realize you did something wrong like turning the wrong way, pointing your foot in the wrong direction, or not breaking your partner's balance correctly. After a while, you realize that making mistakes is a big part of the learning process. That's why you just have to keep going and finish the technique.
Sometimes, it's not what you do that changes the dynamics of execution. In Aikido, we practice with different partners of different ranks. Each one receives the technique differently. What may work for one does not necessarily work for another. But still, you keep going and finish the technique so you can learn to feel the difference.
In football, this is the same as getting YACs, yards after contact. If you're not dragged to the turf on first contact, you keep moving, keep your legs pumping, keep the pile moving, try to break tackles, and fight for every extra yard you can get.
Software development and Agile are no different. No two projects are the same. Why do you think there are so many different accounting systems out there? And the business problem is always changing under you. There's always something that puts us back on our heels, tips us off balance, making us adjust to the new state of things.
The opponent doesn't stop the attack when you mess up a technique. The play doesn't end when that first tackle is made. The game doesn't stop when you turn the ball over. The need for a solution doesn't go away even when your understanding of the problem changes. The business doesn't cease operations just because you're not doing "pure Agile."
If, as apparently the Buckeyes did at Purdue today, you lose a game, you shake off your disappointment, go over the film and learn from your mistakes, and get ready for the next game. If the software isn't doing quite what it's supposed to yet, you write another test, write more code, refactor, and schedule another demo. If your development process isn't delivering all that Agile promises, you have a retrospective, put a process improvement story in your backlog, and get it done in another iteration.
It's all about improvement
There are no promises of a black belt, no promises of a championship title, no promises of development bliss and total customer satisfaction. If, in the end, you do get all that, then that's just a lot of icing on the cake. The whole point really is just doing something and trying to get better at doing it. That's all we can really shoot for, right?
"The reality is that nobody is going to give you a little gold star for being agile. They might, however, reward you for becoming more effective at system delivery." -- Scott Ambler, Chief Methodologist / Agile & SOA, IBM Rational
As for Ben and Marvi, well, only time and Mateo Natan will tell you what you guys need to do next. Good luck and remember: relax and just keep doing what you gotta do. You'll be fine. Mazel Tov!
Wednesday, October 14, 2009
More Agile Analogies: Football
It's fall again and for me that means Saturdays are reserved for watching the Ohio State Buckeyes play for another Big Ten title and a shot at a Bowl Championship Series game in January. Three hours of watching college football gives me a lot of time to think about agile and lately, I've been thinking about analogies. Here are just a few that have come to mind these past few Saturdays.
Going agile is like switching from "three yards and a cloud of dust" to a "spread option"
» Your players are going to need time to adjust to the new plays before they'll be effective.
» Some players will quickly take to the new scheme because it suits their style of play.
» Some players will quit the team because they just can't handle the new style of play.
For example, look at what happened to the Michigan Wolverines after Rich Rodriguez took over from Lloyd Carr. The Wolverines went 3-9 for that first season under Rich Rod, the worst in the program's history. This season, with a new quarterback and players who are more accustomed to the type of play, they are starting to get a lot better again. Hopefully, they get good enough to at least make the game against Ohio State interesting.
Successful agile teams are like good football teams
» They are good all around: offense, defense, special teams contribute to winning the game.
» You take the game one play at a time.
» You get to the goal by getting a bunch of first downs and moving the sticks.
» You have to finish a drive to score; you don't get points for punting.
See The Discipline of Regular Delivery (of working software)
» Don't blow your coverage.
» Play with a controlled rage.
» Take care of the ball at all times.
» Be prepared to call out an audible.
» Miscommunication will get you in trouble.
» Sometimes, the best decision is to just throw the ball away.
» Eleven men on the field, at most.
See Agile Team Size.
» They recruit talented players.
» The best and most experienced, not necessarily the most talented, players are the starters.
» The "star" players always recognize that due credit must be given to the O- or D-line.
» When you make mistakes you go back to the film room and study what you did wrong so you can improve your play and avoid making the same mistakes in the future.
» When you make good plays, you go back to the film room and study what you did right so you can improve your play and do it better in the future.
» Huddle up before the play to make sure everyone knows what we're doing.
» Have players who can make good "reads" of what the opponent is going to do, who are able to make "adjustments" quickly, who can find a "seam" and gain good yardage, who can see the "holes" in the defense and capitalize on them, who can "feel" the pressure of a blitz coming.
See Four Stages of Competence, Refactoring, Code Smell
See Four Stages of Competence, Refactoring, Code Smell
» If things are getting a little hairy, call a timeout to talk about the next play.
» Listen to what Coach says.
Sometimes you gotta wonder if some of these football coaches would do just as well coaching agile teams. Let me know if you have any other football-related agile-isms or agile-related football-isms and/or links to related articles.
Thanks and GO BUCKS!
Tuesday, October 13, 2009
Agile Analogies: Aiki Training
While going through the results of a self-googling search—no, I wasn't stroking my ego, I was simply trying to figure out if and when I had added my name to the list of signatories of the Agile Manifesto—I stumbled upon an old entry in Damon Poole's blog about Agile Analogies and was pleasantly surprised to see that he had actually quoted me. And yes, at this point my ego was getting somewhat tumescent. I vaguely recalled the text that was quoted so I kept going through the results and found more Aiki-related analogies I had made in comments about an article written by Martin Fowler posted on InfoQ.com.
Damon Poole's blog entry: Do It Yourself Agile: Top Ten Agile Analogies
Damon Poole's blog entry: Do It Yourself Agile: Top Ten Agile Analogies
Subscribe to:
Posts (Atom)