Void

Month: July, 2014

Let us set up an office

FreeCharge recently moved into a bigger office. This brought back memories of the first Bangalore office set up. Setting up an office might not seem a daunting task, but trust me it is. A previous company that I was part of had opted out of setting up it’s own office and worked out of an incubation center, I always used to wonder why not move into a proper office space? Now, after personally going through the hassles of setting up and maintaining an office, I appreciate their decision. If you are a small company, try to avoid moving into an office space of your own as much as possible, do it only if you should and must. There are other options available like co-working spaces, incubation centers etc. In spite of this, if you want to get into the adventure of setting up an office, read on.

First step of the process is prospecting potential office spaces. Office spaces in software parks are expensive and come with long leases, but they are the most organized. If you are reading this, most probably you do not fall into the category who can afford an office space in a software park. Some of the things to keep in mind while prospecting:
1. Keep enough leeway for growth, for at least an year.
2. Is there enough parking space? If there is a shortage of parking in the building and the building is located in a busy place, your employees are going to curse you. You do not want people to be grumpy in the morning before they start their work. On the other hand, if the office space is in a residential area, this should not be a problem, usually you find enough space on the roads to park.
3. Does the building have power back up? You have to keep this in mind until Modi gives us 24 by 7 electricity :).
4. Do all the major internet service providers(ISP) serve the area? Confirm this before you sign on the dotted line as some areas have restrictions against digging etc due to which ISPs refuse internet connectivity.

Once you zero in on the place, the second step of the process starts. Things to keep in mind:
1. Interiors and furniture.
2. Networking. Do you go for wi-fi or ethernet? If ethernet, you have to plan your layout in advance. If wi-fi, you might not be able to get away with a home router as the signal strength may not be strong enough throughout the office or the router might not be able to accommodate all the people in the office. In all probability, you need an industrial strength router/switch and repeaters.
3. Drinking water, do you buy a filter or go for water cans?
4. ACs, fans etc. Do keep in mind that you do not have to buy these, you can as well rent them.
5. Cleaning and maintenance, best to outsource this to an external agency. Keep phone numbers of electricians, plumbers etc handy, you will need them all the time.
6. Office keys, you might have to have a security guard 24 by 7 because you will have people coming in and leaving at different times and coordinating the key becomes a headache.

Also, it is best to hire an office manager who can co-ordinate all these tasks for you. These tasks eat into your precious time and I am sure your time is not well spent on these mundane yet extremely important tasks. If you are working out of an incubation center or co-working space you get most of the above as part of the package. As I said before, try to push off moving into an office of your own as much as possible, do it only if you must.

Nothing is sacrosanct

There is an interesting bug opened against Kafka. For those of you too lazy to click on the link and read through the description, I am reproducing it here in full.

It appears that validation of configuration properties is performed in the ConsumerConfig and ProducerConfig constructors. This is generally bad practice as it couples object construction and validation. It also makes it difficult to mock these objects in unit tests.

Ideally validation of the configuration properties should be separated from object construction and initiated by those that rely/use these config objects.

http://misko.hevery.com/code-reviewers-guide/flaw-constructor-does-real-work/

It links to an article by Misko Hevery on writing testable code. If you have not read posts by Misko Hevery, I urge you to. For an open source project like Kafka, it might make sense(Jay Kreps, the person behind Kafka does not agree with the bug as visible in the comment) to follow all the guidelines of writing testable code but for your project it might not. If you are a small company with a two or three person team, do not blindly follow practices because someone on the internet says so.

Follow rules and guidelines only if it helps you to make your code more secure, performant, easier to maintain etc, do not ape guidelines without understanding why they are laid out in the first place. To go back in history, checked exceptions were all the rage in the Java land a couple of years ago, but these days, after frameworks like Spring sprang up, people look down upon checked exceptions. Same with TDD. TDD was expounded as the next best thing after sliced bread, but now programmers are raising their doubts about TDD.

A lot of times, mocking objects, interfaces etc takes more work than writing the actual functionality. In many projects, there might not be an ROI in writing/maintaining this elaborate test framework/infrastructure. It is true that injecting dependencies into an object makes it easier to test, but it also comes with the downside of having to take care of injecting dependencies every time you create that object. If you are injecting dependencies by hand, object creation becomes an elaborate exercise each time, else you have to delegate this to some framework like Spring, Guice etc, now your project is bloated. Maybe you should side step dependency injection and create the object with the dependencies inside it.

The situations and background under which these rules/guidelines crop up might be radically different than the one in your organisation/team. Taking the call of what to follow and what not to is more of an art than science. Your instincts, past experiences etc help you in formulating them.