DEV Community: Michael Kantz

Cracking The Time Estimation

Michael Kantz — Fri, 20 Nov 2020 19:57:49 +0000

My take on how to master Time Estimation (TE) in a full stack software development.

My belief is that estimating time for a new feature could be harder mission than developing one.
Understanding that there is a timeline creation for different features is something that needs to take in a closer consideration, and as one gain more experience it's easier to be handled.

We all know how important is being accurate in time estimations:

Pricing determination.
Setting a feature (or a sprint) deadline.
Understanding the next milestone timeline

Personally looking on my journey, it took me quite a while, ~4 years, to find a platform that kept me satisfied and was able to support my tasks at a high level, I also believe that this system may support other developers concurring this issue.

In this article I will explain the system, and I'll demonstrate a live TE breakdown

The System

Separate the task for multiple (and very) small subtasks.
Each task should be time measured.
The minimum time estimating per subtask should be 0.5 day. Even if you think the subtask is less than hour, make it 0.5 day.
Always round the time 0.5 day up. (1.1 days will become 1.5 days).
Combine the subtasks time estimation.
Add 10% collateral time. (Do not round time here).
If you didn't consider tests - Add 20% time. (Do not round time here).
Add 20% time for personal QA.
Round Time up if needed.

Source: 8x8

Use-Case Demonstration

Lets take a simple full stack task and estimate its time

Task

Show a list of all users in the software.
Show maximum of 10 users and add pagination if needed.
Give the option to filter between different users (admin, premium, etc...).

Time Estimation

Subtasks separation:
- Creating API in the server side, including routes, controllers, interactors, database calls - 0.5 days.
- Creating a network call from client to server. Make sure it works properly - 0.3 days -> 0.5 days.
- Updating the server to get page number, filter phrase, and collect the relevant 10 users from DB + Update the client network call + Check the API - 0.6 days -> 1 days.
- Creating a new page in the client side and show all the users - 0.5 days.
- Adding filtering section and update calls - 0.5 days.
- Adding pagination section and update calls - 1-1.2 days -> 1.5 days.
Combining time estimations - 4.5 days.
Adding 10% collateral time - 4.9 days.
Adding tests 20% - 5.9 days.
Adding self QA 20% - 7.1 days.
Rounding - 7.5 days.

Yes - 7.5 days.
It may look a lot, but let me tell you this - After this TE you either deliver it sooner, either deliver with small/non QA rejections, and you'll have the confidence of delivering a good quality task on time.

Hope this will help someone out there :)
Thanks for reading ✌🏼

I've just enhanced performance from 21sec to 0.4sec with this one single change

Michael Kantz — Fri, 23 Oct 2020 06:55:32 +0000

This is the only thing that I've done to decrease my network call time dramatically.

TL;DR

SQL indexes.

OK, OK, I know what you think

Who doesn't know indexes are very important in all forms of SQL databases??
How come you ended up having a 21 seconds loader??

You're right

You're right, but it can be missed. I mean, we've missed it when we've started our MySQL architecture.
I always knew the role of indexes, but it's hard to notice the real importance of it when your SQL tables are small sized.

"Indexes are used to find rows with specific column values quickly. Without an index, MySQL must begin with the first row and then read through the entire table to find the relevant rows. The larger the table, the more this costs."
How MySQL Uses Indexes

So as a Time To Market Startup, we just forgot to add some really important indexes to our tables.

How things escalated

In the beginning, there weren't any performance issues.
But when the data and the DB scaled up, then things started to slow down.
One day we've noticed that one network call is taking 21 seconds (!).
That was the trigger to start digging into the code, trying to find performance issues.
Very quickly we found the time consuming source, and it was just one DB query.
We also noticed that this query is joining two large tables, and none of the fields in the query where clause were indexed.

The solution

I added a single column index for each one of those fields.

ALTER TABLE `table_name`
    ADD INDEX `fieldName` (`fieldName`);

WOW, the speed!
Suddenly the network call took 0.4 seconds. This change just blew our minds.

Conclusion

Do not underestimate the importance of SQL Indexes, and do not forget to add them to your SQL tables.
One day you may end up with the query time of 21 seconds. It's not fun and it's embarrassing.

Inherit function parameters in TS

Michael Kantz — Tue, 23 Jun 2020 06:54:52 +0000

This article is relevant for all typescript users.
Though, I haven't encountered this issue in Node.js yet..
If you want you can skip the background part, and jump straight to the code examples.

Motivation

Recently I faced a new challenge with typescript, in my react-redux app.

One of the fundamental principles of react-redux is separation of concerns.
As a result of this separation we might need to pass a lot of parameters to an action creator.
In addition, we might want to use this action creator from different components.

Until now everything sounds normal.

Now lets add Typescript.

Adding typescript to react-redux app, forces us to define every action creator function that we use in our component.
of-course some of the functions can be defined as Function type, but there are a lot of places that we need the full function signature.
This boilerplate can be frustrating sometimes, especially when the team is getting bigger, and more people are starting to touch the code.

Me and my teammate Lidor Levy looked for a solution for this problem and found resolution in this Github issue.

Typescript is giving the option to inherit the parameters of a function!!

This is how we do it

Define your function wherever you want

export const YOUR_FUNCTION_NAME = (
  param1: number,
  param2: Array<SOME_INTERFACE>,
  param3: string,
  param4: boolean
): YOUR_FUNCTION_TYPE => {
  // some logic, or even keep empty
}

In your function type definition

YOUR_FUNCTION_NAME: (
    ...YOUR_FUNCTION_NAME_Params: Parameters<
      typeof YOUR_FUNCTION_NAME
    >
) => YOUR_FUNCTION_TYPE

Don't forget to import your function definition.

Now, when you use the function, typescript will know the parameter types, and your IDE code-completion can help you regularly.
Enjoy!

Feature Toggle/Flag Design in React.js and Node.js

Michael Kantz — Thu, 14 May 2020 07:29:45 +0000

A use case for implementing FTDD in a Full Stack JS application

source of idea: DevOps Zone

FTDD (Feature/Flag toggle driven design) is a design pattern that helps teams to deliver new functionality to users rapidly but safely. Basically, it show/ hide features depends on the users role/ group/ whatever distinguishes the features set.

This pattern is the foundation basis of A/B testing.

For instance, with this ability, you may upload a feature to production in the Beginning of the development, hide it from anyone but you, keep working.

When you feel good enough about the feature, you may reveal it to the QA team only, and when they approve, you may reveal the feature to whoever else you want.

Motivation and struggling

Before we dive into the code, let me share with you what motivated me to write this article.

In Castor, the company I work for, we are aiming for a full CI/CD.

As a small seed stage startup, with large scale system, its not an easy task. So we are always trying to find new ways and approaches for reaching this goal.

Few months back, I participated a very interesting lecture delivered by Igal Steklov about FTDD.

That was my very first experience with this pattern, and I swore to myself that I’ll implement this in my company.

It occurred to me that this design may benefit all our departments for a more optimized deployment. From the Development by deploying with less fear of major bugs, to the Product and the QA, by checking their new features in the production environment, prior to exposing them to the customers, and of-course, the managers technological mind set.

When I started to dive deep in the community for implementation approaches, I found myself with too many question marks. I found a lot of built in packages, small or big, free or not, but with a learning curve and code adjustments.

In addition, I found many tutorials and documentation about the design algorithm, but without enough code and architecture references, especially not in my stack.

And in the end, I realized that it would be much faster to build it by myself, without third party packages.

That’s why I decided to build it on my own, and share with all of you what I came up with.

My simple ask for you guys, is to have your feedback on my architecture design and code, please feel more than welcome to share with me your inputs, as we will ever be in a learning curve :)

In this article I will show my solution for implementing it in my React app.

In addition, I will show the implementation in the server side (Node), and the DB structure.

CODE !!

The code order will be according to the development order, but you may jump wherever you want:

DB
Node
React

DB Structure

So the first thing I've done is creating my tables in the DB. i’m working with MySQL DB, and I created 3 relevant tables for this:

feature.sql

feature.sql. every new feature gets his name, ON/OFF toggle property, description and componentId for future use.

role.sql

role.sql. list of roles to give for a user or for a group of users

role_feature.sql

role_feature.sql. assign features to roles and set the’re toggle (ON/OFF)

With this 3 tables I can specify features for different users.

Example: lets say user ‘x’ is an enterprise (role id: 7) user.

We can see in role_feature table that this role has 2 features assigned to him, with specific properties- feature1 (feature id: 1), and feature2 (feature id: 2). Each feature has different toggle property (on field). One is on and the other is off.

So, eventually, user ‘x’ should see the feature1 feature but shouldn’t see feature2 feature.

Node

The server side is responsible of 2 things:

Arranging the list of features with there toggle properties, for the user.
Block off features controllers

Lets see how I managed to arrange those features:

The above code shows the arrangement of features for the user.

The method returns an array of features, some of the are on, some of them off.

This list will be sent to the client side, and will be used here, for the controller blocking.

These logic above shows the blockage of the controllers.

policies.js is responsible for every logic you want to add prior to the controller. For example, checking user authentication.

I added there a feature validation, isFeatureOpenPolicy, which checks if the feature that relates to the controller is on or off.

If it is on, continue regularly (next()).

If it is off, return forbidden response.

React (+ Redux)

You may play with the features and see the code of the client side, in this codesandbox:

In the client side of the application I used a very simple methodology by using HOC (Higher Order Component).

This methodology allowed me to toggle features very easily by adding HOC to component.

To make it work we create a component for every feature.

Its not must, and I will show how I toggled features that are not a component and/or in other component or service

First, we need to store the list of features that we got from the server.

I work with Redux state management, so the right place for me to store was the user reducer (that’s where I store all the initial user state)

OK, lets see the HOC:

This HOC is very simple:

It gets 2 arguments: WrappedComponent, which is the component that wrapped with the HOC, and featureComponentId, which is the feature id of the component.

It checks if this feature is on or off.

If it is on, it returns the WrappedComponent, like nothing happened.

If it is off, it returns nothing (<div/>), so the user wont see that component.

The HOC is connected to the user reducer

isFeatureOn:

Very similar to the server side, isFeatureOn method is checking whether the feature we’re looking for is on / off / doesn’t exist.

What interesting here is the imported redux store. By that, we don’t need to pass features to the method, only the relevant featureId, which is much easier.

We can default features argument with the user features from the user reducer, just like that: store.getState().user.features.

Now we can finally see a feature component:

The interesting stuff here is where we export the component.

That’s where we wrap our component with the HOC, and use FTDD!

Now for those of you who remember that I promised to show a non feature component case. here it is:

Very simple, just use the isFeatureOn method wherever you want.

The next and following article will be on how I created the admin panel for the toggles management

That was my way of using FTDD in my full stack app. I hope some off you out there would find it useful somehow.