Definition of Things

As a science graduate, I’m always impressed by the beauty of nature…

Definition

I’m a science graduate, we learned to define things before starting to work on something.

Example:

In each element of R (Real numbers), if X is greater than 2, then the X square should be greater than 4.

Example: All mathematicians wear glasses.

What if at least one mathematician doesn’t wear glasses? It’s a contradiction to the definition, right? Then, let’s rephrase

Example: No mathematicians wear glasses.

Similarly, a mathematician can wear glasses. If we don’t define terminology or if we don’t clearly write statements, then we cannot rely on something at further steps. Definitions should be as simple as above ones, but well discussed. That’s how mankind can continue to build a future, relies on science.

Example: In Physics,

X defines the change in position, v defines the speed, and t defines the time. When v is constant, and the value of t increases, x increases as well. This is how we roughly calculate hours of traveling by a transportation vehicle between two points. If we couldn’t define this, we would not be able to go forward.

By nature, definitions give birth to other definitions. When you hold a math book, and look at the first page of any subject, you will find the simplest definition of something. Keep looking at next pages, you will see that definition is getting much more complex.

Using Definitions

When defining products

Imagine you are building an e-commerce platform. How would you start? I would probably start asking questions like below.

1. I should be able to sign in/up.
2. I should be able to list my products.
3. Someone should be able to purchase the product.
4. Product is delivered.

Let’s pick number 2, and define it.

A product has a name

It’s pretty straight forward, isn’t it? Now, I’ll ask myself several questions to be sure that this definition is enough or not.

A product must have a name

I think so. Otherwise, how people can search for it, and buy it? I couldn’t imagine a world where products don’t have a name.

A product has more than one names

It could be. In my opinion, this is going to confuse people. I’ll cross out this definition.

A product belongs to one seller

Is it possible? Imagine that the product is PS5. In my opinion, a product can be sold by many sellers.

A product belongs to no seller

Is it possible? Yes. If the product quota is over, then the product still exists, but doesn’t have a seller.

What happens when product capabilities aren’t defined?

Definitions are pretty simple, and if you have noticed, depending on 0,1,2. I’ll explain the story behind it later. It’s also known as zero-one-many or zero-one-infinite. When you define your object and its capabilities, the rest is technical implementation. When product capabilities aren’t defined, development team might apply their own opinions, which might not be 100% compatible with the business domain, which might result in architectural technical debt, which is also known as the most expensive technical debt.

When defining engineering metrics

By default, almost all tech companies use Jira, which is a perfect tool to manage structured data and workflows. Jira is also known as slow, and strangely reacting app by users’ interaction. Showing a piece of data for a task takes several seconds to be loaded, or showing content of a different task after several seconds, or returns server error. This is exactly the output of when you don’t define things. Anyway, let’s get back to defining engineering metrics.

In tech, everyone is working to ease the job of software development team, and build a sustainable pace in an agile environment. For example, we break down stories into actionable tasks.

A task can be coded

Ideally, by one person, and takes X hours.

A coded task goes to review

Ideally, by one person, and takes Y hours after coding.

A coded task goes to staging

Ideally, stays there Z hours after review.

A coded task goes to production

Ideally, goes to production in T hours after testing on staging.

What happens when engineering metrics aren’t defined?

You’ll not be able to identify any problem in the cycle time of a task.

1. If it takes more than 1.5 day to code a task, it means that it was a huge task, which needs to be re-assessed. A coding task should be done less than 1.5 day.
2. If it takes 1 day to review a code, find out why it takes longer, what causes this. Ideally, a code review should not take longer than half an hour, or in other words, a code review should be done on about 300 lines of changes.
3. If it takes more than 1 day to go to staging, find out what’s wrong with the delivery pipeline. It should be maximum a few clicks, let’s say a few hours.
4. If it takes 2 days to go live, find out why it takes time? Found a bug at staging? If yes, how often we face bugs at this stage?, Pipeline was broken? Not tested yet, so many items waiting to be tested at staging? Do we need a dedicated/additional testing resource in our workflow?
5. Person A is asking for a raise after a year. But there’s no performance measurement, or goals are not set.
6. Upper management wants to know which team is killer, highly productive, so they will assign more budget. But there’s no data.
7. Person B is performing more than other people in the team, which might result in burning. Person A needs to be cool down.
8. Person C is performing less than other people in the team, which might feel upset. Person C needs additional help to get to the same level with other people in the team.

To summarize, definition is a must-have in every step of building software products and other areas of life. When definitions are missing, how to make it better? Unfortunately, most people still rely on waterfall techniques at work, and it makes the process more difficult. Customers don’t care how do you work, what do you do behind the scene. They are not interested in if you write comprehensive documents, or doing extensive research before, or have a status update in a weekly meeting. They want to see that their dreams come true, and managers would like to see things are getting done. Bringing more agility to workspace can increase the communication, collaboration, and help to make better outputs, thus valuable outcomes. When you can’t make your customers happy, someone else will.