Estimation Peril: How To Estimate Software Projects Effectively(or How Not To Lie)

road-1668916_960_720

Consider, you are a rockstar engineer and you are given a task by your favorite person, your project manager, to show some new fields in the dashboard.

As usual, you are asked to estimate it as soon as possible. You think that well, seems like a quickie and you are tempted to estimate it a day. But you, being burnt before, decided to look at the fields that are to be added carefully. These fields are for analytics. You think, ok, let’s make it 2 days then. But being more cautious, you dig deeper and find that those analytics are not even being tracked on the app.

Now to complete the story, you’ll have to track the analytics, send them to the server, make the backend accept those and store them, show these on the dashboard, write tests etc….

What seemed a simple task is now a 1-2 week thing. Very hard to estimate. And your manager was expecting a response like, “would be done by end of day”.

What is the problem with estimates?

The main problem with an estimate is that the “estimate” gets translated into commitment. And when you miss a commitment, you breed distrust.

Most estimations are poor because we don’t know what they are for. They are uncertain. A problem that seemed simple to you on the whiteboard, turned out not to be so simple. There were non-functional requirements, codebase friction, some unfortunate bugs etc. We deal with uncertainty.

There is a rule in software engineering that everything takes 3X more time than you think it should, and this holds true even when you know this and take it into account!

Estimates can go the other way too, that is when you overestimate. This is as dangerous as underestimating.

What should an estimate look like?

An estimate should have 3 characteristics :

  1. Honest (Hardest)
  2. Accurate
  3. Precise

1. Honest : 

You have to be able to communicate bad news when the news is bad. And when the continuous outrage of your managers and stakeholders is on your face, you need to be able to continue and assert that the news is bad.

Honesty is important as you breed trust. You are not eliminating disappointment, rage and people getting mad, but you will eliminate distrust.

2. Accurate :

You are given a task and you estimate it to take somewhere between now to the end of the universe. That’s definitely accurate, it’ll be done within that time.

We won’t breed distrust, but we definitely will breed something else.

Which brings us to the 3rd characteristic.

3. Precise : 

An estimate should have just the right amount of precision.

What is the most honest estimation that you can make? I don’t know!

This is as honest as it can get. You really don’t know. But this estimation is neither accurate not precise.

But when we try to make precise estimates, we must note that we are assuming that everything goes right. We get the right breakfast, traffic doesn’t suck, your co-worker is having a good day, no meetings, no hidden requirements, no non-functional complexities etc.

Estimating by work break down

The most common way to estimate a complex task is to break it down into smaller tasks, into sub-tasks. And then those sub-tasks into sub-sub-tasks and so on until each task in hand is manageable and ideally not more than 4 hours of work.

Imagine this forming a tree, with executable tasks at the bottom as leaves. You just estimate the leaves and it all adds up.

This approach works, but there are 2 problems :

  1. We missed the integration cost
  2. We missed some tasks

There is a fundamental truth to work break down structure estimates:

The only way to estimate using work break down chart accurately, to know what are the exact sub-tasks, is to implement the feature!

What to expect from an estimate?

Estimates are uncertain. There is no guarantee that your estimate will work itself out. And that’s OK. It’s your manager’s job to manage that risk. We are not asking them to do something outside of their job.

The problem arises when you make a commitment. If you make a commitment, you must make it. Be ready to move heaven and earth to make it. But if you are not in a position to make a commitment, then don’t make one.

Because he’s going to set up a whole bunch of dominos based on that commitment, and if you fail to deliver, everything fails.

Some interesting links :

https://medium.com/swlh/your-app-is-an-onion-why-software-projects-spiral-out-of-control-bb9247d9bdbd

Uncle Bob on Estimates: https://www.youtube.com/watch?v=eisuQefYw_o

Happy Estimating!

That’s all, folks!

Advertisements

Clean Code Chapter 1&2: Clean Code & Meaningful names

I have started reading the book Clean Code by Robert C. Martin, which is considered to be a industry standard for writing maintainable and elegant code.

Because this book is such a heavy read, and each chapter is full of content and a knowledge bank in itself, for personal reference I’ve decided to summarise each chapter in a set of blog posts.

Chapter 1 : Clean Code

This was more like chapter 0. Author describes what is clean code and cost of maintaining it. How clean code is directly related to team productivity and what makes clean code clean.

It contains views on clean code by many of industries best known people like Bjarne Stroustrup, Michael Feathers etc.

One of my favourite definitions form the book covers it best :

I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well – Bjarne Stroustrup

Chapter 2 : Meaningful Names

Names are everywhere in software. We name our variables, our functions, our arguments, classes, and packages. Because we do it so much, we should do it well.

1. Use intention revealing names : 

The name of a variable, function, or class, should answer all the big questions. It should tell you why it exists, what it does, and how it is used.

int d; // time elapsed

Here d reveals nothing. A better name would be

int timeElapsedSinceCreation;

2. Avoid Disinformation :
Programmers must avoid leaving false clues that obscure the meaning of code. We should avoid words whose entrenched meanings vary from our intended meaning.
ex

int accountsList;

Should only be named so if it is a actually a list data structure that’s used to store the accounts. Not an array or set.

3. Make meaningful distinctions
Entities named different, should be different, mean different.

If we have classes called

ProductInfo

or

ProductData

, you have made the names different without making them mean anything different. Info and Data are indistinct noise that doesn’t differentiates what they actually mean.

4. Use pronounceable names

Makes communicating about the code easy.
ex.

long genydhms;

is not a good name.

long generationTimestamp;

is a better choice

5. Use searchable names
Avoid single letter variables and constants as they are difficult to search.

6. Avoid Encodings

Hungarian notations, member prefixes, interface and implementations should be avoided.

It just adds another burden to remember the encoding format being used.

7. Avoid mental mappings
Readers shouldn’t have to mentally translate your names into other names they already know.
ex.

int r;

Where

r

is lower cased url with host name removed adds to much requires too much mental juggling and mapping when working with the code.

A better name would be,

int urlWithoutHostName;

8. Class Names
Classes and objects should have noun or noun phrase names like Customer, WikiPage, Account, and AddressParser.
Avoid words like Manager, Processor, Data, or Info in the of a class. A class name should not be a verb.

9. Method Names
Methods should have verb or verb phrase names like postPayment, deletePage, or save.

10. Don’t be cute

If names are too clever, they will be memorable only to people who share the
author’s sense of humor, and only as long as these people remember the joke.

Don’t tell little culture-dependent jokes like eatMyShorts() to mean abort().

11. Pick one work per concept
Pick one word for one abstract concept and stick with it.

It’s confusing to have a controller and a manager and a driver in the same
code base. What is the essential difference between a DeviceManager and a ProtocolController?

11. Use solution domain names
It’s OK and preferable to use names from computer science and programming domains.
ex.
In transctionObserver

the word observer means a great deal to person who knows the observer pattern.

12. Use problem domain name
The code that has more to do with problem domain concepts should have names drawn from the problem domain.
ex..

int mriRecord

In a healthcare app will give a great deal of context than just

int record

.

13. Add meaningful context
Enclose names in well named functions, classes, namespaces, etc.
ex.

String state;

In a class called FiniteStateMachine will mean different that in a class called Address.

14. Don’t Add Gratuitous Context
In an imaginary application called “Gas Station Deluxe,” it is a bad idea to prefix every class with GSD.
Frankly, you are working against your tools. You type G and press the completion
key and are rewarded with a mile-long list of every class in the system. Is that
wise? Why make it hard for the IDE to help you?

 

This was part one of a 16 part series on the book Clean Code by Robert C. Martin, where each post covers a gist of a single chapter.

Thanks!

Philosophy Behind The Offensive Programming

football-1149952_640

Recently I was listening to a podcast and there was this really smart guy Piwai talking about something that instantly captivated by attention. That was the coining of the term Offensive Programming.

What is offensive programming?

Well, you can find the literature on  Wikipedia and also I am not the best person to explain that. So check that out please. But fundamentally, offensive programming refers to a style of programming that is exact opposite of the more famous counter-part the defensive programming.

Defensive programming refers to coding style which adheres to dealing gracefully with conditions that should not happen.

Offensive programming on the other hand, well just tells you to let the app crash. Don’t try to recover, don’t try to handle the exception, just log the stack trace and crash.

The reason behind this is that in reality the problem can be much bigger and somewhere else in the code, as a side effect of you are getting this error in first place. This forces you to fix the problem at the source and will possibly result in a healthier code base.

When it makes sense to be offensive?

This was my exact concern while I was listening to this podcast. Thankfully, Piwai answered that himself. I also, talked about it with a really smart guy at the office and he also made the same remarks.

So at Square (the company who do payments and author libraries) what they do is, they stick to a defensive style of programming  for interfaces and parts of code that deals with external interfaces and/or user interactions. Basically, something that is not in your control.

But, for the internal interfaces, where the classes you wrote are going to interact with each other, you don’t have to be that paranoid about that. This is where he (Piwai) said you should switch to the offensive approach. You have full control over the classes you wrote, and the expected behaviour is in your control. If it fails to do so, it’s better to just crash and let the problem to be fixed at the source.

That is the exact reason he said at Square, they make very liberal use of assertions in the code. Assertions are not forgiving at all.

Example Please!

I would attempt to point to examples here, one that the Piwai himself talked in very brief and the one that I’ve encountered myself where I thought it made sense.

In this example, say we are handling credit card objects. There is no point to internally validate the credit card object every time you deal with it.

As soon as we get a credit card, we decorate it with a validated credit card. That’s all the defensiveness we had to offer.

Now internally, we go offensive and throw exceptions or assertions every time we encounter an invalidate credit card object.

The code below is not perfect, but can give you an idea.

class ValidatedCreditCard extends CreditCard{

    CreditCard creditCard;
    
    ValidatedCreditCard(CreditCard creditCard){
      // Handling external user interactions defensively.
      try{
        creditCard.validate();
      }
      catch (CreditCardValidationError e) {
        // Handle and try to fix the error
        tryToFixTheCardDetails();
      }
      this.creditCard = creditCard;
    }
}

public static void main(String[] args){

    CreditCard c  = getCreditCardFromUser();
    c = ValidatedCreditCard(c);
    // Time to go offensive
    // ...
    if (c == null){
      throw new CardInvalidException();
    }
}

Another example I can think of is a much simpler one and more relatable.
Suppose, we have a utility function that uploads a file to s3.
It would make sense to follow offensive programming style and just throw an exception if somehow they file or the key reaching the function is None.

def upload_file_to_s3(file, key):
    if file is None or key is None:
        raise TypeError

 

Few more tips from the podcast

1. How to start with offensive programming?

Best way is to start putting assertions in the code, where you think is suitable. Yeah, we’ll experience more crashes and that’s awesome!

Because now we know that we have a problem.

2.  We feel more confident about the code base:

We just know that, this method doesn’t try to handle nulls, thus I can confidently say that it was not null or it would’ve crashed.

3. Do incremental roll outs.

When you ship a code, roll it out like for 1% of users. We’ll have a ton of crash reports, and that’s good! I mean not for the 1% users but they are taking one for the team!

4. Crash at preventable errors and recover from expect-able errors :

Preventable errors are invalid arguments, NPEs etc. Go offensive on these.

Expectable errors are like resource depletion, invalid user inputs etc.

Try to recover from these.

 

Overall, it was nice to listen to a guy who works at a company like Square talking about how they use offensive programming for a healthier code base. And if Square is doing something, we all can learn something from that!

The Alchemist : Reading Experience

918fZ1wVZgL.jpg

Reading The Alchemist was like getting up at dawn and seeing the sun rise, while the whole world slept.

The Alchemist doesn’t teach you anything, but you can learn a million things from it.

“Lead will play its role until the world has no further need for the lead, and then the lead will have to turn itself into gold.”

My 6th book of the year was The Alchemist by Paulo Coelho. This was a rather famous book that I finally decided to read and was not at all disappointed.

The book narrates the journey of a boy and his quest for his treasure. On the way he meets the alchemist, who helps him find the treasures he didn’t even know existed.

The boy who was a shepherd, used to travel across lands with his sheep.

He remembered that because he had the jacket, he could withstand the cold night of the desert. He knew that we have to be prepared to withstand the change, and suddenly he was grateful for the weight and warmth of the jacket, even in the scorching day time heat.

The above quote perfectly captures the importance of embracing change and suffering now for the sake of later good.

The boy had a dream of finding treasure near pyramids of the Egypt. And he later finds that this was what his personal legend was.

After all, it is the possibility of dream come true that makes life interesting.

On his way, he meets an old king. The old king who teaches the boy what one’s personal legend is.

Personal legend is what you have always wanted to accomplish. Everyone, when they are young knows what their personal legend is. At that point in their life, everything is clear and everything is possible.

The soul of the world is nourished by people’s happiness. And also by unhappiness, envy and jealousy. To realise one’s personal legend is a person’s only real obligation.

“And here I am between my flock and my treasure” – the boy thought.

And while following our personal legend, we have to choose between something we are accustomed to and something we wanted to have.

The secret to happiness is to see all the marvels of the world and never to forget the journey of your own personal legend.

But that journey is full of decisions and choices that one has to make.

Making a decision was only a beginning of things.

When someone makes a decision, he is really diving into a strong current that will carry him to places he had never dreamed of when he first made the decision.

The Alchemist’s greatest discovery was not the elixir of life or the philosopher’s stone. But, they discovered that the purification of metal had led to a purification of themselves.

A purification that made them understand the ultimate truth of life. One’s personal legend.

Journey of one’s personal legend is full of omens. Omens that represent the resonance of energy with the soul of world. And the universe communicates the omens by using the universal language.

But how does one immerse himself in his personal legend?

“Listen to your heart, it came from the soul of the world and one day it’ll return to it”.

Power of silence is what allows us to hear the world speak the universal language. The book describes

The boy was sitting in desert in silence with only sound of the laventer (east wind) hitting his face. He was learning to understand the desert.

An average person speaks 10,000 words per day. May be cut that into half. or some times don’t speak at all.

It’s all about improving himself. That’s is the reason why one’s personal legend was carved by the soul of the world. It’s the journey that one follows in his personal legend. that is the real treasure. Everything else is secondary.

This is why the alchemy exists. So that everyone will search for their treasures, find it and then want to be better than their former life.

“Lead will play its role until the world has no further need for the lead, and then the lead will have to turn itself into gold.”

And finally, towards end of the book, the boy finds his treasure right where he started.. The place where first he had the dream. When he asked the soul of the world why it didn’t tell him that before, it said,

Because it was fun! This is what your personal legend was. You had to follow it.

Conclusion : 

The most prominent lesson I learned from The Alchemist  was that one has to find and follow his personal legend. Even if the goal is right in front of them. Because in the end, it is the one’s journey on his personal legend that reveals the true treasures of life to him.

A must read for everyone!

Skiffle : Android App To Discover, Search and Explore Music – The Making

This is just a log of contemplate on the challenges and learning I encountered while creating Skiffle : Discover tracks, albums and artists.

Skiffle on GitHub

Skiffle was designed with one simple motive , provide fastest way to search for music powered by the best source available. It uses Spotify API as backend.

How this log is structured?

The log is structured under headings. Each heading represents a certain facet of project or technology. Under each heading is the list of challenges or solution.

Overview : 

Skiffle is an app to provide the fastest way to search for music. Powered by Spotify API, it is a great little tool to keep track of your favourite artists and tracks.

While creating it I had some clear motives:

  1. Use RxJava
  2. Use dependency Injection
  3. Use Http Request Caching
  4. Follow Clean Architecture

Thus at some places it might seem as if the implementation is an overkill, but that was the main motivation behind creating  the app.

Software Engineering Items : 

  1. Reading Software Engineering Stackexchange  : It is a goldmine of knowledge for SE related principles like architecture and coding styles.
  2. Start creating your app from the data layer : Model the data layer first. Build your app from the data layer and then upwards. It would have saved me a ton of extra work.
  3. Very important to keep the naming conventions and interface consistent :
    It can get confusing other wise. Keep the naming strategy of everything consistent.
    Ex. AlbumList module, getAlbumList() as getter.
  4. Making sure that the names follow a conceptual model :
    ex. A recycler view showing a list of AlbumItem s.
    It uses a callback for click named onAlbumItemClicked().
    Though this is a small thing but gives a great peace of mind when coding and you expect the interface methods to be likle this.
  5. Local Variables are a bliss :
    Use variables in the smallest scope possible.
    This will allow garbage collector to reclaim objects faster and will save your from debugging nightmares.
  6. Think about all the edge cases before you go coding :
    Once you start coding your brain tricks you into being lazy.
  7. Writing effective git commit message :
    Here you can find useful list of emojis for commit messages
    https://gist.github.com/jhermann/0206ed09b3bbcefdd691

RxJava Items : 

As they say,

With a hammer in hand, everything looks like a nail.

Same goes when you use RxJava. You want to use it for everything. It’s more fun that way! 😀

1. Using for background thread offloading : 

The most trivial use of RxJava is to have it manage threads for you. I have used it extensively to offload tasks to background threads.

2. Observable.fromCallable() for simple usages : 

I wanted to use RxJava to offload the database reading and writing to a separate thread. For this I have used Observable.fromCallable. According to the docs it said that .create() is for advanced usage. That’s why I went with this approach.

3. RxJava 2.xx doesn’t allow nulls to be stream elements : 

You can’t emit null elements in the stream. I used pseudo objects that represent null elements as a work around.

4. Never leave the onError() method empty :

Always put a log statement in the onError method to get the error message

OkHttp Caching Items :

1. Using interceptors : 

Logging interceptors are handy to monitor requests your app is making.

Caching interceptors allows adding request caching.

Dependency Injection Items :

1. Inject or not to inject, that is the question?

For instance I decided not to inject Picasso instance as it already manages a singleton internally.

2. Using Qualifiers to inject multiple instances of same type : 

I used @Qualifiers to inject multiple instances of same type. An use case I encountered was to inject two WebService clients.

3. Regarding Singleton Scope : 

I found somewhere that dont use the @Singleton scope. Instead of that create your own custom application scope. It gives the scoping more clarity.

MVP Items :

1. Be ready for a class explosion : 

One thing i noticed is that, when you try to implement MVP or clean architecture in general, what you get is a class explosion. This is necessarily not a bad thing. Heard this in a fragmented podcast clean architecture episode.

2. How to deal with MVP when using view pager?

I ended up using fragments as views. Activity interacts with the presenter and just updates the fragments as required. And also receives callbacks from fragment events and forwards them to presenter. 

Android Items :

1. Use of onAttach() in fragments : 

It is used to check the state of the container. Example when fragment is using the activity as the container then onAttach() can be used to set the communicator listener.

2. Preventing multiple button clicks when favourite button was clicked for a track :

I disabled it when clicked instantly, then on onNext() and onCompleted() enabled it.

3. Creating SearchView is real pain in some part of anatomy  :

I found that support search view and search view are having different behaviours. I ended up using support search view as it was more like it.
In future, and production apps, best approach i think would be to create your own custom search view that caters to all your needs.

4. Search suggestions using provider :

Use fully qualified name if using packages. Which you should be using, for search activity names that you specify in android manifest.

5. Issue with showing data in fragments when it arrives asynchronously : 

Some times fragment was not finished inflating the views and binding when data was finished with loading. To deal with this I used callbacks and loading data completely before I set view pager.
When fragments finished inflating, they give a callback to the activity to give them the data. And as we have already loaded the data, it should not be a problem.

6. Use StringBuilder instead of String when strings have to be altered  : 

String is immutable and each alteration creates new objects.

7. The monster called as state management :

Managing life cycle of fragments and activities is real pain in the ass. They are very non deterministic.
I, almost towards the completion of the development found crashes due to state issues.
To test apps, enable the don’t keep activities option in development options.

Conclusion :

Main motivation was to create something useful and learn in the process.

Best way to learn alchemy is to go and try – “The Alchemist”

In fact, follows for learning anything.

You can find the project on GitHub :

Skiffle on GitHub

Mastery By Robert Greene : Reading Experience

Mastery_Cover

“The problem with all students, he said, is that they inevitably stop somewhere. They hear an idea and they hold on to it until it becomes dead; they want to flatter themselves that they know the truth. But true Zen never stops, never congeals into such truths. That is why everyone must constantly be pushed to the abyss, starting over and feeling their utter worthlessness as a student. Without suffering and doubts, the mind will come to rest on clichés and stay there, until the spirit dies as well. Not even enlightenment is enough. You must continually start over and challenge yourself.”

Mastery is a book that takes a deep dive into the so-called “superpowers” of masters in various fields and connects it directly to the pillars of mastery like grit, dedication, patience, creativity and intuition.

It contains life studies of legends like Vinci, Darwin, Faraday etc to contemporary legends like Carlo Rodriguez, Santiago Calatrava, Paul Graham etc. And time, again and again, it stands upon elusive pillars like grit, creativity, patience, etc which drives one towards mastery, not just god gifted super powers.

The book condemns that people are not willing to do what it really takes to become masters in their fields and label it as something that can be only achieved by born geniuses.

It starts with covering the importance of the apprenticeship phase. The phase that constitutes the beginning of everyone’s career, even of true masters like Faraday, who did the apprenticeship  at a scientist’s lab for 7 years before going on his own to make history.

During the apprenticeship,  one should focus immensely on learning the vocabulary of the field in depth with patience. Then experiment with his/her own tastes.

Next, comes the creative active phase, where after learning the tools of the trade and becoming proficient in important skills, masters experiment. They mix and match things, blend various fields and concepts and bubble up ideas.

The book presents various strategies for the creative active phase like:

  1. The Authentic voice: Learn the vocabulary of the field first.
  2.  The Fact of Great Yield: Look for anomalies with profound ramifications.
  3. Mechanical Intelligence: Key to building anything right is repetition.
  4. Natural Powers: Enjoy the laborious process.
  5. The Open Field : Create space for yourself in crowded space.
  6. The Evolutionary Hijack: Creativity and adaptability are inseparable.
  7. The Dimensional Thinking: Feel the breathing element in your field.

My favorite quote from this segment of the book was:

Languages evolve in haphazard manner, influenced by the influx of new groups into a society and stages by passage of time. They are not mathematical formulas but living, evolving organism.

Next, the author puts the spotlight on the vitality of “the ultimate reality“. Life is interconnected and it all started with a single cell two billion years ago.

Mastering a field can not be done in isolation with other things. Any field that we are working on, it has been shaped by events, minds that have worked on it and time. It is simply not right to build artificial walls around subjects and study them in isolation.

Strategies suggested in the book to get the rational intuitive feel:

  1.  Connect to Your Environment: Become a consummate observer.
  2. Play to Your Strengths: Have a supreme focus on your strengths.
  3. Transform Yourself Through Practice: Get the fingertip feel.
  4. Internalize the Details: Have the patience to give attention to even the most minute details
  5. Widen Your Vision: Get the global perspective.
  6. Submit to the Other: Loose the sense of superiority when learning from someone.
  7. Synthesize all forms of knowledge

My favorite quote from this part was:

Things push and pull into each other and breathe together, and are one.

To conclude, Mastery is a great book to help people shape their mind in a way that knows what to expect and what it takes to travel on the path of mastery. And that mastery is not a destination but a lifelong journey. One should maintain a beginners mind as they grow old like zen masters.

When you read a great book at the right time, it can only go in the category of Supremely Fucking Awesome.

Thanks!

 

 

 

E-Summit ’17 IIT Bombay — Experience

E-Summit is the flagship entrepreneurship event organized by IITB. The two-day annual summit promises to be an amazing meeting ground for industry experts, business leaders, investors and entrepreneurs and of course, students, many of whom are aspiring entrepreneurs.

I attended this event in its 2017 edition and had mixed feelings on how the whole thing turned out holistically. There were some good parts and some not so good parts, but as a whole the event was worth attending.

There were many small talks spread on a 2 day course. Obviously, you can not attend all the talks, you have to select few of them according to the schedule and feasibility.

I personally realized that choose a topic that you are not familiar with as talks are pretty basic and don’t go to great depths.

Following are the talks and keynotes that I attended.

Day 1 :

  1. Keynote by Raj Jaswa :

First event of day 1 was keynote by Raj Jaswa. Most prominent thing he said in a nutshell was areas in which one should look for business opportunities.

Some being,

  1. Cloning and localisation
  2. Long tail business
  3. Adapt an existing business model to a new sector.

2. Digital Marketing :

This talk was presented by founder of E2M, a digital media company. I found this talk too basic aa I had already taken a course online on digital marketing.

Some topics discussed were,

  1. SEO
  2. PPC
  3. Social Media
  4. Emergence of mobile platforms

3. Brembo Company Presentation :

Brembo is a breaking technology company and a dominant force in the market. A manager from Italy presented the company’s operations in India.

He quoted a quote from the founder of Brembo that I found very captivating,

“Anyone can do simple things, but only few can handle difficult ones. We have to do difficult ones”.

4. Chat with Rahul Yadav :

Next session I attended was a Q&A session with Rahul Yadav, the founder of Housing.com.

It was nice to see him talking about his mistakes and telling people not to repeat them.

5. Wealth creating through financial planning :

This was conducted by Reliance Mutual Funds. In a nutshell it was all about SIP.

6. Keynote by Rajat Sharma :

The day ended by keynote by Rajat Sharma. He discussed his journey and his humility and wisdom was notable and inspiring.

7. Stand up comedy by Vipul Goyal and Sapan Verma

Nice performances by both of them always.

Day 2 :

Day 2 of the event was more power packed. I found the speakers and the talk topics, both to of higher level.

  1. Building a brand that indians love :

This was presented by an ISB professor. Basic point conveyed in the talk was that business customers have two currencies that they spend : time and money.

Thus, trigger point of all the businesses must be how customers are spending these two.

2. Protecting your brand : Trademarks, Copyrights and Patents :

I had no prior knowledge of patents and thus decided to attend this talk.

It nicely packed info on what, when and where to file the patent.

3. Startup Scaling : Overcoming key operational challenges :

Pressing issue of this talk was the resource visibility issues that startups face.

The speaker was from a company called OutThink LLC. They advocated that such challenges can be overcame by businesses collaborating and providing services to each other instead of doing things completely by themselves in isolation.

Here is where OutThink helps its customers by what they call at SRM : Strategic Resource Mapping.

4. Most Common Startup Budget Mistakes:

This talk was presented by a startup investor and mentor from Ireland.

The talk revolved around funding sources, funding advice and bootstrapping.

5. Final Keynote : By Bibop Gresta : COO Hyperlopp TT

The most exciting event of the summit was final keynote by COO of Hyperloop. He presented us with the overview of Hyperloop and how it is planning to carry its operations in India.

It was notable how fit and fun he was at the age of 40. Something that we can all learn from.

Conclusion :

To conclude, the summit was a thumbs up. It was not entirely the standard that I was expecting it to be, but still was Ok.

It was great if you have networking as the primary goal in your mind, not so good if you wanted hand on knowledge on topics.

Finally, it was nice to see other aspiring and existing entrepreneur facing the problems that you are also facing. Makes you feel that you are not alone and if that can pull it off, you can too.