Md Imran Hasan Hira
"We human being, always find a solution, maybe not today, but if you really want to solve a problem, there’s always a way" – Ma Yun @ Stanford, 2013
Tag Archives: Software Development Process
Jan 24 2020

How do you make “Formal definition of things”

by Md Imran Hasan Hira

This note is a followup of previous note (Why formal definition of “things” is important).

I would like to categorise alignment situation into following buckets –

  1. Meetings/discussions
  2. Tasks in jira/trello/gitlab
  3. Application/Services/systems/pipelines
  4. etc.

Meetings/discussions

It’s quite easy. We need a board/paper to draw the topics being discussed. We draw some boxes to represent entities. We draw the options being argued upon. A simple table might look like below. The person co-ordinating the meeting/discussion can volunteer to do this –

| Options  | Pros | Cons | Winner |   |
|----------|------|------|--------|---|
| Option 1 | ...  | ..   |        |   |
| Option 2 | ..   | ...  |        |   |
|   ...    |      |      |        |   |

Also, whenever someone asks questions – “What do you mean by this?” , we might need to be patient enough to explain the intermediate parts. Personally I am more biased to visualised representation in a discussion.

Tasks in jira/trello/gitlab

It’s important to mention details in the task ticket. For example, when there is a multi step task, it helps a lot if all the steps are written upfront. This gives an early idea about which section of the system is the expected work for corresponding ticket. Any kind of context is helpful.

Instead of Just error, include where it happened, who faced it, basically a correct way to reproduce the error. If it’s not reproducible, at least mention where it happened, how it happened.

It takes time to write these details, but if we don’t write it, we might have to spend similar amount of time explaining the same thing over chat/face2face to the person working on it. Better to have it in the ticket.

Application/Services/systems/pipelines

Explaining a system out of nowhere isn’t easy. If the system is large/complex, that’s even harder. The idea is to take scientific approach – break it into pieces, flows, something like lego.

Here is one way to describe a system –
1. A bunch of blocks representing individual scripts/crons/modules/systems/storages…etc.
2. A set of entities representing data structures, the data that is being passed around
3. A set of lines, drawing connections among #1 and #2

There are many more ways to describe a system. We can write pages of documentation with system design diagrams. Coming up with workflows. Any such kind of representation helps people to discuss over a system. Those formal definition makes sure that both people are talking about the same piece. And that facilitates a healthy debate.

Categories: Software Engineering | No Comments »

Dec 10 2019

What is a “Formal definition of thing” and why it is important

by Md Imran Hasan Hira

This note is about alignment in term of concepts while discussing any topic.

Working in a multi-cultural company has it’s own benefit and tricky things. People come from different styles, different behaviours. One thing common among us is, we want to solve our customer’s problem. The most important part in a discussion is to be aligned on the topic that is being discussed. Being able to understand the terminologies that is being used in the discussion, really helps everyone.

It can happen that people arguing about the same thing for some time. Even if they don’t argue, but keep talking same about the same thing, that is more worse than just wasting the time. It creates miscommunication/confusion and people have to revisit the same issue after a few days or week. “Formal definition” is here to rescue.

What the heck is this “formal definition” ?

Any form of representation that can be seen/read by more than one person at the same time, can be considered as a formal definition.It can be in written form ( i.e. documentation, wiki, email etc.) or visualised form ( i.e. diagrams, flowchart… etc.). These persistent things helps people to look at together and thus tie on what each one is talking about.

  • What is the benefit of “formal definition”: It’s easy to follow up with defined terminologies. It’s kind of a quantisation. With formal definition, people can argue about the specific system, avoiding personal conflicts. Once things are quantised, we can compare among solutions, we can discard old/suboptimal stuff and explore better stuff.
  • Why waste time in explaining if we can just fix it in minutes: Well, we are developers/engineers. We can fix things quickly. But for other people or for a developer who doesn’t have the context, will spend more time in understanding what we just did in two minutes. Some situations it might take more time than making a formal definition.
  • Traps of not doing formal definition : There is a common scenario when people say “we are just building things”, “the thing is changing too much” or “it’s too early to write formal documentation”. All these phrases are valid, and we all know that premature documentation is costly to maintain. But we need to make sure we have at least high+mid level definitions from where people can start further documentation.
  • When is “formal definition” not required : Formal definition might not be required when people work alone and don’t have to explain things to others. In booking.com we don’t have much of these scenarios.

Dude, isn’t it what we call ‘documentation’ ?

It is close to documentation. It’s a marketing technique to sell similar product in new packets :p The reason why I avoided “documentation” because I think there is a different perspective. Just “documentation” isn’t helpful. Making sure audiences are aware of the documentation is also important. We need to tie terminologies with context. The part I want to emphasise is whenever we have discussions with another person, we might be thinking that the other person already knows this. But in reality it may not be. With ‘formal definition’ keeping in mind, explaining the terminologies upfront, we can improve the outcome. Or at least that’s how we keep us aligned 🙂

Categories: Software Engineering, Uncategorized | 1 Comment »

May 6 2015

Power of SCRUM

by Md Imran Hasan Hira

Few months ago I heard about SCRUM. It’s an iterative and incremental agile software development methodology for managing product development. In our office, we got four Certified SCRUM Master. I have been fortunate enough to have such kind of open environment in my current workplace. It’s not about how many of them we have, I am saying about the practices that we try to follow. Those CSM’s have already been started to implement SCRUM in their teams. They are doing great. They also gave a half day briefing to us about SCRUM processes, it’s roles, dos and donts etc.

Since then my team was continuously trying to implement SCRUM in our team. But we failed to incorporate upto the standards, rather what we got, is actually called ScrumBut by definition. We don’t mind. We are trying and we will get success. At least we know about the ScrumBut effect. Despite of all these, what amuses me most are –

1. Scrum  doesn’t support Micro Management! – It’s a myth. It’s not true. Scrum highly emphasize on Micro Management. Please continue to read the rest of this paragraph. One need to manage herself at micro level to get the best out of her. It’s kind of human nature. Scrum facilitates this. Scrum says all the micro management will solely be kept inside the team. This micro management data can not be visible to anyone outside of the team, even not to the Product Owner. Otherwise the idea behind self-micro-motivation will be failed.

2. Who will play the scrum cards ? And when ?

3. Our storypoint calibrations are not converging! What to do ?

4. Can we say “Difficulty Level” instead of story point ?

 

 

Wait, I’ll keep you guys updated later. I got the idea just now, I though to write something about it so I can remember it later. I promise, I’ll come back with the rest of my thoughts.

Categories: Software Engineering, Technology | No Comments »

Theme by Ali Han | Copyright 2025 Md Imran Hasan Hira | Powered by WordPress