Agile Articles

If you are using an Object-Oriented language (writing code in a DSL can change things a bit, it depends on the DSL) you should specify and verify the objects themselves and not how they are implemented.

If you consider yourself to be mature enough, to drop testing pay attention to the minefields you may be leaving behind.

Probably one the least understood aspects of the architect role is that the software development team **(which the architect is part of)** is itself a very important stakeholder. The architecture has to fulfill requirements from the system users, the project sponsors and developers.

Let me try to compile here a list with the books I've read in 2010. I'll also add a very quick review.

Aggregations and compositions are not just collaborations; they are part of the class internal design and should not be exposed; not even to tests.

When a project starts, I don’t care about having a sound and complete architecture. What I do care about is having a reasonable strategy for dealing with architecture decisions.

Using mocks and interactions as drivers for test cases you away from good specifications; always keep in mind that we should only bother about what, not how

I’m just too tired of how our industry just does not get the difference between Domain-Driven Design and Object-Orientation.