8th Light Blog: Tag bradbury

Own Your Tools

Doug Bradbury — Thu, 18 Sep 2008 06:00:00 +0000

I spent a lot of time with my grandpa growing up. He has spent much of his retirement ‘fooling around’ in a workshop he built on his slice of Pike County, Illinois farmland. From a very early age I spent a lot of weekends and entire weeks of the summer as Grandpa’s little helper. I’d work on the things he was working on while helping and learning. When I was about 7 years old, I was helping Grandpa refinish a dresser. I had a flat paint scraper in my little hands and was trying to dig into the layers of flaking paint that gripped the dresser. I really didn’t have the strength to get under the paint with that big blade, so I turned the tool on edge and started scratching deeply into the wood. I was making progress now, but tearing the heck out of the surface. Now in Grandpa’s version of this story, he says that when he saw what I was doing he corrected me too harshly and sharply and later found me teared up in a corner of the workshop sorry for what I’d done. I honestly don’t remember being that hurt by his rebuke, but I do know how to use a paint scraper and dozens of other tools properly because of that time I spent ‘helping’ grandpa in his shop.

As software crafts-people our tools are other bits of software. We spend every minute of every day using software. Our editors, compilers, interpreters, source code repositories, IDEs, debuggers, and test frameworks enable every stage of our work. Everything we do to create and add value to a software project requires some other software tool to make it happen.

At many of the places I’ve worked, the developers have a laundry list of complaints about their software tools. Often, teams develop elaborate rituals and incantations to dance around the shortcomings of their tools. “Before you check in, copy this file over there then add a note to that file then spin around in your chair three times and your check-in should succeed.” Now I agree that there are lots of poorly designed tools out there. Some tools do things that just don’t make sense and others crash all the time, but I have a challenge for us as software crafts-people: Own your tools. Tools are software, you are a software crafts-person. You can find or make a tool to do anything you need.

Groups decide to invest in a tool, often at great cost, but very few people end up understanding or even using the tool. The tools usually gets blamed for its shortcomings before anyone has really made the effort to get them to work. They give up on it far to early. Own your tools. Understand everything it can do, and if it isn’t enough, find a way to make it do what you want.

One of the cool things that happens is that investing time in your tools may give you the chance to explore a new language. One of our goals as craftsmen at 8th Light is to learn a new language every year, but often its hard to justify the time spent in a new language when you are heads-down in a project. Using a new language to create a tool for yourself may give you just the excuse you need to spread out a bit and learn something new.

Is it really worth it? Can the time spent writing “non-production” code really be justified? Let’s take a task, say the creation of a new class in C++. Most people when creating a new class, will open up the last class they worked on, copy the entire thing, paste it into a new file, delete all the methods and data, then do a find/replace on the class name. There are probably a few comments that need editing, the revision history needs to be cleaned out and maybe there is a comment header or footer that needs to be updated. This entire process could take maybe 2 minutes. It hardly seems like it’s worth automating. Except … Wait! It won’t compile, because you mistakenly didn’t remove the parameters from the constructor and the compiler can’t resolve the dependencies. This is a manual process, so it’s error prone. So you spend maybe another 3 minutes getting the thing to compile. Then we need a test harness so you do the same copy, paste, delete, find / replace process. 8 minutes later we have a new class and test harness and we are ready to start working. The hour or so investment to build a tool for yourself will surely be worth it now. If you share your work with the rest of your team and suddenly everyone is saving 8 minutes every time a new class is generated, you might have your hour back by the end of the week.

Some IDEs and editors have some class generation utilities for you. This may get you part of the way there, but it probably won’t put your company’s header on the top or put in your source control keywords. It may not make your destructor virtual or create a private copy constructor to start like I like to do. The tool doesn’t do exactly what you want. Own your tool. You are a software craftsmen. You can create software that generates a class for yourself. If you are in an editor that supports macros or bundles, you may be able to implement the tool in the editor’s macro language.

In this spirit, the craftsmen at 8th light have contributed to open source software tool projects for several years. Micah is the author of the widely used Fitnesse acceptance test framework and Eric has taken over the management of Selenium on Rails. Micah’s also been working on a whole new development framework called LimeLight. We love open source tools because they let anyone own the tool.

Grandpa used to make things out of sliced walnuts. He’d glue together little baskets or crosses and fill the walnut cavities with colorful beads. As you can imagine, a walnut is a pretty difficult thing to slice. At the very least it’s awfully dangerous to get your fingers that close to a band saw. Grandpa showed me a while ago the tool that he made to save his lower digits. It’s a pretty simple block of wood with a half-walnut sized divot carved out of it. It was a woodworker using his woodworking skills to create (and own) a tool for woodworking.

If you’d like my class generator, you can have it here. Chances are, it won’t do exactly what you need it to do, so … own your tool.

Maturing the Manifesto

Doug Bradbury — Wed, 27 Aug 2008 12:54:00 +0000

There has been an interesting discussion happening about adding a 5th value statement to the Agile Manifesto. Uncle Bob Martin proposed this addition earlier this month at Agile 2008. The proposal has centered around the idea of craftsmanship or professionalism. In his keynote, Uncle Bob proposed that we value “Craftsmanship over Crap” and in a later blog post suggested “Craftsmanship over Execution.” I strongly agree with the call for more professionalism and craftsmanship amongst software developers.

The original value statements are comparative. The things on the right still have value, but the things on the left are valued more. “We value working software over comprehensive documentation.” I think what has happened is that we have found something we value MORE than “working software.” We value well-crafted software over working software. It’s very important that the software works, but even more important is that the code is clean, that it is easy to read and therefore easy to change.

I’ve been reading “The Craftsman” by Richard Sennett. I’ve found a great definition of craftsmanship. “They are dedicated to good work for its own sake” (Sennett 20). A craftsman is driven by quality. Quality software is software that both does what is is supposed to (works) and is clean and easy to continue to work with.

This has me wondering about the other 3 value statements in the manifesto. Are there things that we value more than those things on the left hand side? We are learning day by day better ways of doing software, so what have we learned since 2001? We have a good idea about how Craftsmanship shapes the way we think about ‘working software.’ How can the idea of Craftsmanship change how we think about ‘responding to change’, ‘individuals and interactions’, and ‘customer collaboration’?

Sennett, Richard. The Craftsman. Yale University Press. New Haven and London. 2008

How Doug got started programming

Doug Bradbury — Sun, 10 Aug 2008 13:43:00 +0000

Tagged by Micah Martin

How old were you when you started programming.

When I was about 11 or so I bought a Color Computer III at a garage sale. I started typing in some basic programs that I found in a math text book or something. I had no disk or tape drive, so I had to start over every time I turned the computer on. I don’t remember what the program did. I do remember playing the game with the bouncing ball, paddle and busting up bricks.

How did you get started programming.

I started writing static web pages somewhere around 1995. I was the president of my high school’s computer club and we built the first every website for Jacksonville High School, complete with a presentation to the school board. I’m pretty sure the site had blinking text.

We also started learning C++ in the club. We didn’t have a text book, but our sponsor, Robin Manker, would print out sheets each week for us and we’d bind them into one of those plastic spiral bound things that you needed the machine to open up the binding.

What was your first language?

BASIC

What was the first real program you wrote?

Like others, I’m not sure what makes a program ‘real.’ I remember that my first C++ exercise was a Fahrenheit to Celsius converted.

What languages have you used since you started programming?

BASIC, ADI Sharc assembly and other uber-fun machine languages, C, C++, Java, Ruby

What was your first professional programming gig?

My first job was writting DSP (Digital Signal Processing) algorithms in assembly. The first thing I worked on was the compressor algorithm, I implemented time sharing on the averaging algorithms and reduced the cycle count by 30% or so. The processor was an Analog Devces Sharc. It had two data buses and two ALUs, so you could basically make two read/writes from memory and two arithmetic calculations per clock cycle. We’d write lines of code that looks like this:

r1 = r2+r5; r3=r6-r7; dm(i6) = r2; r5= pm(i3);

Everyline of code would be followed by a line of comments explaining the line. It was painstaking work, but It’s how I learned to be methodical and linear. It was also a whole lot of fun to listen to your code after you finished it.

If there is one thing you learned along the way that you would tell new developers, what would it be?

I still remember one of the first things Robin, the first person to teach me how to code used to say. I still pull it out often. It went something like this.

1) There is a teapot sitting on the counter. How does the programmer solve the problem of making tea? He picks up the teapot and sets it on the stove.

2) There is a teapot sitting on the floor. How does the programmer solve the problem of making tea? He picks up the the teapot and sets it on the counter. The he says “I’ve solved this problem before”

What’s the most fun you’ve ever had programming?

Kevin Moore was one of my first mentors when I started working at Shure fresh out of college. These was a time, when we would stay late every Tuesday night and code together. He was the first one to tell me about XP things like “What’s the simplest thing that could possibly work” and pair programming. Late on Tuesdays we didn’t have any managers telling us to stop wasting time with two people at one computer. We paired together writing the microcontroller code for the DFR22. We had a lot of fun and pulled of a pretty amazing project in something like 8 months.

Up Next

Note sure if they have blogs or not: Kevin Moore, Robin Manker

That's Not Agile! Bibliography

Doug Bradbury — Thu, 07 Aug 2008 15:58:00 +0000

Mondo Cane. 1962. http://www.youtube.com/watch?v=fSZXe5NjqAw]

McConnell, Steve. Cargo Cult Software Engineering. IEEE Software. March/April 2000. http://www.stevemcconnell.com/ieeesoftware/eic10.htm

Frye, Colleen. Alistair Cockburn on what’s agile, what’s not. 2007. http://searchsoftwarequality.techtarget.com/news/interview/0,289202,sid92_gci1255480,00.html

Beck, Kent. Keynote Address. RailsConf 2008. http://www.viddler.com/explore/gotthingsdone/videos/5/

Vandegriend, Basil. To Be or Not To Be Agile. http://www.basilv.com/psd/blog/2007/to-be-or-not-to-be-agile

Spolsky, Joel. From the “you call this agile?” department. http://www.joelonsoftware.com/items/2006/11/15.html

Webber, Jim, Ph.D. Agile Atheism. http://jim.webber.name/2006/11/30/a7ccc5a7-08a8-4594-a347-5f78e13f04f2.aspx

Martin, Robert. The Founding of the Agile Alliance. http://blog.objectmentor.com/articles/2007/07/10/the-founding-of-the-agile-alliance

Fowler, Martin. Writing The Agile Manifesto. http://martinfowler.com/articles/agileStory.html

Holy Bible. Matthew 15:1-11. http://www.biblegateway.com/passage/?search=matthew%2015:1-11;&version=31;

That's not Agile, Live

Doug Bradbury — Sat, 26 Jul 2008 14:48:00 +0000

About a year ago, I wrote That’s not Agile. The idea has grown a bit since then and I will be presenting it as a workshop at Agile 2008. If you are coming to Toronto, please consider coming to check out the workshop. It all happens Thursday morning (8/7) at 8:30 am.

In this workshop we’ll be looking at the differences between the practices of Agile and the values/beliefs in Agile. We’ll explore questions like “What makes a practice Agile?” “Is it your practices that make you Agile or you beliefs?”

I’m especially hoping to find some people in the room who have been on a team that has struggled in transitioning to Agile.

See you in Toronto!

That's Not Agile!

Doug Bradbury — Sun, 05 Aug 2007 11:51:00 +0000

Removing the religion from software development

I had feared those words. I’d often been tempted to use them myself, but something told me I shouldn’t. As I sat in a planning game on a previous job, I heard the words. They still make me cringe. â€œWe can’t do it that way. That’s not Agile.â€

I’m a big fan of agile. I’ve long been convinced that the agile movement truly is uncovering ways to do software better. It’s revolutionizing the way that companies approach software. At 8th Light we’re using Agile to help us deliver the highest quality software possible to our clients. I wonder though, how exactly something can be classified as un-agile?

What is Agile anyway? Can it be measured? Can one thing really be more agile than another? If I had a yardstick and I was going to measure Agile, what would the markings be along the stick? What units would I use? ‘Points’ has already been taken, so maybe I should invent a new unit. I’ll call it the Agl. For every hour of pair programming an organization does it gets 10 Agls. Unit tests are worth 1 Agl each. Acceptance tests get 100 Agls. I’d use negative values too. For every page of documentation written, an organization looses 40 Agls, but the group running in iterations gets 1000 Agls. One week iterations are worth 2000.

The problem is that as a development organization adopts Agile and buys into various processes and practices, the temptation quickly grows to covert that development process into religion. â€œWe can’t do code reviews, that’s not Agile!â€ â€œWe don’t write documents, that not Agile!â€ What may start as genuine excitement and passion can quickly become religious dogma when those involved in the process lose sight of why they do what they do. Let me say that while I am a religious guy, I hate religion. Religion, to me, means action without thought: doing or saying something because that is the thing that you are supposed to say or do. I’d rather call what I have faith. Faith comes from beliefs or values held and turned into day-to-day living.

Since we are talking about religion, I thought I story from the Bible might be appropriate. Jesus and some friends were sitting down to eat when some super-religious folks showed up and started berating Jesus for letting his friends eat with dirty hands. These religious-types had established an elaborate ceremony for washing hands that had very little to do with removing bacteria. Jesus comes down hard on these guys for exchanging true principles for religious dogma. He responds by handing them the principle that does really matter. â€œNothing outside a man can make him ‘unclean’ by going into him. Rather, it is what comes out of a man that makes him ‘unclean.’ ” (1) Here one of the most well-known religious leaders of all time shows his followers that it is the true principles that matter, not the religious practices or rules.

In software planning situations and day to day development we are faced with hundreds of little decisions about how to do our work. Should we throw this code out and start building the whole thing from scratch? Should we iteratively improve the code and slowly arrive at a better design? Do I write a test for this code? Should I pair with someone or just write this myself? When making these decisions we need guidance, something to help us understand if one thing is better than another. â€œAgileâ€ is not that thing. Agile is just the label put on a whole spectrum of practices. Those guiding lights we need are principles. Principles are the domain-specific set of beliefs that an organization has adopted. They reflect what the organization values. I think it’s possible that many organizations get swept up in the excitement and freedom of agile practices that they skip this critical step of establishing the their principles. Kent Beck lays out a set of principles for extreme programming. Baby Steps, Failure, Quality, Redundancy, Opportunity, Flow, Reflections, Diversity, Improvement, Self-Similarity, Mutual Benefit, Economics, and Humanity(2) help direct an organization when it is trying to figure out the how of software development. Whenever I’ve heard Kent speak, he always comes back to the principles and values behind the practices in extreme programming. UncleBob has established a great set of principles that help us discuss and qualify designs. The Single Responsibility Principle, the Open-Closed Principle, the Don’t Repeat Yourself Principle(3), and others are guiding lights for design decisions. These give teams concrete evaluators that keep design discussions productive and prevent them from deteriorating into contests of dogma. Alistair Cockburn writes about 7 properties in Crystal Clear that can be translated into principles: Frequent Delivery, Reflective Improvement, Osmotic Communication, Personal Safety, Focus, East Access to Expert Users, Automated Tests, Configuration Management, and Frequent Integration (4). I don’t want to delve too deeply into these principles here, but an organization in the process of adopting agile should. Each of these manifesto-signing authors have explained these principles wonderfully in their books.

At issue in my planning meeting was whether or not to require a certain feature in a third party library for which we are shopping. At the time, we didn’t have a need for this feature, but we anticipated that it may show up an upcoming story. The person who spoke up saying â€œThat’s Not Agileâ€ was really referencing the XP value of simplicity. â€œSolve today’s problems today and tomorrow’s problems tomorrow.â€(2) This would suggest that one shouldn’t take on additional complexity until it is needed. However, when purchasing a third party library, perhaps the principle of Economics might suggest that paying a little more for this library today will save a lot of time and money later and potentially avoid purchasing the library twice. Which is the right decision? I don’t know, but after having agreed on the principles that guide our decisions, we can have the conversations around those principles and pick a way forward.

An organization transitioning to some flavor of agile ought to first clarify what its organization’s principles are. Read Beck or Martin or Cockburn or your favorite Agile author and choose the principles that you want to live by. Second, make the principles visible. Put them up on a wall. Have meetings where team members present a principle. Refer to them as you pair. Write about them, read about them, explore them. At 8th Light, we’ve put them on our website. Revisit them when starting a new project. If you are working with a consultant, ask them to take you through a values and principles exercise. If you are a consultant, please don’t miss this critical part of transitioning to Agile. Making your principles part of the every day vernacular of your organization will take you to a place where design and planning discussions stay productive and you’ll hopefully never hear â€œThat’s not Agile!â€ again.

End Notes:
1) Mark 7:1-16
2) Beck, Kent. Extreme Programming Explained: Embrace Change (2nd Edition). Addison-Wesley Professional. 2004.
3) Martin, Robert C. Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. 2002.
4) Cockburn, Alistar. Crystal Clear: A Human-Powered Methodology for Small Teams Addison-Wesley Professional. 2004.

Shake Things Up

Doug Bradbury — Thu, 19 Jul 2007 18:55:00 +0000

The most widespread and common greeting in the American culture is the handshake. Handshakes are shared between anyone meeting for the first time, to finalize a business deal, and to end a conversation. I spend a good deal of time around 2nd and 3rd generation Korean-Americans. In Korean culture, like many Asian cultures, the handshake is replaced by bowing. In these transitional immigrant generations, the bow and the handshake have been merged into one awkward action. I was recently walking through the reception line at the wedding of 2 second generation Korean-Americans and I went to greet the 1st generation parents. I was going to try to be respectful and offer a bow instead of a handshake, but just as I began to bend, a large hand was thrust out in front of me. I felt myself lucky that I didn’t end up with the guys finger in my nose.

One of the things I immediately noticed as I began working with the craftsmen at 8th Light is that everyday I walked into the office, every member of the team shook my hand. As each team member left for the day, he shook the hand of everyone who was left. I expect this on the first day, as you always shake hands with everyone on your first day. On the second day, I thought maybe they had all forgotten that they met me yesterday. As I realized that this would continue, It really made me start thinking.

As I went to work with another team for a little while I came to really miss the handshakes. I’d walk in the morning and maybe get an eyebrow flash from my teammates. A â€œHelloâ€ would come if I was really lucky. I decided enough was enough, so I just started shaking hands. At first, I got some really weird looks and was left hanging a few times. The looks seem to ask â€œWhy are you shaking my hand, we see each other every day.â€ But slowly it started to catch on. My teammates began to expect a handshake from me at the start and end of each day.

Here’s what I think these bookend handshakes do for a team. First, believe it or not, a handshake becomes an intimate gesture. It communicates genuine care and concern for each other. To me it’s a physical expression of the XP value of Humanity.

Second, it communicates respect. Sometimes design and project discussion can get very heated, especially if you are working with a passionate group of people. If your days begin and end with a handshake, everyday is bookended by a statement of mutual respect. There is a proverb that exhorts people to â€œNot let the sun go down on your anger.â€ That handshake is a way to let go any residual anger from the day and commit the next to dealing with each other with respect.

Third, It’s an honest statement about the hours you are working and the time you are putting in on the project. In a handshake-free environment, if I’ve had to leave the office early, I’d usually try to sneak out without anyone noticing. At the time I was in an office culture that promoted flexible hours, but you always felt like people were watching you to make sure you were still putting in your hours. I always put my time in, but because I sometimes played with my schedule quite a bit, I was always afraid that someone would perceive my time poorly. When an handshake begins and ends your day, you are being direct and up front about your time. You are communicating at the start of the day â€œI’m here, I’m ready to workâ€ and at the end of the day â€œI’m gone, my day is over.â€ There are no apologies, no sneaking in or out, and no elaborate time-tracking system. Your teammates trust that you are working as much as you should be and you are not likely to try and cheat you company or your team out of your time week-to-week.

Try it in your team. It’s a morale boosting behavior that will cost a team nothing to implement, but will be one baby step to improving the strength and productivity of the team.