On November 12 to 14 the Jax conference will finally come to Italy. On the first day there will be my presentation on How to grow a team, where I tell a bit about my adventures in growing a team in Sourcesense. It will be part of the “Agile Methods & Tools Day”.
I’m very excited to be part of this conference; look at the (other) speakers! I hope I will see you there.
Summary: I will attend this workshop by Francesco Cirillo
Ebbene sì. Mi sono iscritto al Workshop di Design Emergente di Francesco Cirillo. Sarebbe stato da pazzi lasciarmelo scappare proprio ora che Francesco “sbarca” a Milano. E poi sono anni che non vado a seguire un corso; l’ultimo è stato l’ottimo corso di Project Management XP di due anni fa, sempre di Francesco. Penso di avere proprio bisogno di continuare la mia formazione :-) Come dice il mio amico e collega Tommaso, o si progredisce o si regredisce; non è possibile restare fermi.
Ci sono ancora un paio di giorni per sfruttare lo sconto del 30% sul workshop di Cirillo. Credo che sia un’occasione da non perdere.
The common wisdom is that Ruby is slow and Java is fast. In general, it’s true. But is it always? Look at this simple test.
$ cat hello.rb puts "Hello world!" $ ruby hello.rb Hello world! $ time ruby hello.rb Hello world! real 0m0.008s user 0m0.004s sys 0m0.003s $
So it looks like it takes 8ms to run a simple “hello, world” in Ruby. How does Java compare to this?
$ cat Hello.java
public class Hello {
public static void main(String ... args) {
System.out.println("Hello, world!");
}
}
$
$ javac Hello.java
$ java Hello
Hello, world!
$ time java Hello
Hello, world!
real 0m0.122s
user 0m0.061s
sys 0m0.028s
$
Even if we ignore the time it takes to compile the Java program, it looks like running the “Hello, world” in Java takes 15 times longer than Ruby. This is due to the long startup time of the Java Virtual Machine. The times you see here are taken on my MacBook Pro; they will be different on other operating systems, but not much different.
So what, you will say? “The startup time is not important! As soon as the JVM is up and running, Java can run circles around Ruby.”
I don’t agree that startup times are not important. The startup time for Java becomes much worse when you run complex applications. A vanilla Tomcat with no web applications installed takes about one minute to start up. Compare with Webrick, the Ruby web server, that is up and running with my web application in 3 seconds. The difference in startup times makes all the difference in the world when you’re developing software. It takes at least one minute, often much longer, to start up a Java application so that I can try it. There are times when you’re developing an application when you need to test it after each tiny change. It’s very difficult to do that in Java. The problem is made much worse by the fact that in general Java “containers” can’t reload changed classes without a restart. (Webrick can do that.)
What, you will say? “Matteo gave up TDD! He tests applications manually by clicking around like a monkey!” No, really, it’s not like this. I always write production code with TDD. That does not mean that you *never* test your stuff manually on the live application. Quite the opposite: there is a danger, with new converts to unit testing, that we trust our tests too much. I’ve seen people declare a story “finished” when all the unit tests are green, without ever checking if it really works! And of course, if you never test it manually, it will not work. There is a need for manual testing (some call it exploratory testing), even if you’re Kent Beck or Misko Every.
So I hope you’ll agree with me that short startup times are important for developers. But there are other implications. The fact that it takes a lot of time to startup a Java application means that Java developers are trained to write applications in a single JVM process. For instance, we often see dozens of web applications running in a single Tomcat. If you need concurrent operations, the solution is always to run more threads within the same process. And there is a big problem with this.
The operating system’s concept of a “process” is a very useful one. A “process” is a bundle of threads and resources: memory, open files, network connections, and the like. A process in Unix or Windows is a watertight compartment. When a process terminates, *all* of its resources are released. A process cannot easily corrupt the state of another process. A process can be given limits on how much memory or CPU it can take. It’s very useful to organize a concurrent application as a set of cooperating operating system processes. That’s the way the Apache Http server works, and that is a remarkably reliable software. It’s also one of the smart ideas in the Chrome browser, to run each tab in a separate process.
It’s a good design principle to have many small modules communicating with well-defined interfaces, rather than a single monolith where all the threads can interact in unforeseen ways. It’s also the way of Unix to design applications as collections of small communicating processes. Which makes me wonder how could Sun ever get us to believe that it’s a good idea to put all of our eggs in a single, huge process. Should not Sun be the champion of the Unix way? But I digress.
In conclusion, I claim that designing applications with small cooperating operating system processes is a good principle. Java current practice runs against this, but it need not be.
Ho visto sul calendario di metodiagili.it (l’azienda di Francesco Cirillo che fa corsi) che ci saranno corsi con James Shore (The Art of Agile Development) e Diana Larsen (Agile Retrospectives). Sono un fan di entrambi i libri. E’ un’occasione da non perdere! Io mi sono iscritto. Penso che investire in sé stessi sia sempre un buon investimento.
Ci sono anche due corsi di Rebecca Wirfs-Brock. Non ho ancora letto niente di suo, ma c’è ancora un po’ di tempo prima che scadano i termini della early registration.
I and Gabriele will present the Birthday Greetings Kata at the 7th XP Days Benelux in November. See you there if you can: it’s a very useful conference to attend.
Per il prossimo Agile Day ho proposto una breve sessione intitolata “La mia esperienza di coaching”. Da due anni e mezzo sono “coach” per il team Orione in Sourcesense, e mi piacerebbe parlare di quello che ho imparato in questo periodo. Il ruolo del coach è molto meno documentato rispetto al ruolo dello sviluppatore. L’unico libro specifico sull’argomento che conosco è quello di Rachel Davies che è uscito da poco. E’ un ruolo che poche persone conoscono e ancora meno persone ricoprono.
Per questo sarebbe bello se le persone che hanno questo ruolo o ambiscono ad averlo si confrontassero. Dunque chiedo: indipendentemente dal fatto che la mia sessione all’Agile Day venga approvata, che domande mi faresti? Di cosa ti piacerebbe che io parlassi? Qual è il tuo requisito per la mia sessione?
Ho il piacere di essere invitato al Bergamo XP User Group per raccontare il materiale del mio post sul codice parlante. La serata è questo giovedì 3 settembre, e il luogo è (pare) la sede di Softcare a Torre de’ Roveri.
I have this idea, of exploiting the kata concept for learning and teaching more than just the traditional areas of TDD and refactoring. I already put some of this in action in my university courses, where I encourage students to perform katas as a means to learn some technology; for instance Ruby on Rails.
Here is a collection of ideas for katas that stress the mastery of some technique or technology, rather than pure algorithmic or TDD/refactoring skill. All of these katas are to be performed in your favourite programming language, with your tools of choice.
[Web] Write a blog application in 30 minutes. For extra points:
[Web, DB] Write a web app that shows a table of data, with pagination. The data can be in a static, big table that simulates a database. For extra points:
[Web, DB] Write a standard CRUD. With validation. Writing to a real database.
[DDD, ATs, Fitnesse] Write the domain model for a Monopoly game (idea from Craig Larman’s book)
[Web, Gui, SVG, TDD] Plot a function. Begin with a fixed function, such as sin(x). Then make it so that the user can specify an arbitrary function. The rendering technology can be anything you like: for instance, ascii graphics, SVG, Gnuplot, jQuery + canvas tag, … Be sure to apply TDD. Try to develop a working solution without ever looking at it until the end! (Not that I recommend working like this in real work. This is an exercise; in real work I would frequently check that my application really works, expecially when the app is visual and/or I don’t master the technology.)
[Web, sockets, TCP] Write a tiny web server. It should serve files from its working directory (but should not allow the users to browse outside of its working directory!)
[Web, sockets, TCP] Write a chat server.
[Distributed programming] Write a messaging service with guaranteed delivery. Suppose you need to send a message to a remote service. You have a faulty communication channel, that can lose messages without warning. The remote service may also fail during the processing of the message, or before or after the processing of the message. Your system should guarantee that eventually the message will be delivered successfully. You should also guarantee that the message is not processed more than once on the receiving end. You must design the protocol that the two endpoint use. You decide the format of the messages.
[Distributed programming] Write a system that performs a distributed transaction. Simulate a database service and a payment service. Your system should accept a “Transaction” order, that simulates the fact that a User buys something. The system should let the user pay, and then record in the database that he successfully paid. Both the database service and the payment service fail 1/4th of the time. Your system should guarantee that it can never happen that the user has paid, but we don’t record this fact, or that the user is recorded to have paid when in fact they didn’t.
[Algorithmics] Anagram server: write a service that finds anagrams of a given word or phrase.
[Parsing] Basic interpreter: write an interpreter for a simple Basic language, such as the one in the Commodore 64 of yore.
[Parsing, DDD] Text adventure: write a game that plays a simple text adventure.
[Parsing, algorithmics] Format subsets of HTML. For instance, your input is an arbitrary HTML table; your output should be an ascii rendering of the table.
I’m looking for ways to make my coaching more effective. One important thing is to get people to find their solutions, rather than impose my views. Francesco once warned me that the coach does not ask questions in a Socratic way, for the purpose to get them to reach the solution that the coach has in mind. At the time I thought that would be rather difficult to do. Now I see that the Socratic dialogue smacks of manipulation and rethoric.
Not so long ago I asked a question that sounded like “do you think your choice was the best thing to do, or the easiest thing to do?” What a loaded question. It’s clear that my poor team member had no other choice than to agree that he chose the easy (and worse) thing. This is not the way I wanted the conversation to go. The question was not a very useful one; it was in fact a more embarassing way of chiding someone.
Not all questions need to be so false and rethoric. Last Monday we had a retrospective, and I asked questions like
Now this is a lot of questions. There are questions that I, as the person formally responsible for the team’s output, think I should be able to answer (the ones about the effort spent.) These questions explain the reasons why there should be a tracking activity at all.
Then there is the question to the team. How do we get to the point we can answer these questions? I’m not telling them “I propose we use this tool”. I’m asking for input. In fact, I’m asking them to tune their process so that it’s easy to answer this question. And I’m explaining why I’m asking them to spend effort on this. (In fact the information is *almost* all there; we just have to tune the process one little bit.)
As I was pondering how much you can achieve by just asking the right questions, I came across this beautiful little book, The Art Of Powerful Questions, which expands on the theme of honest, non-manipulative, insight-generating, mind-expanding questions. They are a precious tool for a coach, but indeed for anybody who wants to have constructive meetings and discussions.
I recently asked a few people to solve a little programming problem. In this problem, a number of towns are connected by one-way roads that have different distances. The programmer must write code that answers questions such as:
I reviewed three different solutions; they were all valid, reasonably well written. Two had proper unit tests, while the third was checked by prints in a "main". The authors tried hard to write a "good" solution. There were no long methods; all the logic was broken down in small methods. And yet, I was not pleased with the results.