9 Lessons I Learned by Creating Large Frontend Web Applications and Managing small team.

Update : Fixed some grammar errors — 17 Jan 2017

I have been writing JavaScript code from 2008 onwards. Its my primary Language. My single page applications journey started in Nov 2011 when I joined a company called Clickable.

Lesson 1 — Developer must help themselves first.

at Clickable, frontend team was provided with some WAR in order to run the local server. Server application was Tomcat driven. Server setup on local machine was a problematic for UI team(at least for me). I simply did not want to run MySQL or Java Code on my machine.

In Order to solve this problem, I setup node based http-server to serve static files. Almost empty index.html loads a remote script called load.js. This load.js is responsible for loading remaining assets (js/css/img) files from some other server. There was a if/else condition in that load.js. If script finds a secret variable called __DEVELOPER_CONFIG_ in LocalStorage then it starts loading assets from local static server from developer machine else it will continue to load assets from remote CDN server.

This small trick helps UI team to code FASTER. Because, we are not required to setup any backend server locally, Instead we were using some Staging Server for our development.

Using this, It was quite easy to fix production bugs. Previously, I was supposed to reproduce the same bug in my local environment which is quite a time-consuming activity.

With this new approach, I can open production website and All I need to add that secret localStorage variable. The moment I add that variable, localhost js/css/img files getting loaded on production site on my machine. I can easily make changes in my local files see changes.

Developer should fix their problems first before fixing somebody’s else problem.

Lesson 2 — Great Code/Product are not written in hurry.

After Clickable, I joined Unicommerce (a company acquired by Snapdeal). I designed their entire frontend from scratch. Best thing, they gave me initial 3 months on researching and designing the base architecture. If initial free months was not provided, an excellent product was almost impossible. I see many startups expect to deliver from the first day itself.

Many old CTO and almost every CEO do not understand the dynamic trends of frontend at all. JavaScript is more trendy than the fashion industry.

at Unicommerce, I observed that there are a lot of pages are basically forms, So I wrote a “framework to auto generate forms based on config”. It took me a good amount of time to wrote that internal framework and it was a very slow delivery in terms of pages. But after finishing the internal framework, we were able to produce new forms at very rapid speed.

Many technical people compromise quality on pressure, they fall into short term approach and it results in the Bad product. A product which you may be able to sell to few initial customer but you cannot scale later.

Always listen your inner voice and not pressure, may your product have best architecture. Ask sufficient time from CEO/CTO.

Lesson 3 — Continuous code refactor

Over the time, I realized that focusing on perfection at first instance is not going to help at all. You might end up at some architectural beautiful code which is useless.

Instead, I prefer, Continuos code refactor. In this approach, you never settled with any code, you keep improving it, even after production delivery.

IMHO, production delivery is just a delivery for the client. Your Code is still with you. It is part of your git repo. If you still have ideas to improve it, Do it.

Old code must not become a bottleneck to the new code.

Using continuous code refactor you can develop the best code.

Never focus on writing best code at first pass. Always Keep on improving your codebase. Even after your production release. Continuous code refactor will create best code.

Lesson 4 — Never commit tight deadlines.

I suffered a lot because of committing tight deadlines. It takes away your peace of mind, your sleep, and your happiness.

When we wake up in morning, we never think that we will die today because of a road accident on the way to the office. We do not think that way

Reason — We are optimistic.

Because we are optimistic, we tend to agree on tight deadlines but in real life, those deadlines are suffered by undiscovered problems and inter-team miscommunication.

Never agree on very tight deadlines.

Lesson 5 — Layered Architecture is fastest way to deliver

Remember, when REST came, It gave a nice split between client and server. There is no limit on splitting code into various layers. splitting brings 2 main benefits

• Scalability
• Parallel development (aka — FAST)

Recently, in one project, I sliced client side code into

• Functional UI
• Reusable Component
• Business logic

We published private packages over npm. Reusable components have their own repo. This approach is slightly time-consuming but helps a lot if you have multiple products and you want exactly similar UI behaviors.

Business Logic Layer should be kept separate from UI layer. Thanks to React, we now have an excellent method to “Externalise State Management”.

I kept various layers in code and that yield in faster code development. Any Layer or code can be replaced by another in later time.

Split the code in as many layer as possible. Always separate UI Layer with Business Layer.

Lesson 6— Strictness on Code quality using tools.

You can add or improve code quality by using tools by adding strictness in coding patterns.

In order to make a consistent code quality, I have used many tools, like eslint, various scripts at git pre-commit hook.

I kept git pre-commit hooks so that nobody should bypass them. if somebody bypasses them then there is a penalty for it.

Here are points for strictness.

• consistent indent, eslint rules.
• checking localisation was done or not.
• code-copy paste checker (intra-project duplicate code locator — )

Duplicate code locater was a great help. whenever I find a duplicate code between two files, it is a hint to improve the architecture. So, removing the code from both locations and transferring to more suitable code location is one simple solution.

Initially, I use to tell developer their mistakes in code-review. Later on, I started noting down points in code-review. When I find some mistake by any developer, I try to add some script or strictness in the workflow.

For example — I find that sometimes developer forget to add files in git. This mistake will be only caught when some other developer will do a git checkout and then the build break or run time error. When my developer made this mistake, I wrote a small script and added to pre-commit hook where it complains about such mistake.

Be Strict on your code Quality, Use tool to add strictness.

Lesson 7—Increase productivity of your team members.

I applied various tricks to generate more productivity from the team.

It is a misconception that productivity can be increased by increasing time or working more.

I have a new theory to increase productivity. The real Trick is — Remove obstacles in achieving goals.

There are many ways to remove obstacles to your developers.

1 — discuss/guide before assignment of the task.

If you guide your developer on what library or code to use, and how he can proceed then the developer is super productive.

For example — I assigned a task to add a full-screen button in our application. When you click that button, it makes the FullScreen.

When I assign this task developer, he may waste(or invest) time in understanding FullScreen API or browser compatibility issue. If he is ultra curious, he may waste (or invest) time in find “THE BEST” icon for the full-screen button. He might find the best icon but may then fails in adding the icon to the button.

I was in the above situation and I gave clear directions to proceed.

I gave following instructions.

• npm package for full-screen API which he HAS to use, without understanding inner details.
• font awesome icon path for the full screen icon to be used.
• He needs to set up a toggling behavior and that toggling will be managed by State/Store. So I showed him existing UI component where toggling of state variable was done for some other purpose so that he can follow exact approach.
• This button is only meant for making a full screen on whole page and full screen of any random DIV.

Defining path helps to cut wired imagination and endless googling of Developers. This results in productivity. Asking developer to do it fast will not help at all.

2. Tell developer, we can change design little bit, if needed.

design files come from product team who has no idea on what is the underlying architecture.

It so happens that design file asks to make a behavior X which is quite difficult to do it in current code base. But if Design team make a small change to X then it may become easy for the developer.

So, If you as a developer, think that slight change in definition will make you faster, go ahead, discuss and explain to design team.

I call it — negotiation between the design team and the UI team.

3. Early code reviews

A Developer worked for 4 days and ended up in a code which you do not approve? Waste of 4 days ? this is why early code feedback or code review is needed so that developer can be on right productive track.

4. Ask them again where they stuck.

Many times developer shy in sharing where they stuck. Sometimes they think that the problem on which they got stuck is genuine and will take time.

So you need to ask them if they stuck somewhere? You can solve their problem or you may ask them to move on.

5. Increase intra-team collaboration.

Our entire schooling and college is based on competition and individual efforts. In schools, collaboration is cheating. Almost many developers stuck in their school days. We never grew up in collaborative working.

You need to teach your developer that they can take help from other team members for The Assigned Task instead of struggling alone.

The company wants task to be finished. and Not task to be finished by 100% your own genuine efforts.

6. Spend Friday for internal tech discussion.

We started internal tech discussion in Friday second half. The response was quite good. these internal tech discussion and presentations energies developers.

This increases their productivity.

7. Tell developer about the scope.

When you ask an artist to draw your image, he can finish in 1 hour or 2 days. It depends on how much detailing is needed.

In 1 hour, he may draw a cartoon or simple sketch. In 2 days, he may draw an excellent image/picture with lots of detailing.

The same rule applies with Software development too. Each feature or sub feature or simple task need a discussion on quality or detailing.

For example, a developer can spend 2 minutes to add a File Icon on button or designer can spend 1 full day in designing a File icon because he thinks it is a cool idea to add a different icon.

Let’s define a quality index. from 0 to 5. 5 being the highest quality and 0 being the lowest quality workable solution.

So when you assign the task or may be subtask, Always tell about the quality index so that they can work accordingly.

I was able to achieve great productivity by simply telling the developer to how much quality I need for a particular task and speed of execution.

Productivity of Team can be increased by simple tricks and continuous engagement with team and understanding their problems.

Lesson 8— Fast feedback cycle with stack holders

In startups, even CEO/CTO do not have 100% crystal clear thought on what they want?

Many times, developer work for 10–15 days and their work get scrapped (fully or partially) because the “upper layer” is not satisfied the work.

There are many reasons, like miscommunication, misunderstanding etc. In most meetings, everybody talks about the product and its workflow “on the air”.

We faced the same problem and we came up with FAST feedback cycle approach. In this approach, we started per branch continuous deployments for the development branch.

auto deployment of developer branch helped the “upper layer” to view developer’s “incomplete” work to give an early feedback. This helped a lot to reduce time to push a feature in production.

Make a FAST feedback cycle so that developer can get early feedback from Product Managers or Owners.

Lesson 9— Separate UI from Business Logic

In startup word, we see frequent changes on pages and rearrangements. If you separate your UI logic and Business logic with a clean separation then it is quite easy to re-work or redesign pages later.

with React, Store+Flux pattern gives a clear cut separation between UI and Business logic.

At Unicommerce, One page of the product was very complex and It took me almost 1 month to code and make it bug-free. After 7 months, I was asked for a complete redesign of that page. This redesign can lead to new bugs.

When I developed that page, I made a separation between business logic and UI layer. It was quite easy to throw away old page design and write a new one. most of the code which was written for business logic was intact or minimal change. Only UI layer for that page was affected mostly.

while redesigning, there was no headache for bugs. Most bugs come from Business logic layer and we have not touched while redesigning the page.

Always think, the page you are creating will be replaced by some better page in 8–10 month and most of the business logic will remain same. So make the clear separation between UI and Business logic.

Contact Author —

Narendra Sisodiya (narendra@narendrasisodiya.com)