Gojko Adzic

Value objects are one of the basic building blocks of object domain driven design. The pattern makes manipulating objects very easy and is very easy to understand. Yet often I see teams with a strong preference to entities, making clean design harder to sustain and system much harder to write and more error-prone on the end. In most cases, this oversupply of entities comes from the fact that critical business data has to be persisted and by persisting the object we give it many traits of an entity. In my opinion, this is jumping to conclusions too quickly. I prefer values over entities because of all the management advantages that they have. Persistence is not an excuse to turn everything to entities. In this post, I’ll show you several tricks how you can persist object and still keep all the benefits of value objects. Continue Reading »

Sticky Minds published a review of Bridging the Communication Gap today.

As a tester, this book has been quite useful to me. It explains where the roles of other people, besides developers, fit in the agile process. I believe this is an important book and is a must-read for anyone contemplating or performing in agile development.

Read the full review at stickyminds.com

The most important take-away idea from CITCON Europe this year for me was probably building ‘save game’ functionality as an integral feature in software systems.

Antony Marcano talked about this, not as part of the official programme but over beers which is another example of how informal chatting at conferences is often more valuable than the schedule. He mentioned how it is common for games to automatically save the complete state at checkpoints. This allows us to easily go back to the last saved position and continue playing if our character gets killed for whatever reason. So if something really bad happens after 10 hours of playing, you don’t have to do it all over again.

Functionality similar to that could help immensely with exploratory testing in software. When we find an issue, we could easily go back to the last checkpoint and reproduce it and also use that same saved game later to check if the problem was fixed. This could also be used if a customer encounters a problem in production to make bug reports a lot more complete and reliable.

Implementing this feature is by no means a trivial task and might be nearly impossible to retrofit into existing systems. The reason why gaming companies can do it is that they consider saving as an integral feature of their systems from start. I have yet to try this but my gut feel is that if a system is built with this in mind, the actual overhead of doing it is minimal. Modern games have states as complicated as lots of enterprise systems, with tons of actors, their states and event information at any time. Yet they manage to load it up in a few seconds and continue from the saved state. By designing for that up front, ensuring that all actors can be persisted and loaded and that all state is easily extractable, we should be able to do the same in enterprise software as well.

I facilitated an openspace session on acceptance testing and collaboration between business people, developers and testers at CITCON Europe last week. We started with a list of five common reasons why I’ve seen teams fail with acceptance testing but added five more during the discussion, so here’s an expanded top 10 list:

Continue Reading »

Certification in software seems to be one of those hot topics that never die. This phoenix recently rose again in the form of Certified Scrum Developer announcements and discussions that followed on the agile developer skills mailing list. A recurring theme in the discussion is the mythical Joe the Developer, who is passionate about his work and needs the certificate to stand out from the crowd so that hiring managers can notice him easier. Continue Reading »