Browsed by
Tag: opinion

Revolutionising Agile With Head-Stand-Ups

Revolutionising Agile With Head-Stand-Ups

So here’s a true story. I work with a normal sized team as per Agile/Scrum guidelines, about 8 people. We have our usual stand-ups every day, at about 10:30 in the morning. As a general rule, people have to join this meeting. Everyone speaks following the Scrum rules, just what is required: What I did, what I am going to do today and if I am blocked. And that’s it. Yet, our discussions diverge, others jump in to help whenever someone mentions why they are blocked, suggesting how it can be solved. It is helpful, it speeds us up in ways because it avoids need for a one-on-one meetings later, and team generally returns feeling the meeting was fruitful.

Yet, it results in our meetings getting extended, we have our stand-ups almost 20, at times 30 minutes long. This is something that has been on our mind for quite some time now, as a general rule, the stand-up should not be longer than 10 minutes, that is why we ‘stand up’, so we realise the time being spent physically, with a minor discomfort and that drives us to close the meeting sooner.

This is when I read about the “plank meetings”. Excited, I suggested to the team and everyone agreed agreed that this could help us reduce the time we spend in stand-up considerably, while giving everyone a healthy boost. We agreed to put it in practice. Now, for those who do not know what plank meetings are here are couple links explaining them. We decided we would start the next Monday, with the next sprint. But destiny seemed to have some different plans. During my yoga session on Sunday morning, it dawned on me that there could be something much more effective than this. It was the Shirshasana that gave me this idea! Shirshasana is an asana in yoga, where you stand on your head and keep the body and legs straight up, like a plank but upside down. This! This could be the thing we need to keep the timings in check.

Now Shirshasana, as a yoga form, has many, many benefits of its own. It is known to direct the blood flow to head and eyes, relieving stress, improving focus, and digestion. But the quality we are looking for most was that it makes us temporarily uncomfortable! Perfect! On the planned day, we started with this instead. There was just one simple rule:

  • No one speaks without first assuming Shirshasana form.

Now you see, there is no rule about when to speak, or who speaks. That is because on the first day we observed that entering this form and exiting from it is not easy, we needed help from others. Meaning it was intuitive that anyone who wanted to speak would have to wait for their turn and to get help from others to speak! This caused a revolution amongst us, we realised that this one change alone has brought us many benefits. Here are our observations:

  • First and foremost, meetings became short.
  • Meetings became fun.
  • Our habits changed to be more healthy. It is not advisable to consume food before performing Shirshasana, and hence we automatically started following better timings for breakfast.
  • Our team found that we were more interactive throughout the day. Somehow activity of helping each-other daily, and needing help from others was turning into a team-building exercise of sort. We may just have saved our company thousands of dollars.
  • More people around us took interest in this seemingly odd practice of standups and that created awareness about health and yoga across the organisation.

We as a team have never been better! Who needs stand-ups when ‘head-stand-ups’ are so rocking!

PS: Reading between the lines is an important skill, for others there are warnings in F12/console.

Software development hygiene: Why do we brush our teeth?

Software development hygiene: Why do we brush our teeth?

Yes, why do ‘you’ brush your teeth?
Is it guaranteed that if we brush our teeth twice a day, floss once a day, gargle with an antiseptic, we will never have toothache or bad breath? And if we did not brush teeth say, for a week, would we be guaranteed to have toothache? For a few months, may be yes, we might, might just have to get some treatment done for a few teeth. So the question, why do we brush our teeth, daily?

And how did we start brushing the teeth? Were we born with a brush in one hand, toothpaste in other and with an utter, inexplicable desire to brush teeth every morning after waking up from sleep and before going back to bed? Assuming that no one would remember how they themselves were born, all parents at least will agree with me, that this is certainly not the case. So the question, how did we start brushing our teeth daily?

And now the question you might have in your mind: “What’s the point?”
Recently, a person on our team raised this question(s): Why do we have unit tests. I have been writing good code, good enough that QAs do not find any critical issues, nor has anything ever severely broken in production because of my changes, why should I write tests? If I could think of all scenarios to unit tests, why do we have dedicated QAs on our team? Why should I pass my code through a static code quality analysis tool? All these processes are slowing us down. I have worked without all these processes in the past and that has worked quite well, why do I need this overhead of processes?

I agree, I hate processes.
Yet we need to appreciate the importance of processes and acknowledge where they are required. Come to think of it, why does a process exist? Can we not work without processes and the overheads thereof? Short answer: No, we cannot. Long answer: We can, given that everyone on the team understands the core reasoning for the existence of the process being bypassed and takes the responsibility of upholding the goal of this process without strict adherence to the process itself.

Well, how did I start brushing my teeth daily? My mother would tell me: till I was a couple years old, she used to brush my teeth. When I became three, she taught me how to do it and would ask me to show how clean my teeth were. She would ask me: “Are they shining when you look in the mirror?”, I would go and check and say “Yes”. When I became four, she would just remind me to brush, and I think at five I had finally started brushing my teeth daily, without having to show her how clean they were. I do not believe your story would be very different than this. It took years of practice and perseverance of our parents to eventually get us to brush our teeth daily so that finally we could get rid of the ‘overhead of process’.

Yes, many processes can be chucked as long as the goal is achieved; but are we, as a team, responsible enough to make sure they are achieved every single time? Let us say we are, but are we ready to carry the burden of remembering every single code smell, every single potential bug and be mindful of it while writing code? Is that even humanly possible? If the answer to that question is yes, sure go ahead and chuck the quality analysis tools, unit tests, pull requests and code reviews; we don’t need them. But if the answer is no, wait till it becomes yes!
We can certainly bypass processes and get an apparent speed-up, but chucking a process before we are ready is sure to give us pain in the tooth (and in a few more places)!

Please Give It A REST!

Please Give It A REST!

A regular stressful day in the life of a software developer. I was communicating a module we needed to quickly put together. The team was not exactly new. We had a backend guy, and a front-end guy. Interface was designed and agreed upon, we needed to make it quick, we just defined the resources and said that we need the ‘standard CRUD operations done via REST’ on them. And we got down to work.

When everyone reverted that they were done, we sat down to quickly integrate and test, but the front-end and the backend refused to talk, we got the 404, not found. Well, it should have been simple, we had very clear instructions; the resource names and that they were REST.

Or so I thought. REST, the standard, arguably most popular of the web service protocols out there should have made it very easy for the backend and frontend to talk to each-other. But no. Turns out that there are (still) huge misconceptions around REST; there are so many among us who believe that abominations like ‘getCustomer’ and ‘createCustomer’ (yeah, you guessed it write, the HTTP method was ‘GET’ for this one too) are ‘resources’ and are valid REST.

Oh please, give it a rest.

Not the first time have I encountered this, and it would not be the last either. I thought we were over this. But no, I had fallen for it, assuming that common knowledge is common. It is not.
Well, these ‘divergents’ among us, are not totally wrong in assuming what they write is REST, it could probably be referred to as a form of REST. They are on HTTP at least, someone could certainly fit the level-0 in Richardson Maturity Model to it. But this type of API modelling does not really help integrations, has no standard understanding nor predictable way of implementation and yet we tend to stick with it.

The level-2 is where we need to be with REST, as a basic understanding and expectation from APIs: with Verbs and Resources. It conveys a very clear message as what to expect
from the interface. While Level-3 or HATEOAS with a hypermedia client, or if you are so security conscious making the URLs opaque, would be a dream implementation but for a team struggling with ‘resources’ it feels far-fetched. So level-2 it is.

I have seen that there seem to be a whole lot of people with this kind of confusion around, entire applications built with just GET calls for everything, even for inter-service and frontend-backend communication. I wonder at times what could have caused this confusion, and popularity of Spring’s for REST implementation comes to mind time and again. It is also an observation I have made over time, those who think ‘resources’ also tend to be Jersey (JAX-RS) users at some point in time and the other class seems to be comprised largely of Spring users for their REST implementation.

Probably it makes sense, Jersey as a framework leaves little room for the idea of method-wise resource names, you tend to define the resource at the top of the class (or resource!) and HTTP methods are just marked below. Although you have the option of marking each of your method differently with an additional @Path annotation, the trend is not seen as much and people are forced to think in terms of resources and verbs. Whereas the Spring’s implementation of REST is basically the Spring MVS’s controllers and request handling used to simulate how a REST service will work. Although Spring 4 introduced the @RestController it did little to enforce the resource behaviour as did @GetMapping, @PostMapping and the siblings defined in Spring boot; the method implementations are still standard (or implied) @RequestMapping from Spring MVC and coming from there, people may tend to think a need to override the handling and define the java method name in the path, for some reason. Well, I would not know for sure but this seems like a logical explanation for the trend observed.

Now how do we convey to everyone that they do not need to define different paths and let the HTTP verbs do their job is a challenge. This post is just an attempt.