Here it is. You weren’t looking for it, but you found it.
What do I know?
Archive for the ‘General Stuff’ Category.
Here it is. You weren’t looking for it, but you found it.
Llewellyn Falco and I have done a number of presentations together. I’ve always loved working with Llewellyn: I’ve learned a lot and had a lot of fun. This “Practical Refactoring” presentaion is one of my favorites.
We’ve called it Practical Refactoring, 2-Minutes to Better Code, Code Excellence for Every Programmer, Code Excellence for the Average Programmer. I think we’ve presented this about 20 times. We finally made a video of it, and thanks to Llewellyn’s dedication to editing it and posting it on YouTube – you can all now enjoy watching the fun.
This presentation was done at the Inland Empire .NET Users Group in San Bernardino. They are an excellent group, and if you live near enough to attend their meetings you won’t be disappointed.
If you write down every 3rd word spoken, and then write it out backwards, you can read the special secret message hidden in the video. Remember, resistance is futile – or at least frowned upon.
Jim McCarthy wrote a book called “Dynamics of Software Development”. If you don’t own it, you should.
I believe it was published in 1995, and I think I read it in 1996. There is little reason for you to do anything else until you get this book and read it.
He has an updated version published in 2006. The 2006 version includes a CD of Jim’s 23 1/2 Rules of Thumb (For Shipping Great Software On Time.)
You can find this book used for about 1 cent for the 1995 version, and about 2 dollars for the 2006 version. You have to pay shipping – but still, for 5 or 6 bucks you can get a lot good, old fashioned, unconventional wisdom. I paid full price for both, and it was well worth it.
If you think the stuff I say is worthwhile, you just might like this book. If you hate the stuff I say, then this book will give you even more great stuff to hate.
Even without taking into consideration how old this book is (almost 20 years! ) most of his insights are extemely relevent and useful (and downright powerful) if you are doing software development. A few concepts might need to be updated for changes in technology, and some of it has been surpased by modern Agile thinkging (in my opinion), but overall it’s valuable reading.
Also, he has a set of clips from the 23 1/2 Rules of Thumb (For Shipping Great Software On Time) presentation at his site: http://www.mccarthyshow.com/the-23-rules-of-thumb/
There you go. Free advice you can use today.
It’s been exactly a year since I last presented at the Agile San Diego Group.
This group was founded by Carlton Nettleton and June Clarke – over 10 years ago, I believe. At least I think it was. Regardless, they currently organize the group and make sure there are meetings just about every month. It’s a great group, with wonderfully dedicated Agile folks of all experience levels.
I started attending the meetings in late 2006 or early 2007, and did my first presentation to this group in March 2007.
But first, here is a list of the talks I’ve done, just to prove that even though I’ve presented there before, they still ask me back. That is a good thing, right?
Many organizations have adopted an Agile approach but have not seen the results they were hoping for.
Agile exists because enough people recognized serious failures in the typical phased (waterfall and other) approaches. However, in switching to Agile, many have brought along the same old thinking, expectations, and way of doing things that caused those failures. ‘Agile’ is not a new way to do the old things. It’s a way to create software that requires abandoning those old ways and thinking. What was once ‘important’ is now recognized as blocking progress.
In this advanced talk we’ll explore some of the issues that block Agile success.
For example, regardless of how desperately we desire to know the future, we can’t know it until it is in the past. Getting good (or even less than harmful) at estimating and planning just might be impossible. Even worse, planning out what we ‘think’ we want is most likely causing our failure to produce something of value. Agile is about discovery, not prediction.
We’ll also discuss the 8 Maxims I follow that have made success possible for the teams I’ve coached and worked with. I don’t have a lot of answers, but I do have a lot of questions.
I would appreciate it if you could spread the news, and let a few people know about this.
We meet at 6:30pm on the first Thursday of every month at The Linkery in North Park.
All meetings are free and open to all.
The Linkery is a restaurant/bar in North Park that has a meeting room for us in the back. Craft beer is available from the bar during the monthly presentation and you are welcome to join us in enjoying some of their top notch food after the meeting.
The Linkery is in a large purple building on the corner of 30th Street and North Park Way, close to the 805. You should easily find free street parking, but there is also a multi-story parking garage across the street that costs $5.
I will try to show up early so we can have more arguing time.
My Maxims are not meant to distract from or replace them. My Maxims are just another way to for me to frame my thinking.
I spend a lot of time scrutinizing the things I value to make sure I can minimize my blind spots and unknowns, at least the ones that make the most difference. Seems I am usually my own worst enemy.
I share my Maxims so I can get feedback from you and learn where I can improve. Please be kind.
Once again I have been able to participate in the Agile Open So Cal at UC Irvine. Great fun, great people, great sessions, great etc. Several people had seen me tweet these “Maxims” or heard me talk about them before, and asked me to present them again. It takes VERY LITTLE URGING to get me to talk about Agile, Lean, Clean Code, or anything programming. So, I proposed a session – and here are the notes:
1- It is in the doing of the work that we discover the work that we must do. Doing exposes reality.
I live this daily. Thinking about stuff is obviously worthwhile – I don’t discount that. But doing is way more important.
2 – “Responding to Change” is impossible unless code is easy to change, easy to maintain, easy to fix, and easy to enhance.
The “easy qualities” – I learned them from the greatest programmer I have ever worked with: Fred Zuill, my little brother. Back in the 90′s he used to do a talk on the Qualities of Software that was pithy, meaningful, and wickedly sardonic. If you ever get a chance to hear him speak, do it. If you see him please remind him he owes me $18.
3 – Question Everything – put special focus on our deepest held beliefs. What we trust most hides our biggest problems.
I’m pretty good at getting comfortable in my ways. Gotta work at keeping that from blocking improvement. When I really believe something, I’m likely to be fooling myself. Lets keep things uncomfortably wonky.
4 – “Working Software” is software that users are actually using. Until it’s in use it is truly useless.
This is my understanding of how “Working Software” should be thought of (as in the Agile Value of “Working Software over Comprehensive Documentation”).
Let’s not fool ourselves: “Potentially Deliverable” is a lot like “The check is in the mail”.
5 – Stress at work diminishes value. Crunch-time is a symptom of harmful and counter-productive attitudes.
Nuff said? I hope so.
6 – We are the innovators of our process. Learn what works for others, prove it for our self, innovate beyond.
Just a suggestion: Don’t wait until you are an “expert” to innovate. Just like Jello, there is always room for innovation. (You remember those ads for Jello, don’t you? Dang, you young people really missed out on the best days of television. You remember television, don’t you? Dang… I’m getting old, so it seems)
7 – The object isn’t to make great software, it’s to be in that wonderful state which makes great software inevitable – Robert Henri, paraphrased
This is a paraphrase of the well known quote from Robert Henri. Just replace “great software” with the word “art” and you get the original (and much more meaningful) quote. I replay this one over and over in my head all the time. Wish I was the one who had said it! I was introduced to this quote many years ago by Donald Faast, an amazing show-card writer and sign man. I think he is in Colorado now. If you see him, just say thanks for me if you would.
8 – The more we work at the work we do, the less capable we become -Repenning/Sterman – Make time for improving capability
Dang. If you haven’t already read the paper “Nobody Ever Gets Credit for Fixing Problems that Never Happened: Creating and Sustaining Process Improvement” by Repenning and Sterman then please click on it and read that now: http://bit.ly/Qd3NmR - It’s a pdf file.
9 – I reserve the right to add, remove, change, improve. (This one has been added since the session).
I expanded on these greatly during the session, and invited feedback, observations, and discussion. Unfortunately I was not able to take notes. Overall, I feel it was well accepted and if it was not, my memory has already painted it much better than it actually was. Thank you memory!
Remaining Puzzles, Recommendations, Next Steps:
I pointed out that these Maxims will change and grow, and invited the participants to add, remove, change, improve
Drew has been very encouraging to me, and on his own he quickly put up a site and posted the Agile Maxims: http://agilemaxims.org/ - Remember, this whole thing is just me thinking out-loud.
[NOTE: To make sure people are paying attention, I always purposefully put a hidden typo in my posts... see if you can find it.]
One thing I really miss in Agile is having long, incomplete, boilerplate documents for me to “sign-off”. I like to write code and deliver working software quickly, but even more I LOVE to read documents and like nothing better than to spend long days before a glowing flat-screen reading incomprehensible nonsense carefully crafted to appear complete and correct while still being essentially content-less. Doesn’t matter what they are about, as long as they have small type and lots of words. Of course, nothing is further from the truth. If I want to read nonsense then I’ll read Edward Lear. Or my own writings.
Even more, I love to take responsibility for documents that I did not write. It gives me the feeling that I am a grown-up. But apparently, I am very unsophisticated regarding sign-offs. Or I was until recently…
I had one CEO show me the policy for documents at his organization (let’s call it “Anonymous Inc”) where there were 3 sign-off statements for a manager to sign on any document requiring her approval. Oh joy!!! It is in the spirit of Extreme Documents, I suppose. If one signature is good, why not dial it up and try three? More is always better. In his defense, he was showing this to me as an example of something he wants to abolish – he understood the absurdity of it.
This typical sign-off is for the manager-type to “approve” the document. In software development this often indicates that others can rely on this document as being “okay to use for doing whatever it is they do next based on this document”, and that it is Complete and Correct. This is actually the third signature to apply after the next two required signatures have been taken care of.
At Anonymous Inc, besides approving the document you are also required to sign-off that you have read the document. You’d think that approving something implies that you read it. Guess what? Apparently this isn’t as common as you might think, at least not at Anonymous Inc. I suppose the “I have read this” signature solves the problem of someone later on saying “I just signed it, but I didn’t read it – if I knew what was in it I would not have signed it”. I suspect that a lot of documents get “approved” without the approver having actually read it, and VP’s and upper management can always say “I was so busy I had my underling read it – he said is was okay so I signed it. Let’s fire him, okay?”
Okay – “I approve this document” might make sense in some organizations. ”I have read it” at least keeps some people a bit more honest, I suppose – I’m not sure it would. But “I understand it” is something I just do not understand. Still, it is a very fun idea, and Anonymous Inc is all about fun. Still, just because I say “I understand” doesn’t mean I do. Any parent knows that. “I understand” can also mean “shut up already”. But then, what do I know?
Have fun out there, and be careful when you sign-off.
In the traditional phased SDLC approach, a phase for ”Requirements Gathering” is done very early on in the process. We can argue about all the issues with this some other time – I am just covering one issue here.
My opinion of this “phase” is that it is pretty much worthless: THERE IS NO WAY TO PROVE THAT THE REQUIREMENTS WE’VE GATHERED ARE COMPLETE AND CORRECT UNTIL WE HAVE WORKING CODE. Working code, in this sense, means code that is actually being used to do real work for the real users. Does that make sense? If not, you probably don’t want to read on, and probably shouldn’t bother reading anything I have ever written or will someday write. Plain and simple.
One issue is that requirements will rot if not used promptly after collecting them.
Early humans are thought to have used a subsistence strategy where they hunted and gathered (and scavenged and stole) their food for immediate use. If the food was not eaten shortly after it was obtained, it would rot or otherwise become useless. The food needed to be put to work within minutes or hours, or at most a few days. Otherwise, the effort of hunting and gathering would go to waste.
Just like the early hunter and gatherer folks, we have no way to “preserve” the requirements we’ve gathered. We don’t even know if they are edible. And yet we store them for a long time, and do a lot of work with them during that time, and base a lot of decisions and work on them (like estimates, budgeting, designs, architectures, ramping-up efforts, coding, testing, marketing, and so on) and all the time the requirements are rotting.
It isn’t until the code becomes true working code that we can get real information about the correctness and completeness. Until then everything is just assumptions and guesses. Unfortunately, by the time we learn that the requirements have indeed rotted it is too late. They have become toxic, wasting our money, time, and effort, and killing the usefulness of the project they are supposed to define.
Early Humans understood this, and therefore rarely wrote software, and never ate mayonnaise that had not been “refrigerated after opening”. Fortunately for Late Humans (us, that is), someone eventually figured out how to preserve foods so we could buy and eat them days, months, or years and years after they had been plucked, prepared, and packaged. However, to this day, I have seen no way to preserve requirements.
So, my recommendation is: Eat your requirements as soon after you have picked them as possible. Between the garden and the kitchen they have already started to lose their sweetness. [Please imagine that there are many other very funny food based metaphors here. I am not having trouble coming up with them as such, they just don't seem all that meaningful, and they aren't as funny as I thought they would be].
How do you do this with software? You use a very short “discover, define, code/review/re-discover, deliver, discover more, repeat” approach during which we are continually discovering what it is we really need to do:
Following this approach the requirements will not rot because you leave them “on the vine” until you are ready to eat and digest them. Of course, what comes out after the eating and digesting is not covered in this article: At some point all analogies break down.
[NOTE: Everything I say in this post and on this blog is based on my experiences, study, and observations. It is MY OPINION. It is the way things seem to me. It might be useful to you, might not - I don't really care. If you want to argue about it, that is fine. I am suggesting that there are better ways to do almost everything we do in software development, and that it is worth thinking about it and doing something about it. You might already have better ways to do things, and I want to hear about it.]
I’ve signed up for a few sessions at the SoCal Code Camp at USC in Los Angeles. The dates of the camp are October 15th & 16th, and I will probably be there both days. There are about 87 sessions listed so far, so you are sure to find something of interest.
Here are the sessions I am doing:
I hope to see you there… whoever you are. Let’s talk Agile and write some code.
A boss of mine once said to me ”I wish I had your passion and interest in coding – I lost that a long time ago”. I think that is kind of sad, especially if you make your living making software. I don’t think I could spend each work day doing something I was bored with – but of course, a lot of people do that, and I’ve worked with a lot of programmers who have lost interest in programming. Seems they were once interested, and now they no longer are.
Perhaps I’m just naturally interested in programming and can’t help myself, or maybe I have a mental disorder – but I seem to be able to stay engaged and still enjoy programming every day. I think part of the reason I keep my interest is that I continuously “refill the cup”. When I sense I am starting to loose interest (or even long before that) I look for a way to refill the cup.
One note: I don’t really think it is ever “too late” to regain interest.
I’d like to share a couple of ways that work for me: Intentional Practice/Effortful Study, and Programming as a Social Activity.
My friend Jason Kerney did a talk on Intentional Practice at the San Diego .NET Development Group back in March. I have a lot of respect for Jason. He has an infectious passion for programming, clean code, and continuous improvement and I always learn a lot from him.
I had talked with Jason about this idea and like it a lot: It’s important for us programmers to intentionally practice our craft. I remembered reading an article on the topic somewhere, and tracked it down at Coding Horor: http://www.codinghorror.com/blog/2008/06/the-ultimate-code-kata.html. In this article from 2008 Jeff Atwood quotes an article by Steve Yegge (from 2005) called Practicing Programming. You can read this article at http://sites.google.com/site/steveyegge2/practicing-programming. Steve refers to some other articles, and I think if you follow the references in those articles you eventually end up at Kevin Bacon - but you know all about that. With all this great stuff already written about practicing our coding craft I won’t have to regurgitate that here.
Anyway – Jeff quotes a Scientific American article that uses the term: “Effortful Study”. I like that, and suggest you read that article too, and then tell me what it is about.
I’ve been meeting up with a few friends at work, at code camps, and remotely during the last few years to intentionally practice programming. We engage in effortful study to focus on very simple things that lead to code excellence. I have been learning a lot. Hovever, even more imortant to me is that I feel rejuvinated after these study sessions. Some of the Katas have been very simple, others have been very complicated. Sometimes we move quickly to a good solution, sometimes we flounder about and don’t get anywhere. Regardless, I have a great time interacting with my fellow programmers and find I’ve refilled my cup. And that is the concept I call:
People get together to watch sports, go on bike rides, have dinner, go to movies, play games, get drunk, and lots of other fun stuff JUST FOR THE FUN OF IT. Programming can be done the same way. Two people or a whole group of people. You can do simple Kata exercises, complicated code jam style contests, work on some Open Source project of mutual interest. Whatever. A friend of mine (the brilliant and dynamic Llewellyn Falco) used to have “Monday Night Programming” get togethers every week at his house. What a great idea!
I don’t know how or why this works for me, but it does – every time I do one of these code dojos or attend a coding gathering, or some similar activity it definately stimulates my interest in the work I love to do: programming.
It might not work for you, but I love it. Next time you run into me let’s sit down, open up the laptop, and code something – what do you say? Come on, it could be fun.
Last week I was able to spend two days at the AOSoCal 2011 event with 70 other Agile enthusiasts who are all practicing, thinking about, coaching, consulting, and working with Agile Software Development. I had a great time, learned a lot, made a lot of friends, and can’t wait for the next one.
Like I said several times at the event, I felt surrounded by friends the whole time. These are the sort of people I would hope can attend my funeral to balance out the other folks who will be there to gloat and trash-talk me. Do people still say “trash-talk”?
Each Open Space event has a theme that defines the purpose of the gathering. Our theme for AOSoCal 2011 was People, Principles and Performance. That’s pretty wide open. However, unlike many typical conferences, an Open Space event is invented by the people who show up. The sessions are not scheduled until the morning of the event.
Everyone gathers in a circle, and the participants propose session topics by writing the topic on a piece of paper and announcing it to the gathering. Typically, the proposer takes responsibility for the session, choosing a time and space to hold the session, and later facilities the session. One by one the event schedule it built, and once that is done everyone selects the first session they will attend… and then off we go – the Space has been Opened. Sessions can be added at any time, and some get combined or morph into something completely different. Overall it is a very dynamic process.
From my description it might be hard to get a picture of how this all works – but it does work, and rather nicely. I encourage you to attend an Agile Open event - they are generally very inexpensive and then you could easily experience it for yourself. All the people I’ve talked to who have attended these events have been very pleased they were able to join in.
I have been to a variety of Open Space events and the details vary from one another – but overall I get a lot more of what I want from a conference than I ever get at the more traditional conferences. One thing I have especially enjoyed is that the sessions are engaging, personal, and interactive – I find this keeps me energized throughout the entire two days. Most sessions keep things lively using facilitated (or non-facilitated) discussions, hands-on activities, or interactive techniques of some sort. I love that I get to spend a couple of days continuously interacting with fascinating people who are discovering, learning, experimenting, living, and inventing what Agile Software Development is all about. How is that for a poorly formed sentence?
In addition, there are endless opportunities to just sit and talk, pair program, or take a walk (or whatever) with other attendees. Overall, a lot of fun.