In the book ‘automated delivery’ there is this controversial statement:

Thus one of the more controversial statements in Continuous Delivery is that you can’t do continuous integration and use branches.

However, with new systems like DVCS branching is incredibly easy so no branching? What is actually meant here?

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler)) The bible on continuous delivery

During a session on supporting multiple versions of our software application we got into the argument if we should create multiple copies of our system by using branches. Keeping multiple copies (in different branches) of your software is of course a totally different statement then just ‘use branching’.

The book gives the answer to that option op using copies for versioning already, but think about the consequences of that approach. For example if you have to fix a bug in one of the versions you probably need to copy that fix over to the other version branch, which in time might divert to a different direction altogether. Divert, because different versions of software always divert as you are supporting different clients.

Now, think about what would happen if you just have one application. Supporting multiple versions. The same software supports all the different clients that it needs to support. Your software might have different entry points.

- It can support multiple currencies.
- It can support multiple languages.
- It can supports multiple different frontends, that itself can have different pages (ticketinsurance yes/no, discounts yes/no etcetera, etcetera)
- It can support different workflows, wizards.
The software also supports different backends, like when you support a service for maintaining shopping baskets, over time you might have to integrate with different financial backends. How? By branching on abstraction.
That way, the software is highly configurable.

This would not have been possible if we would have different versioning branches for all of the possible config-switches / configurations to support all connectionted other software components.

We have one ‘pallet’ of options that is configurable. Having configurable software, switchable by settings makes integration flexible.

In the ever changing life cycle of software we can not maintain software in different versioning branches because bug-fixing would have to be done multiple times for each versioning branch.

So yes indeed: to support multiple versions that indeed will mean we have to support different versions and have multiple of the same kind of classes in the same codebranch indeed.
However, at some point in time, we discontinue support for an older version, and then we remove it again. From the same codebase.

Note that this has always been the case for the mid office software we are working on within my current company Travix. Last months we switched and deleted support for connecting to several hotelproviders, carproviders or a previous flight provider. All with the same mid office servicelayer code. We have done this before.

So when you read a statement from a book about ‘do not use branches’, know that it is about ‘do not use branching for versioning’ instead of ‘CI branches’. Please do use branches! Use them as much as you want, but just not for versioning! No branching means no branches for different versions of your software.

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler)) The book is packed with information on getting your software on to continuous delivery.

Hi all,

Two software video’s. One from ‘Uncle bob’ on what he would expect from you when he was your CTO. The other is a recent posted video on refactoring with Resharper and NCrunch. Have fun!

SCNA 2012: Robert Martin – The Reasonable Expectations of Your CTO from 8th Light on Vimeo.

And another Practical refactoring with resharper and Ncrunc

I do not have a lot of blogposts on the subject of fighting technical debt. Maybe because as a developer it is such a clear thing that needs to be done that it is hard to imagine why -not- to do it.

Old code that is not used, or code that is too hard to grok simply gets in the way and we need to clean up thoroughly to pave the way ahead. We want to keep momentum to maintain our speed.

As william puts it refactoring is not a cost:

My advice to managers (..) Reward and encourage deleting of unused code; fight for and insist that programmers be given time to refactor and otherwise eliminate unused code, and don’t account for time spent doing so in the same way you do the creation of code.

My advice to programmers: Delete unused code at *every* opportunity and scale (function, class, file, project, organization); don’t compare the effort to do so to writing code; work at all times to have your software feature-set reflect its actual, operational use.

Or to put it in my own words, developers can be compared to Knights:

Sour Knights flee surrender or choose other fights. Brave Knights refactor and tame the beast!

Continue the fight, young warrior. And do not get distracted.

We assume the reader knows that NHibernate is one of the best ORM’s build for .NET.

Implicit transactions are discouraged

Generally “implicit transactions are discouraged” (ref: http://www.google.nl/search?hl=nl&q=implicit+transactions+are+discouraged)

However, webservices can be build by simply opening up an NHibernate session whenever a new webCall arrives at the server. Than simply handle all data manipulation and closing the NHibernate session when the webCall ends. THis is usually done when the context for the service is going to be setup during inputfilters and outputfilters, or if you work with WCF using things like custom Behaviors.

The problem with this is that it makes reads from the database as well as updates to the database kind of uncontrollable. If you use implicit transactions you really never know for sure what object updates cause SQL update statements to the database. This of course is not a good thing.

When using an ORM like NHibernate we really should be using explicit transactions, even for database read actions.

We can describe this wish using the following example user stories:

To be able to support NHibernate second level cache,
all read actions should be written
with explicit transactions.

or:

To better control what is updated in the database
we need to prevent NHibernate properties registered as ‘dirty’
by the NHibernate framework therefore we
need to use explicit transactions when writing,
updating or reading from the database

Example of the difference

So what is this all about really? Well here is an example of the difference for a reading action:

This first piece of code that assumes an NHibernate session is already opened thus considered an implicit transaction

public List<Airport> FinAirportLocationList(string nameCriterium, ... )
{
  //get current session
  ISession session = HaddockSession.Current.CurrentSession;
  //construct query
  string queryString = @"select l from Location l inner join fetch l.Names as names where names.Text      
like :searchcriteria";
  IQuery query = session.CreateQuery(queryString);
  query.SetString("searchcriteria", nameCriterium + "%");
  query.SetCacheable(true);
  IList<Location> list = query.List<Location>();
  return list;
}

Here is an example that reads data with an explicit transaction:

public   IList<Location> GetAllLocations()
{
  IList<Location> locationList;
  using (ISession session = HaddockSession.SessionFactory.OpenNewSession())           
  {                
     using (ITransaction transaction = SessionFactory.BeginTransaction())
     {
       IQuery query = session.CreateQuery("select l from Location l inner join fetch l.Names as names");
       locationList = query.List<Location>();
       transaction.Commit();  // always commit: needed for 2nd level cache
     }
   }
 
   return  locationList;
}

Note that this example wiil have to enable access to the Nhibernate sessionfactory. This Sessionfactory will need to be controlled per application.

Benefits of explicit transactions are:

• It drives developers into awareness when database access is happening. This is especially important to ; make roles explicit.
• of course also important for awareness of performance of your application
• Explicit transactions for read access enables the possibility to use NHibernate second level cache.
• Creates awareness what is necessary to load during a transaction. This is because when a session is closed, lazy-loaded properties/lists will not be loaded automatically anymore by NHibernate. Note the small ‘fetch’ statement in the above example: it pre-fetches the names collection of Locations.
• It makes clear what your root-aggregates are and how you want to load these.

And for the sake of more detailed information: A good example how to configure 2nd level cache for NHibernate can be found on gitshah.com.

Conclusion: Do not fall for the trap of using implicit transactions with NHibernate. When you start with NHibernate as your ORM, start with explicit transactions. See if you can use the Unit of Work pattern for NHibernate if you need it for user stories that need to update multiple objects during one webcall.

Hey all, before I show an example of an informative workspace, first another quote from the book, The Art of Agile Development

An informative workspace broadcasts information into the room. When people take a break, they will sometimes wander over and stare at the information surrounding them. Sometimes, that brief zoneout will result in an aha moment of discovery.

An informative workspace also allows people to sense the state of the project just by walking into the room. It conveys status information without interrupting team members and helps improve stakeholder trust

Right. So, here’s an example of such a workplace:

Let us quickly go around this room. Suppose you were working here? You will like the windows! being able to immediately look outside to let the creative mind wander is an asset not every developer is given. Embrace that as long as it lasts!

Of course the scrum board and story board look to be placed wrong as the Product Owner (PO) might need to be close to the story board while the Devs should be closer to the scrumboard. But this apparent mismatch actually is a good thing: people will move around the room and notice discussions at boards outside of their designated roles. This is important to prevent silo’s from (re)ocurring.

If we enter the room via the door, we see the information radiate at us from all walls immediately. To the left we can see the long wall that has the story board for all upcoming sprints:

The story board.

The story board contains all the user stories we could think of to complete the product. Sized by the team in t-shirt sizes (small, medium, large) to give the global overview.

To the immediate left of the door when entering we see a graph that shows the burndown chart plus something we really emphasize these days: our code coverage. It is reaching 80%, a pretty good figure.

Burndown and code coverage graph.

If you have designs, maybe made or drawn by a business analyst or graphic designer don’t let it rot in an electronic document stored in an unknown place of your company wiki, but print it all out and be sure to display it:

Screenshots of initial designs, possible prototype screens.

Of course we also have our planning board or taskboard Aka…

We definately need a drawing board too:

Drawing board, great for drawing designs.

Lastbut not least, we always update our weekly events on our weekboard. Crucial because it shows what team members might not be in during the week, for whatever reason, or raises attention to important upcoming events like trainings, the sprint review and retrospective or planned team events.

In short: the informative workspace shows all team members what is being worked on, raises important focus points for the team and helps the team to collaborate to achieve.

Questions? Let me know how your team configured your teamroom! What are we missing here?

Melle is currently in the role if Scrum Master at Travix International in the Netherlands. He is a proficient team lead and has more than fifteen years experience in the industry in different roles from software engineer, unit manager, test coordinator, team lead, coach of software engineers, to scrum master. If you want to know more, get in touch.

Currently reading a book on Agile Development: ;The Art of Agile Development from O’Reilly by James Shore and Shane Warden.

In Chapter II of the book there is a full description on doing proper eXtreme Programming (in short XP, that’s why the capitalization is there).

An excerpt:

It’s clear that the book is packed with common sense. if you do not take the time to deliver quality, you will never get it either.

Eat healthy foods! Seems I am doing that already!

Must say that in our scrum team we also adhere to those kind of standards. We do see other teams bragging about their weekly overtime, even going along in weekends, but we also see the results. Some teams take on a ‘whatever it takes’ mentality. Developers in those teams can be sick after a few weeks of death marches. So why bother? Just stay fresh and focused during normal work hours and your team will be very productive.

More on this in the book, I highly recommend it: The Art of Agile Development

What are your thoughts on this?

Restaurant Swoel is erg klein, en daarom ook heel gezellig. Op bovenstaande foto zie je me in m’n ‘freedom of speech’ T-shirt genieten van een vispasteitje, onderdeel van het 3 gangen dagmenu dat ik koos. Dit voorafje is een gerecht op zichzelf. Twee in bladerdeeg gehulde gehakte vispastei, heerlijk mediterraan gekruid, wat een smaak! Mijn eega koos voor de pasteitjes met geitenkaas, zoete uitjes, dadels, amandelen en saffraan. Aangezien we de gerechten verkeerd om geserveerd kregen kan ik vertellen dat ook die heerlijk is. Vooral de zuur zoete smaken in de salade er omheen maken het helemaal af.

Onze tweede gang bestond uit een pastagerecht, helaas of expres niet geheel al dente, en voor mij een Tajine (stoofpotje) van lam met kaneel en rozijnen, volkoren cous cous en seizoensgroenten, in dit jaargetijde een bijpassende zomerse salade. Beide gerechten hebben volgens de vriendelijke bediening van Swoel hun oorsprong in Turkije, en vielen beiden zeer in de smaak door een juist gebruik van garnituur. We bestelden hier ons tweede biertje. Alfa en Hoegaarden Wit zijn merken die bij Swoel worden geserveerd.

De keuken van Swoel lijkt klein omdat chefkok Peter van der Wal achter de bar druk aan het koken is voor alle gasten. Voor de gasten die op de lange bank aan de lange kant van de zaak zitten biedt dit een fraai schouwspel. De gasten aan de andere kant moeten het doen met te harde stoelen en elke gast zie je dan ook grijpen naar de kussentjes op de bank om het soms lange wachten wat te veraangenamen. Tip: zorg dat u zit met kussentjes in de rug, voordat u hier te laat achter komt.

We rondden af met werkelijk fenomenale desserts: een Oosterse hangop met abrikozen en amandelen, een zeer lichtfijne smaak. Het dagdessert was een Italiaanse eucalypta ijs; roomboterzacht, licht gezoet en een frisse limoensmaak.

Ons eindoordeel: geweldige gerechten, volgende keer zorgen voor betere stoel dan zeker iets om terug te komen!

Just as with software engineering, you have to use the right tools when doing the hardware side of live! First we plan and measure where to put the holes in the wall with a water level / plumb rule…

Than it’s time to make some real noise! Playing with a hammer drill… To create some sturdy shelves in the room of my son Theun!

Theun can help in his room of course…

The train passes by outside…

Great when the framework is stable. This is where we can build upon!

Cleaning up after use.. Always put some grease on the drill to prevent rust!

Inbetween demo, review the work. We’re almost done.

Want to have all shelves aligned the same! Not relative but absolute positioning!

This is good, client/product owner wants to use what is built already and understands the purpose.

Looks great.

Dank papa!

What motivates us really?

The question is posed by Daniel Pink in his book:

Drive: The Surprising Truth About What Motivates Us

If you have been working in business for some time already then your gut reaction might be ‘Money!’. Although this is true for simple tasks the same is not so true anymore for complex tasks where creative thoughts are necessary to complete the job.

Watch this movie that was posted after the book was published. It is a summary of what is there in more detail in the book itself:

http://www.youtube.com/watch?v=u6XAPnuFjJc&sns=em

So, we have to aim for the following keywords to get the best out of us, wether it is our work or the olympics…

Mastery
Autonomy
Purpose