Is your code agile?

Yesterday I saw this on twitter:

Mirando solo el código: ¿Serías capaz de saber si fue construido ágilmente?

— Agustin Cuenca (@agustincnc) 28 de mayo de 2019

Basically, the poll says: “Looking only at the code: Would you be able to know if it’s agile?”, and it made me think about something I was doing at my previous company, at trivago.

I’m not going to tell you practices or things to follow to determine if what you have coded it’s agile or not, instead I’m going to describe an exercise where the whole team will check and generate their own conclusions about it.

It’s agile also about code?

Well, if it’s not, what are we doing? let me elaborate, a lot of organizations sustain their business model thanks to the technology they build right? and those organizations need to be able to inspect and adapt and react to change, as well, from a tech perspective we are moving forward to an era where the delivery teams have to right but also the responsibility to “build, ship and own” the product they build, where owning a product of course implies maintaining it, and maintaining the infrastructure that keeps them up and running.

With this paradigm in mind, what is agile software? I’m constantly asking this question to myself but also to the people I work with, and I guess in order to answer that question you should be able to answer the following questions as well:

• Is our code easy to change?
• Is our code highly coupled to other services?
• Do we have tests that can spot if there any change that is broken our logic?
• Are we controlling our tech debt? Are we are of our tech debt?
• Are we creating new dependencies?
• Is our code easy to read and understand?
• Did you ever try to explain to someone what you have coded and see if you struggled?
• Are we logging properly in case we have an exception? Are we able then to see somewhere those exception?
• etc…

There is one special question I also ask

• Is the code you are writing, being written for deletability? I got this question from this really great talk: The art of destroying software.

Note that the questions above raised from my mind just while I was writing, and at the end is the experience you and the team have that will trigger the questions to ask, note as well that they do not pretend anything else than generate conversations about the quality and reliability of the software we have built.

A Real example

This a real example I experienced, someone brought a new service that was connected to a specific database engine, so then this service could be used to pull data, I remember someone asking, “How easy would it be to change the database engine if we would need so?, of course, this question generated many conversations, the conversation ended up with the team changing the new service to make it database engine agnostic.

The exercise

Every week or every 2 weeks, this is up to the team, the team will propose something new the have build or a piece of code they want to check together, they will go to a room and all together they will start asking questions like the ones above.

What is the goal?

The goal of the session is to really come up with ideas and constructive feedback about how better we could have done the software we are checking, the idea is not to criticize the person to build it, the idea is that all together as a team we check and see what we could have done differently and what could make the software we are checking better.

Inviting others

It’s good if you invite someone that does not belong the same team to bring a different perspective, can be an architect or someone else, does not matter, the important thing is that brings a different perspective because the day to day of this other person will be in a different context.

And what happens after the activity?

I can think in 3 situations:

• Situation 1: we have found something that should be refactored/changed/fixed/added, so the team just goes ahead and perform all changes.
• Situation 2: there is something that should be refactored/changed/fixed/added, but is not on the team hands to do it, they have a dependency, so the team will have to start a conversation with whoever is behind the dependency.
• Situation 3: is not so important but it would add benefits, be careful with this one, the things that are important but not urgent are rarely prioritized, but I guess it will depend as well of the relationship you will have with your product owner/product manager or equivalent.