Beards and Keyboards

How to meet other craftsmen

Wed, 06 Jan 2010 19:38:14 -0500

This is not about speed dating but I had the luck to meet a craftsman during these holidays. He is not a software craftsman. He does not work with computers, but with construction and repairs of homes and apartments. He is a master mason.

During my stay in Spain, I had to interview and evaluate the proposals of three local constructions shops to almost rebuild from scratch an old apartment there.

I observed a bunch of similarities with the craftsmanship movement of our software industry. This actually helped me make a decision to pick the right person for the job. If I ever jump into freelancing, I would try to have all the attributes that made me pick this guy.

The first thing before starting a project this big, is to get a proposal. You tell them what you want to do, leave them the keys of the apartment, meet again in a couple of days to review their proposals.

All our proposals were a few pages long. They describe what needs to be done and the price for each of those items. Their language is sometimes technical. They describe the techniques and materials that they plan on using. So I had to learn a lot of new words and the whole process that goes into this “big refactoring” of the apartment.

After getting all the proposals, compared prices, interviewed again with all of them, made revisions to their original proposals, we chose our shop. Here is what helped us made that decision:

Referrals

A couple of friends and family had recent experience working with them. They were very happy with the results. They were even proud to show the work that they did for them and walked us through all the details.

Passion

When interviewing with him, it was obvious that he is passionate about his work. He does not only do it for a living. He enjoys what he does. He took the time to explain the techniques that he would use and why he would apply them.

Professional

He listened to us and provided advice, ideas and alternatives about what could be done. He was honest about what could be done within budget and what could increase the final price.

Portafolio

Even though we did not ask for it, he was the only one that took the time to show his current work. We visited houses that his team is currently building and enhancing. We were also able to see his past work through the referrals.

Price

He was not the cheapest or the more expensive option. He was also upfront that sometimes his team is slower than others. He takes the time to finish his job correctly.

Payments

A very agile method of payment. Him and his team will work for you for a week. At the end of the week, review their work and decide if you want to continue working with them. You can then pay weekly, every 2 weeks, or monthly. You decide how long is the iteration (he did not call it that, of course). There is no contract, only a handshake to continue to the next iteration.

The other 2 companies required a 30% up front followed by fixed payments on certain dates.

He also agreed to send me weekly pictures of the progress through email and I am going to ask him to have regular phone calls to talk about the project. I guess I will secretly call it ‘a standup call’ or something like that ;)

Of course, this made me wonder about ‘agile’. Why does it seems so easy for this 4 people construction shop to behave like the best ‘agile’ company I ever knew? They haven’t heard the term ‘agile’ and probably don’t care for it. They are craftsmen with a business model that makes sense and works for them.

Something I admire and hope to copy someday.

“People don’t care how much you know until they know how much you care” - Cavett Robert

Elevator pitch of why keyboard shortcuts rule

Fri, 27 Nov 2009 17:09:44 -0500

A coworker asked me why I find important to learn and memorize keyboard shortcuts.

I wrote about it some time ago, but this time this person wanted my elevator pitch, so it came out like this:

If I have to use the mouse to reach a certain menu to perform an action, a simple refactoring like extracting method, or inlining a variable for example, I am likely to get lost in the menus trying to find the right option. I know I am not the only one…

If I am more likely to get lost in the refactoring menus (taking up my precious time before that urgent deadline), I am less likely to use the menus more often.

If I am less likely to use the menus, I am less likely to refactor my code often (because doing it manually is hard). And if I don’t refactor, my code sucks.

On the other hand (bad pun here), if I don’t have to leave the keyboard to refactor, typing and refactoring become part of the same flow. No extra effort in grabbing the mouse, giving it a couple of shakes because the pointer does not want to move exactly where I want and then finding the right option under the right menu.

My coworker nodded and smiled. The conversation drifted to another subject so I am not sure I was convincing. What would you have changed to make this a better pitch?

"Mark my words, if you want to stay relevant and competitive in the coming years — I..."

Sun, 15 Nov 2009 19:21:50 -0500

““Mark my words, if you want to stay relevant and competitive in the coming years — I don’t care if you’re in sales, tech, finance, publishing, journalism, event planning, business development, retail, service, you name it — you will still need to develop and grow your personal brand. Everyone — EVERYONE — needs to start thinking of themselves as a brand. It’s no longer an option; it is a necessity.””

- From the new and awesome book from Gary Vaynerchuk “Crush it!”

My pomodoro experience

Thu, 12 Nov 2009 19:27:07 -0500

I have been using on and off the pomodoro technique since earlier this year. It works great when pair programming but I have also used it alone.

In a nutshell, this our loop:

10 Agree on the goal for the next 25 minutes
20 Start the timer
30 Work towards the goal until the time is up.
40 Take a 5 minutes break
50 GOTO 10

After 3 loops, we take a longer break.

We use it for story work, prototyping, designing, team presentations, email, etc…

It seems easier to use pomodoros when working with a pair. Agreeing on the goal removes misunderstandings, puts us back on track if we went off on a tangent, and makes it easy to keep each other honest to stop typing when the clock goes off.

It requires a lot more of my energy and discipline to run pomodoros by myself. Distractions and shortcuts are all around me.

Focusing is like doing push ups. The more you do, the easier it gets.

After a couple of months working almost by myself, I wasn’t using pomodoros that much, I moved to a new team where we decided to use the technique on day one. The first few iterations were difficult for me to keep my focus since I was no longer used to the time constraint. The tomato would go off and I was just starting to get into the groove. Or I could not wait for the timer to finish because I wanted to check twitter, my email, etc …

A few days ago, a coworker that popped into our area commented on the noise level in our room. He was surprised that we could get any work done: a meeting was happening at the other end of our table and we were surrounded by 2 conference calls on speaker phone.

We run 5 to 9 pomodoros a day (yeah, meetings suck). When the timer starts, the whole room disappears, there is no noise but our conversation. It takes milliseconds to get into the groove. We are also pretty good at locking the screen as soon as we hear the bell. It has become an habit.

And at the end of the day, the sense of accomplishment is clearer. We can recall the different episodes where we reached our goal and how much progress we have done since we started in the morning.

This post was written in 2 pomodoros.

"I am sure a lot of you are frustrated at your colleagues, not being here at this conference. Not..."

Wed, 04 Nov 2009 09:31:04 -0500

“

I am sure a lot of you are frustrated at your colleagues, not being here at this conference. Not being passionate about code the way you are. And I am sure you are trying to teach them. You are talking about design patterns, test driven development, refactor your code making it readable.

I am saying that they are not ready for that. They are not aware that there is a need that could be filled by learning these things. And until we make them aware of that need, there is no meaning in trying to teach them.

”

- From Good to Great Developer - Chris Hedgate

The bouncer pattern

Mon, 02 Nov 2009 22:16:52 -0500

Last week, J.B Rainsberger talked at Agile Philly about integration tests are a scam and explained to the audience the bouncer pattern.

I am going to paraphrase the concept.

Imagine you own a night club. It’s pretty big with 7 bars around a dance floor. Bartenders must ask for your ID before you get a drink. Some bartenders are pretty good at remembering faces, others not that much. It’s Saturday night and the place is packed. As the night goes on you start to get pissed off at the fact that you need to show your ID for almost every drink. Getting a drink gets slow and sloppy. People stop showing up at your night club.

So you push that responsibility out of the bartenders and hire a bouncer that can check for IDs at the entrance of the club. Now, the bartenders understand that if you are the club, you pass the requirement for drinking. Not only this speed things up, it also minimize the possibility of something going wrong (null pointer if I don’t have my ID anyone?).

So that’s the bouncer pattern. Instead of doing defensive programming all over the code base, check for basic correctness at the edge of the class/module/service. The code becomes easier to read and simpler to maintain.

If we use constructor dependency injection to construct objects/module/service, we can help out our bouncer keep the junk out of our code.

My learnings from Code Retreat Philly

Mon, 02 Nov 2009 21:38:54 -0500

My learnings from Code Retreat Philly

sundayconf

Sun, 18 Oct 2009 17:30:02 -0400

For this sundayconf, I have a good selection of music, no, videos, no, code, no, music!

Unclebob’s prime factors Kata

Even though the video is called “Prime Factor Kata (Rough)”, the flow of the kata is perfect. The music matches Unclebob’s movement from the spec to the code and back. I had mixed feelings about the choice of IntelliJ but was surprised with the “introduce variable” popup. I wished I could have seen more refactoring tools. After hearing great things about this kata on twitter this week, the video lived to his expectations.

Here is the video

Corey Haines’ Number to LCD

Corey’s kata was more challenging that Unclebob’s and turned out to be great. The resolution of the video could have been a little better but it was easy to follow what was going on. The music choice was on target: crescendos and allegros kept me wondering about what was going to happen next. But I wish I could hear Corey’s narrative for some portion of the kata. Especially at the beginning. With 2 examples, Corey focuses on refactoring his code for a few minutes. He moves blocks of code, create structures, extract variables and keeps running the tests. The beautiful thing about all this refactoring is that adding the next 8 examples was a breeze.

That reminded me of a quote I saw this week about sharpening the saw:

If I had eight hours to chop down a tree, I’d spend six sharpening my axe. - Abraham Lincoln.

Here is the video

Starting a code study group

Thu, 15 Oct 2009 15:27:15 -0400

We are starting a new code study group at work. Here is the email that I sent to the group to kick it off:

Starting a code study group

What is it?
A code study group is a bunch of people that choose an open source project or library and read it like a book.

As they go through it, they take notes; identify patterns, critique techniques and post a report.

They look at code with a critical eye. Various style of code will amaze them, amuse them and challenge them. They learn new paradigms that completely changes the way they approach problems.

They study the work of masters to improve their skills.

They meet twice a month and nominate 2 to 200 lines of code to study.

Why study code?

To sharpen the saw

To use existing code to reflect on our own capabilities

To understand new code quickly

To identify code patterns quickly

You can even learn from bad code.

This is not something new. Musician, painters, poets get together to study the work of masters. They learn their work and quiz each other.

Since we are heavy on the java side, I created an online survey with 4 open source libraries that could be interesting to study:

Mockito
FitNesse
Spring
Jakarta Commons

I can’t wait to see what are the results of the survey. I am going to keep it open until Monday.

Philadelphia's code retreat

Sat, 10 Oct 2009 17:24:00 -0400

At code retreat, we retreat from the world to advance in our craft. We sharpen our saws, together.

We retreat from production and business value to increase our production capacity, our quality, our velocity, our ability to produce business value.

We retreat from immersion in deep technology issues to advance in our ability to learn and adopt to any technology well.

We retreat from our fears, and embrace new practices and patterns.

We retreat from our local ponds and swim in a larger pool. We connect with other passionate coders who we seldom get to code with. We make new connections and learn new lessons.

At code retreat everything is about the journey and nothing about the destination.

Join us on Sunday November 1st, 2009 in Philadelphia at indyhall. We will start at 9am and will be practicing Conway’s game of life in Java.

Here is a approximate agenda of the day:

We’ll spend 15 mins introducing the event, drinking coffee, thanking the sponsors, answering questions and describing the game of life problem.

We will break down into pairs and run an iteration of 45 mins.

Take a 10 minute break and throw away the code (this could be hard!), switch pairs and get ready to start the next iteration.

Run another iteration and throw away more code.

We will be exploring new things to try: coding with no if statements, using TDD as you mean it. 1-line methods, interfaces everywhere, etc…

We have lunch when it makes sense and see if we have something to demo.

After lunch, iterations might run shorter switching pairs after each iteration and always throwing away the work.

Finish the afternoon around 5pm or so and head for beers across the street to National Mechanics

Be ready

Bring your laptop with:

Java 1.5 (minimum)
Git
An IDE (Eclipse, intelliJ, etc…)
If you use Eclipse, consider getting J.B Rainsberger’s game of life template for eclipse

If you use intelliJ, consider adding an empty template like JB’s.

We will have coffee, soft drinks, and snacks available. Lunch will be supplied. However we are still looking for a food sponsor. Help us out!

If you are going to attend, please RSVP at http://coderetreat.ning.com/events/code-retreat-philadelphia-java or at coderetreatphilly@gmail.com. We may be overbooked, so the RSVP is required to determine headcount.

Please send any questions you might have to coderetreatphilly@gmail.com.

Hope to see you there!

My learnings from AgileTour 2009

Wed, 07 Oct 2009 20:36:51 -0400

94 people gathered for the first AgileTour stop in the suburbs of Philadelphia. A good turn out for a mini 4 hours conference! Ravi and I welcomed the attendees and gave a little intro about the conference and the speakers. After that, I spent most of my time in the Open Jam.

Agile assessments

We commented on the recent efforts to assess agility.

Bob Martin, Ron Jeffries, Chet Hendrickson, Brian Marick and Jim Shore are working on a scrum certified developer program.

But wait! Ken Schwaber and Microsoft are working on another scrum certified developer program.

Joshua Kerievsky started a mailing list to study more alternative assessments.

A big surprise for me was learning more about Ken Schwaber’s and Microsoft alliance. Their scrum developer certification is not language agnostic. I am not sure of the value of being a .NET scrum certified developer. It looks like they are matching practices like Continuous Integration or TDD to a specific Microsoft tool. I am not sure how this is valuable for the industry. As a side joke, I look forward to the MS pairing tool. That is, if pairing gets into their “approved list of practices”.

Certifications

We talked about the evilness of the scrum certification scheme and the false sense of thinking that when you are certified, there is no need for you to study more about the topic.

We tend to blame certifications but is it maybe an organization or people problem? If we look at certification as the minimum basic knowledge to perform a job, why assuming that basic is enough? Basic barely makes the cut.

Somebody made the point that Scrum is sold as a “silver bullet”, an all-in-1-box solution. Organizations or teams are not encouraged to look outside of scrum because they are told that scrum will solve all their needs.

I agree with that, but it does not matter what methodology you use if you (and your organization) aren’t continuously learning?

Forget scrum, look at the technical field. How many of us (programmers) learn a new language every year? Let me lower the bar: How many of us are somewhat comfortable in more than 1 programming language?

Since it seems impossible to avoid the birth of a scrum developer certification, I am embracing it. I hope that my company will jump all over it and mandates for all of us to become certified.

If it takes a piece of paper to make my life easier, I am all for it. Not having to argue about the benefits of TDD, pairing, frequent checkins everyday is a welcome change. I don’t expect a big change overnight, but at least, it will be a starting point.

Wrap up

I got a lot of energy out of this conference. It was nice to see old friends and make new ones. I look forward to what we can do next with Agile Philly. We have plenty of new ideas.

My learnings from Concept Camp 2009

Sun, 27 Sep 2009 18:29:30 -0400

I quickly checked the weather before packing for ConceptCamp2009. “Mmmm… rain Saturday night. It won’t be that bad.”

Well…There was a lot of it but it did not stop us from having fun, talk about code, patterns and play some team building exercises like beer pong and twister. Yep, twister.

After a good camping breakfast, we protected ourselves from the rain and started the conference.

I did not take notes during the talks, being a small group, the interaction was more important than being head’s down try to type stuff.

Note that there was almost no powerpoint use. We did not have a projector and this made for better sessions IMO.

Chris Ballance (@Ballance) “Design Patterns for Scalability”

Chris’ talk was a nice warm up for the day. He walked us through the patterns to build a scalable web site (MVC, loose coupling, Stateless, Queueing, ..).

Using twitter and facebook as references, he gave examples on how the 2 sites scaled to what they are today.

I found his love/hate relationship with the flyweight pattern interesting ;)

Steve Andrews (@SteveAndrews) “Community Speaker Tips and Tricks”

Steve speaks at many user groups and Microsoft conferences. He shared with us ~60 tricks to make your technical talk more effective. From brainstorming, mind mapping, outlining, having 3 copies of your talk as backup, inspecting the stage before your session, knowing your audience, dealing with a difficult person in the audience, timing yourself and wrapping up.

I learned that Microsoft TechEd has a “presentation competition” similar to “Programming with the stars” at the Agile conference. I thought that it was an interesting concept and a great way to get feedback from your talks even if you are not participating.

If you are on Windows, a little tool called ZoomIt does what CTRL+ two finger scroll does on the mac: zooms where your mouse is. Download it here: http://technet.microsoft.com/en-us/sysinternals/bb897434.aspx

Matthew Podwysoki (@mattpodwysocki) “F# Parallel Programming”

I am not a .NET person but I was impressed with F#. Matt’s knowledge and presentation was full of great and simple examples that showed the power of this language. Sharing syntax with Haskell and Python, F# felt easy and fun to play with.

Looks like F# is getting a lot of attention in the Bank and Insurance industry.

Matt got me interested into giving F#, Haskell or Clojure a try before the end of the year. I promised to learn a functional language before 2010.

Sara Chipps (@SaraJChipps) “Choosing Your Patterns - Architecture and Design for the Freelancer or Hobbiest”

Sara talked about her super dooper secret project that she’s launching next week. Shhh! Can’t tell you yet but it’s clever and awesome!

She shared with us her troubles building this product, how she designed her software layers and how her mom gave her detailed feedback about her site ;-)

Sara and a bunch of other guys recommended Balsamic, a screen mockup utility: http://www.balsamiq.com/products/mockups

It was interesting to hear how she outsourced some of her work. After reading the “4 hour workweek”, I am willing to give it a try.

Scott Allen (@OdeToCode) “Design Patterns for Victory!”

Scott Allen gave an awesome closing keynote and I don’t want to spoil it for you so go and read it here: http://odetocode.com/Blogs/scott/archive/2009/09/27/13241.aspx

ConceptCamp2009 was a success! Congratulations to Sara and Erika for making it happen! Will be back next year for more.

GitHub setup in 13 steps

Sat, 12 Sep 2009 13:42:22 -0400

I have used git in the past but I am a newbie to GitHub. Here are the 13 steps that I followed to get my first repository in GitHub.

1. Upgrade to the latest git: http://git-scm.com/

2. Open a github account: http://github.com/signup

3. Add GitHub’s settings to git: http://help.github.com/git-email-settings/

4. Generate a SSH key: http://help.github.com/mac-key-setup/

5. Create a repository: https://github.com/repositories/new

6. $ mkdir my-project

7. $ cd my-project/

8. $ git init

9. $ touch README

10. $ git add README

11. $ git commit -m “first commit”

12. $ git remote add origin git@github.com://my-project.git

13. $ git push origin master

Right after the Open Jam session “Is scrum evil?” at...

Sat, 29 Aug 2009 15:58:11 -0400

Right after the Open Jam session “Is scrum evil?” at Agile 2009, Ben Rady got me into thinking about my next set of stickers.

Simple instructions: fill in the blanks with a marker.

“Hello, my name is Sebastian and I have been scrum free for 2 years 7 months and 3 days”.

“Hello, my name is Sebastian and I have been scrum free for eva”.

Now, this will be cool on a t-shirt.

"If you are going to take into account stakeholder feedback, you cannot commit ahead of time to 100%..."

Tue, 25 Aug 2009 01:24:00 -0400

“If you are going to take into account stakeholder feedback, you cannot commit ahead of time to 100% of what you are going to do. You can only commit to 50% or 70% of what will be delivered in a release.”

- IBM leader about their biggest problem for Agile adoption: the governance system a.k.a product management. Quoted by Mary Poppendieck during her “workflow and schedule are orthogonal” during her Agile 2009 talk.

A breakfast story about Quality

Fri, 21 Aug 2009 08:41:00 -0400

How’s that for a ambiguous and confusing sentence: “As an organization, we must focus on quality.”

Sorry, I must focus on what? Oh, yes “quality”. And what is “quality” for you, dear Organization?

Sit down and observe everyone running in different directions:

Quality is the satisfaction of requirements
Quality is the absence of bugs
Quality is the number of features of a product
Quality is the testability and coverage of the code
Quality is the user experience
Quality is delivering value to the customer
Quality is being predictable and delivering on time

That’s the problem. Quality is abstract and subjective.

None of the definitions above are correct but if you look at them together, they are all correct.

Picture yourself taking a knife and cutting a thin slices across all of them every time you start a new user story. Now, spread it in your toast. Mmmmmm….yummy…Quality tastes good.

The circular argument

Sat, 08 Aug 2009 19:43:06 -0400

“We’re doing the best possible job of software development.

Therefore, if other people are doing better, their problems must be easier.

Therefore, we never find out what other people are capable of doing in software development.”

G. Weinberg in Quality Software Managment: System Thinking

This actually not only appears at a company level but also at the departamental level.

Teams sitting accross each other fall into this pattern. Programmers sharing their practices are ignored by others because they believe their business domain is different. Even when the practice have nothing dependent on the domain.

Usually, the more push back you get, the more desperate the team is. They know something is wrong, ask for advice and then discard it.

Why?

It’s time consuming to give it a try? Too intrusive? Too challenging? Fear of failure? No management support? Out of your comfort zone?

I am sure glad I found the name for this: “the circular argument”.

The Tao of Programming

Thu, 06 Aug 2009 16:57:28 -0400

Reading Weinberg’s book of Systems Thinking, I ran into this excellent excerpt from the “Tao of Programming” from G. James. Probably my next read.

Why are the programmers nonproductive? Because their time is wasted in meetings.

Why are the programmers rebellious? Because the management interferes too much.

Why are the programmers resigning one by one? Because they are burnt out.

Having worked for poor management, they no longer value their jobs.

"Quality is not the absence of error."

Tue, 04 Aug 2009 20:41:31 -0400

“Quality is not the absence of error.”

- I am enjoying Gerald M. Weinberg’s “Quality Software Management” book. You should repeat this sentence in your head a few times and then chew on it for a little while.

The fear of working in legacy code

Mon, 03 Aug 2009 21:14:00 -0400

Over the past weeks, I have been lucky to pair with a bunch of programmers in a large legacy java application. As we were adding tests before new features, we made important design changes (mainly related to the Single Responsibility Principle, Law of Demeter, Inversion of Control and DRY). Here are some of the fears that we experienced when working in legacy code:

It’s not my domain

Domain knowledge is always a plus but it can backfire at you when you get too comfortable in it. Especially if you are not willing to step out of it. Because I was working outside of mine, I told them to blame me if something did not look right during the code review with the experts. Most of the time, we just wanted to move behavior to the class where it belongs.

It’s not my code

Reading somebody else code can sometimes be a challenge. We all have different ways of attacking a problem. Heck, even reading your own code can be a problem sometimes. But in bigger corporations, this is about working in silos, “throwing code over the wall” and endless “steel threads”. Collective code ownership is accepted by some but refused by others. It all depends on the impact of the change that we are about to make. We checked with our “service custodians“ if we thought it could get messy but always doing the change and not throwing it to another group.

There are no tests

You need to do a small change to this big method on this big class but there are not tests for it. What do you do? Put the whole class under tests? Put the whole method under tests? In some cases, after a few tries, we found that we were able to put the method under tests. Sometimes, we had to extract our new behavior elsewhere and add tests there. Not feeling overwhelmed and knowing that we can’t solve all issues in one morning was important.

I am making the code uglier in order to test it

I always refer to Michael Feathers for this one:

“You can start to grow areas of very good high-quality code in legacy code bases, but don’t be surprised if some of the steps you take to make changes involve making some code slightly uglier. This work is like surgery. We have to make incisions, and we have to move through the guts and suspend some aesthetic judgment. Could this patient’s major organs and viscera be better than they are? Yes. So do we just forget about his immediate problem, sew him up again, and tell him to eat right and train for a marathon? We could, but what we really need to do is take the patient as he is, fix what’s wrong, and move him to a healthier state. He might never become an Olympic athlete, but we can’t let “best” be the enemy of “better.” Code bases can become healthier and easier to work in.” From Working effectively with legacy code.

I don’t have the time

You just want to get there, add a method or two and get out quickly. There are simple techniques can you can use:

Extract a new method from the existing one and test it
Extract a new class and test it
Wrap the existing method and add new behavior you can test

And what if doing that you leave the code in a better place? Simple operations like removing unused imports, changing a method name to clarify the intent can help. Remember, code is your house, you have to live in it.