In his talk at the Agile2008, Bob Martin proposed an addition to the Agile Manifesto:

Craftsmanship over Crap.

Although most of us can identify with that statement, it’s probably not easy to sell the idea put that way. But now he rephrased it to:

Craftsmanship over Execution.

I confess the first time a thought about software development being a craft was in a Joel Spolsky’s article disagreeing with the use of this term. In the post he suggests creating software is more related to design than craftsmanship, but he reinforces the idea of software not being simple execution.

After working with a lot of different people, it’s easy to distinguish who think about software as being craftsmanship or mere execution. And undoubtedly the best developers and consequently the best software always come from the first category. They care about what they’re producing, are passionate about it and never stop learning. They want to become master craftsmen and know it depends only on his own attitude.

The question is: should the Agile manifesto include that statement? Personally I don’t believe so. The “Individual and Interaction over processes and tools” part already implies that. Focus more in processes and you’ll end up caring more about execution. Value people and the craftsmanship aspect of building software will become natural.

1. Is the easiest and cheapest way to invest in training

To run a coding dojo people don’t need much more than a computer and a projector. Paying for the pizza and some beers for the end of the meetings is not expensive either, and is surely welcome. But if the company is really cool, some dojos can take place during work time to get more developers involved. Note that none of those items take lots of money nor is too complicated. The only things needed are some engaged developers and good sense of the company to invest in their professionals.

2. Stimulates social and self-organization skills

Many developers have some hard time when talking in public, exposing their ideas or collaborate with other people. Others have problems to self-organize, work in a team or even lead. When does a company invest on those kind of skills of a developer? Rarely. The dojo is a great start for those people, and even who doesn’t have any of these difficulties will have a chance to exercise their skills and explore points which may need some improvement.

3. Is good publicity for the company

If the company took the first step and the developers are already comfortable running a dojo, why not open the doors for the public? The company name will become associated with the agile principles behind the the coding dojo and developers won’t have to leave the company to network. Better, if everything goes well the company won’t have to publish ads to get new developers since the potential candidates will be part of the company’s routine.

4. Helps developers to be active in the community

Discussing the techniques applied in the dojos can be a good incentive for some developers to participate more in the software development community. It can also be a first step help some open source projects, publish articles or participate in conferences.

5. Breaks the routine

Code something different from the daily projects, using other languages, tools and techniques, with other people and in a more relaxed environment may be very stimulating.

So, do you need more reasons?

Carlos Brando release the first book on RoR 2.1. More information and download here.

Three simple steps to measure velocity in a software project:

• Estimate your requirements using a size metric.
• Agree on the concept of done.
• Define a timebox size.

Then we just need the formula:

Velocity = Points done / Timebox

Just to clarify:

• Integration test: modules of the system are tested together, as a group.
• Integration build: modifications made by developers are consolidated through a full build.

Although the integration build may include running integration tests, they’re are clearly two separate problems.

Sometimes in a project:

• People are treated as mere “resources”, being part of the project only to work on predefined activities and nothing else.
• The managers want to be sure that everyone is doing exactly what they think it’s the best, and forget that people can have good ideas.
• People prefer to work on tasks defined by someone else because they don’t want to be responsible for their work.

Having self managed teams is a good way to change this reality but to make people capable of managing their own work is a tricky task. With that in mind, the principles I consider most important to achieve it are:

1) Shared vision

The first step to build a self managed team is sharing the project goals. A good start is to define SMART (Specific, Measurable, Achiveable, Realistic, Timed) goals and to make sure that the goals make sense for the whole team.

2) Commitment

Once the vision is clear, the next step is to build the commitment. When the members of the team agree to work to achieve the defined goals, the perception of the their actions changes and they start thinking about the best solutions to get closer to the goals.

3) Trust

If people trust each other, a bond is created and there’s no reason to control other people’s work. On the contrary, people start helping each other.

4) Support

Every self managed team needs an “interface” with the rest of the organization. That’s why one or more people should be able to help when the solution to a problem depends on external factors. These people should be considered part of the team since they share the vision, are committed and trust the other members of the team.

Conclusion

Although these principles look very simple, they’re forgotten all the time. And they’re usually replaced by micromanagement, which on top of wasting people’s time frequently becomes the biggest cause of stress to the team.

Then it’s time to try the Way of Testivus:

• If you write code, write tests.
• Don’t get stuck on unit testing dogma.
• Embrace unit testing karma.
• Think of code and test as one.
• The test is more important than the unit.
• The best time to test is when the code is fresh.
• Tests not run waste away.
• An imperfect test today is better than a perfect test someday.
• An ugly test is better than no test.
• Sometimes, the test justifies the means.
• Only fools use no tools.
• Good tests fail.

If you haven’t tried Ruby on Rails because was too busy developing your J2EE applications, now you have no more excuses! It’s possible (and surprisingly simple) to deploy a RoR application in your favorite J2EE server just by following these few steps:

1) Install JRuby on Rails

Get JRuby and install the Ruby on Rails gem:

gem install rails --include-dependencies --no-rdoc --no-ri

2) Create a simple test application

Run the following commands to set up your new application:

rails test_app
cd test_app

You’ll have to edit the first line of the created scripts (’script‘ directory) to use JRuby:

#!/usr/bin/env jruby

And at this point you’re ready to test your application:

script/server

Open http://localhost:3000 and check if your application is running as it should.

Now let’s create some functionality. First, edit your config/database.yml file, defining your development and production database as it follows. Note that we don’t need the test database and we can use the same database for both development and production for the scope of this example:

adapter: mysql
database: test_app
user: root
password: xxx
host: localhost

Create a scaffold:

script/generate scaffold Dog name:string
rake db:drop:all
rake db:create:all
rake db:migrate

At this point you’re already able to point your browser to http://localhost:3000/dogs and start playing with with your database.

3) Install the JDBC adapter and change your application

In order to deploy as a Java web application, you’ll have to replace the database adapter by a JDBC one. To achieve this, first you need a new gem:

gem install activerecord-jdbc-adapter --no-rdoc --no-ri

You also need to copy your mysql driver (JAR file) to your JRUBY_HOME/lib directory and edit your database.yml once more:

adapter: jdbc
driver: com.mysql.jdbc.Driver
url: jdbc:mysql://localhost/test_app
username: root
password: xxx
host: localhost

Restart your server and, since we just changed its configuration, everything should be still working exactly as before.

4) Install Goldspike and create your WAR file

In your application directory, install the plugin:

script/plugin install http://jruby-extras.rubyforge.org/svn/trunk/rails-integration/plugins/goldspike

To include your database driver in the generated archive, you have a few options (Maven is one of them), but for now let’s just copy it to the ‘WEB-INF/lib’ directory of the application:

mkdir WEB-INF/lib
cp $JRUBY_HOME/lib/mysql-connector-java-5.0.5-bin.jar WEB-INF/lib

You also need to edit the app/controllers/application.rb file and include the line:

protect_from_forgery :secret => '6dc47d156f8f3724e4634c37bc0f9f94'

Finally, to create your WAR file, run:

rake war:standalone:create

Deploy the generated file in your favorite J2EE server like Tomcat or WebLogic.

Conclusion

The integration between Ruby on Rails and Java is easier than most people would expect, and it may become a new option to develop your next web application. That may be also a great motivation to learn JRuby and start taking advantage of its integration with existing Java code.

After taking the Asshole Test, now is time to know about the Asshole Driven Development and other “alternative” methodologies

PS: see all the comments about the Scott Berkun’s post. There’s a lot of new acronyms there too.

Reading about several things they don’t teach you in school, one that sounded me very important is how to deal with failure:

In school, kid’s learn that “failure” is a negative term.
However, it is nothing of the sort. There has never been a
single successful person who hasn’t failed numerous times on
their journey to success.

In fact, the most successful people in life are those who
have failed the most.

Edison ‘failed’ more than ten thousand times before he
succeeded in creating the light bulb. As said by Thomas
Edison: “I have not failed 10,000 times. I have
successfully found 10,000 ways that will not work.”

In software development, failure is mostly seem as a negative term too. Obviously we don’t want to deliver software with bugs to the end users, but I believe that most of the bugs could be avoided if the developers change their view about failure.

When you start doing Test-Driven Development, one of the first lessons you learn is how failures are useful during the development process. Every test that fails is an allied to understand a little more about the problem you’re trying to solve. Why don’t they tell this in Software Engineering class? I really don’t know.