List of FREE services Startups should be using

I have curated a list of free tools, services, and apps that startups could and in fact should use to grow at the initial stage. Free doesn’t mean they lack quality, instead these free tools are from top-notch companies like RedHat, Google, Asana, GitHub and in all areas from infrastructure to version controlling to marketing and sales to project management.

Have a look at this list here and don’t forget to give your feedback.

I compiled this list a long time ago and recently updated it but it still might have some outdated links that I didn’t get chance to update yet. Feel free to let me know and I’ll update it.

Enjoy!

Advertisements

1 reason why you shouldn’t be an Entrepreneur?

There has been a lot of buzz about entrepreneurship in recent years and lot of people have come up as great entrepreneurs and have set a trend for others to pursue in this direction. This term was not very common in the past and due to which lot of people don’t really know what entrepreneurship really means. Lot of people also mix it with just doing business. That is true somewhat but that means every businessman is an entrepreneur? That is not the case. Lot of people think doing technology enabled business is entrepreneurship. This is also not very true although in our modern era technology has played a big role in business and life.

So, if you try to dig it more, talk to entrepreneurs and other people you will start differentiating business and entrepreneurship. There are different traits of entrepreneurship. Entrepreneur actually take risk and starts a new business on the opportunity he/she finds.

Let me explain. First let’s describe what is opportunity. People come across different problems in life. Opportunity is basically a solution to that problem. You might be thinking how come a problem be an opportunity. You are right and this is where things start to go wrong.

Business is to earn money to fulfill their family needs. While entrepreneurship is finding people’s problems and make money from that problem.

If you hold for a moment and think what entrepreneurs do is ask money from people just to solve their problem. In my opinion this is not a right approach and creates a culture where people instead of helping each other will ask for money to give them a hand or solve their problem. This kills the humanity and one will always thought of making money from others problems.

I won’t say doing business is wrong, but the approach of entrepreneurship is. And this is the one reason you shouldn’t be an entrepreneur if you really cares about people and want to help them.

At the end of the day this is my thought and doesn’t represent anyone. Let me know in comments below if you agree with me or what are your thoughts on doing business and entrepreneurship.

Code Refactoring

One reason why you should refactor your code often

Once upon a time, a consultant made a visit to a development project. The consultant looked at some of the code that had been written; there was a class hierarchy at the center of the system. As he wandered through the hierarchy, the consultant saw that it was rather messy. The higher level classes made certain assumptions about how the classes would work, assumptions that were embodied in inherited code. That code didn’t suit all the subclasses, however, and was overridden quite heavily. If the superclass had been modified a little, then much less overriding would have been necessary. In other places some of the intention of the superclass had not been properly understood, and behavior present in the superclass was duplicated. In yet other places several subclasses did the same thing with code that could clearly be moved up the hierarchy.

The consultant recommended to the project management that the code be looked at and cleaned up, but the project management didn’t seem enthusiastic. The code seemed to work and there were considerable schedule pressures. The managers said they would get around to it at some later point.

The consultant had also shown the programmers who had worked on the hierarchy what was
going on. The programmers were keen and saw the problem. They knew that it wasn’t really their fault; sometimes a new pair of eyes are needed to spot the problem. So the programmers spent a day or two cleaning up the hierarchy. When they were finished, the programmers had removed half the code in the hierarchy without reducing its functionality. They were pleased with the result and found that it became quicker and easier both to add new classes to the hierarchy and to use the classes in the rest of the system.

The project management was not pleased. Schedules were tight and there was a lot of work to
do. These two programmers had spent two days doing work that had done nothing to add the
many features the system had to deliver in a few months time. The old code had worked just fine. So the design was a bit more “pure” a bit more “clean.” The project had to ship code that worked, not code that would please an academic. The consultant suggested that this cleaning up be done on other central parts of the system. Such an activity might halt the project for a week or two. All this activity was devoted to making the code look better, not to making it do anything that it didn’t already do.

How do you feel about this story? Do you think the consultant was right to suggest further clean
up? Or do you follow that old engineering adage, “if it works, don’t fix it”?

Six months later the project failed, in large part because the code was too complex to debug or to tune to acceptable performance. The consultant was brought in to restart the project, an exercise that involved rewriting almost the whole system from scratch. He did several things differently, but one of the most important was to insist on continuous cleaning up of the code using refactoring.

This is an excerpt from the book preface “Refactoring – by Martin Fowler”.