The Bootstrap Protocol

I wonder if anyone already did this. If not, I wonder who will be the first and how long it will take to change everything:


"Hi all,

I am listening for UDP packets on [host:port].

If you send me an empty packet, I will send you a list of secure hashes of the services I provide and a list of IP:port addresses of peers like you and me.

If you send me a packet starting with a service hash, I will forward the payload to the service. The service can reply to you.

If you send me a request for the source code to a service given its hash, I will send you the source code along with hashes identifying its dependencies (incuding compiler/interpreter/runtime dependencies).

The friendlier you are to me, the friendlier I will be to you."

No-Brainer Refactoring with Byke

It is very difficult for computers to read handwriting, a trivial thing for us human beings. Computers beat us at chess but they are no better than mediocre amateurs at playing the game of go.

That's because computers are good at crunching code whereas human brains are honed for feeling, for recognizing and reacting to patterns. That's also why I am a much more productive and relaxed programmer using Byke.



Byke is a nifty Eclipse plug-in that shows the dependencies among the elements in my code and gives me immediate visual stimulus from what I'm doing. When you encounter a familiar pattern in your life like a friendly face, an angry animal or the smell of food, you don't have to think. You simply feel it.

The diagram above was produced in realtime from this class from an actual project of mine (a calendar app that sends email reminders).

Take a look at the code. Are all refactorings immediately obvious? Can you feel them? Do you see the dependency cycles? Which members (fields and methods) can be extracted? Can you >feel< any clusters among members that can be extracted together?

No. These things are not easy to see by looking at the code.

Byke tries to layout the diagram as best as it can, but often the result is ugly, unpleasant. Ugliness/beaty and pleasentness/unpleasantness are FEELINGS I get without having to think about code at all.

Dependency cycles are shown in red so they stand out like the sore thumb they are. I introduced a method call just to see the dependency cycle in red, above. After removing it, this is what we get:



Clicking on the "sendRemindersTo" box highlights its dependencies in blue, above.

That diagonal blue dependency pointing up and crossing several boxes is >annoying< me. My first reaction is to think: "Byke sucks! I could layout this diagram much better manually! I would just have to pull that box up.". Then I took the humble approach and thought maybe my own code wasn't all that clean... maybe there was some refactoring I could do. Hmm...



That box is being pulled down by the arrow to "isToday". I realized those four static methods selected above go together nicely so I moved them to a CalendarUtils class. The diagram is less cluttered already:



WHOA! Now I can >see< an entire tree above, on the right side, separate from the rest, apparently used to "choose" something. Can you see it? Without even having to know about what the code does we can >feel< the class is not cohesive. We can extract that tree to its own EventChooser class:



That leaves us with a result that is simple and cohesive:



No brainer.

L&C - Learning and Coolness

L&C is the software methodology we use to develop Sneer, the sovereign computing platform.

 

Douglas Giacomini, myself, Sandro Bihaiko and Rodrigo Bamboo in Guaratuba, Brazil

Our project has certain peculiarities: it is a funded, open source project and we have a small team of up to 4 developers plus occasional contributors. Our technical lead also knows a lot about the business. That is not the case in the early stages of most projects but it is often the case after a few months.

L&C is guided by two values:


1) Learning

Learning supercedes the XP values of simplicity, communication, feedback and respect:

• It is much easier to learn simple things than complicated.
• It is impossible to learn and teach without communication.
• We can only learn when we get feedback for the things we do.
• Learning sets the humble and respectful attitude we need to approach our peers, our users and the code.

Learning requires communication, simplicity, feedback and respect

Learning also gives us, once and for all, the requisite understanding of what software development actually is. Software development is not "ball dancing", it is not "driving a car" and it is certainly not civil engineering. Software development >is< learning.

Building a replica of a shopping mall, for example, with the same construction crew costs 90% of what the first mall cost. Producing a replica of a software product with the same team costs a fraction of what it did the first time because the team already knows how to do it.

The source code to any particular software system is not a product of what a team has built. It is an expression of what the team knows. That changes everything.

There are heated discussions in the industry as to whether pair programming and moving people around is productive. The notion that learning is really our goal renders all these discussions void.


2) Coolness

Coolness supercedes the XP value of courage. One cannot be a wuss and be cool at the same time.

Igor Arouca and my foot - Hammock pair programming in Curitiba, Brazil

We like working with excellent programmers, true software craftsmen, and excellent programmers like doing cool things.

Our team:

• Learns new things
• Invents new things
• Makes a difference
  
• Writes its own tools and languages when necessary
• Travels
• Parties
• Speaks at conferences
  
• Interacts, discusses and challenges
• Engages the community
  

"Pool Programming" - Didn't actually work but we tried it :)

Our team also ships working software. Failing to do so is, by definition, the most uncool thing a software development team can do.

Practices

How does L&C affect our lives concretely? Let's compare it to XP.

We believe it is misleading and arrogant to try and predict the future. Nobody likes doing the following XP things. The insight they give us is no better than an educated guess by a business-savvy project leader and the effort and stress they imply are just too much, so we dropped them:

• Release Planning
• Iteration Planning
• Project velocity
  
• Planning Game

(Scrum is glorified release planning, so we don't do that either)

We also dropped the following:

• Iterations (!)
• Continuous Integration
• Open workspace
  
• Stand-up meeting
• CRC cards

To the remaining XP practices, we added a few things:

• Significant Celebration - Instead of celebrating the Nth sprint (Yay!) we finished, we prefer to travel somewhere nice when a significant business or technical milestone is reached.

• Remote Pair Programming - Skype and VNC. Having the team co-located is certainly more productive, but we want to work with the best developers, wherever in the world they might live.

• Hammock Pair Programming - Ad-hoc wireless and VNC.

Hammock pair programming with Patrick Roemer in Florianópolis

• Team Chat - A chat conversation open on Skype all the time with all members of the team. Has the same effect as an IRC channel.

• Weekly Conference - Same as a stand-up meeting but via Skype.

• Let Your Customers Remind You 

Listening to Potential Users at the Sneer Summit in Curitiba

• The Cleaner - A role specifically allocated to refactoring. There are no fancy discussions about "technical debt", "productivity curves over decades", etc. Refactoring is hygiene.

Jules, Vincent and Wolf, The Cleaner

• Continuous Deployment - Anything any developer commits is downloaded by new users at most five minutes later on the project website. 

• Periscope - We use periscope to emerge occasionally, look forward and ask ourselves: "Are we going in the right direction? Is there a huge iceberg ahead or an amazing shortcut we could take?". That is all we need to know about the future. We plan on demand and simply take the next baby steps in the right direction. We trust our own agility so we don't lose sleep over hypothetical icebergs far, far away. Also, we don't need estimates to "measure" our team's productivity and whip developers that are late. We simply use periscope to look back and answer: "Are we progressing fast enough? How can we optimize our work?"

More than a deliberately designed methodology, L&C is an empirical observation of how we work and what we value.