Divide and Conquer » TDD

Accelerated Agile on Øresund Agile 2008

David — Wed, 11 Jun 2008 20:38:15 +0000

Yesterday I participated in the Accelerated Agile workshop at Øresund Agile 2008. It was attended by both developers and non-developers. Some parts of the workshop were common for the two groups and others were separate. Me and another developer actually did both TDD and pair programming! BestBrains, the company that organized the workshop, had prepared an Eclipse project in a Subversion repository, using Maven to build and with CruiseControl for automated build on commit. We pair programmed on an MS Windows machine but I tried on my Ubuntu Linux machine to and it worked fine.

Update Photos and comments from BestBrains.

Agile Architecture on Øresund Agile 2008

David — Mon, 09 Jun 2008 21:23:15 +0000

Today, on the first day of Øresund Agile 2008, I attended the Agile Architecture workshop held by Jim Coplien. He is a really great speaker! Some things that stuck in my head:

Don’t use TDD, it destroys architecture because it makes the programmer focus on individual methods, losing the bigger picture on the way
Don’t bother with unit tests, they make a bigger code base (equal amounts of application and unit test code is not unlikely), meaning more defects! The system tests should be enough
A subset of system tests that run in less than ten minutes should be used as a smoke test.
For interactive systems he was able to unify Agile software development, Model-View-Controller(-User) and Object Orientation.
MVC inventor Trygve Reenskaug was referred to a few times, and Jim told us that Trygve’s Data-Collaboration-Algorithm (DCA) was going to be the next big thing in software development! (This will be the seventh hit or so on a Google search for "Data-Collaboration-Algorithm". Maybe I should make a dedicated blog post about it.)
Domain Specific Languages (DSLs) are bad because they add new languages to learn when new people should work on a system, and it takes years to create a good language.
UML could be used to visualize a system, but should be generated from source code. Quote: "No hand should ever touch a UML diagram."

Food for thought, isn’t it?

The list above is unfortunately a little short on things that Jim advocates but I need some good sleep before the Accelerated Agile workshop tomorrow and my writing would not be half as good as hearing him saying it.

Holiday project!

David — Thu, 20 Dec 2007 12:09:59 +0000

The day before yesterday I registered a domain name for a new project and yesterday (while recovering from a really upset stomach) I wrote three A5 pages with a database model, sketchy requirements and possible features. All from very basic ones (“It shall be possible to register a new user account”) to some that are way into the future (“A user can customize font and color”). Maybe five of those requirements will make the cut for a first version of the site…

I’ve promised myself to write the project in Ruby on Rails (not a PHP hack like folkmun.se) and do my best to use TDD or maybe even BDD. If I go for BDD there’s an RSpec plugin for Ruby on Rails and I’ve found some interesting reading, for example Developing a Rails model using BDD and RSpec, Part 1.

So, will it fly? Evan Williams lists a number of questions for evaluation of product ideas:

Tractability: How difficult will it be to launch a worthwhile version 1.0?
Obviousness: Is it clear why people should use it?
Deepness: How much value can you ultimately deliver?
Wideness: How many people may ultimately use it?
Discoverability: How will people learn about your product?
Monetizability: How hard will it be to extract the money?
Personally Compelling: Do you really want it to exist in the world?