Stack Overflow profile for Roopesh Shenoy

10 Questions to Ensure That You Have The Right Cofounder

CoFounding a Company is a lot like marriage; only more difficult. Usually, there are more than 2 people involved, there is a baby born on the first day (your company) and that baby will demand almost all your attention every day.

And you are legally bound to them; if you ever were to separate, there would be an issue of the custody of the baby, as long as it makes it.

Obviously, you have to get into bed with the right people!

Answer these 10 questions to know if you have the right co-founder for your company. The below are in singular (so you can judge one cofounder at a time)

Is your  Co-founder -

  1. different enough that they bring a unique perspective and a different skill set than what you already have?
  2. similar enough that you don’t have large ideological differences and ambitions about where your company should go in the long run?
  3. someone you respect and respects you back?
  4. someone you trust and trusts you back?
  5. someone who you can rely on to deliver?
  6. the best at what he/she does?
  7. a team player?
  8. sold on the problem you are trying to solve?
  9. a self-starter?
  10. willing to learn?

Even a single “no” means you should rethink.

Are there any questions you would like to add here?

What Makes A Game “Dream Team”?

So you’ve decided to take a plunge and explore the world of Game Development. And then you wonder, what kind of a team will help you get there?

At makkajai, we’ve been there, and we’ve had our fair share of lessons along the way. I’m sharing this, in the hope that others find it useful and can get up and running, building amazing games, even faster than us.

Unless you are just building a hobby Game, or have decades of Game building experience (and even then), you need a good team to supplement your skills. At minimum, you need these roles identified and amazing people to fill them.

  • Game Designer – U/x Designer on Steroids + knows Technology as well as Business + Good Leader And Manager

    It’s important someone owns this role on the founding team. This is not just UI design or U/x Design but Game design – holding the bottom-line for the game and bringing various experts to work together (story, technology, art, etc.)  Really, if you outsource or delegate this role, you are not a game maker, you are just a publisher.

    There are very few game designers worth their salt, but with effort, you could do a good job yourself – this is the best book I have read on this topic, must-have before you start even considering building your first game. Take a month just to read the whole thing and then read it again just to sink it in. Absolutely worth it.

  • One (Amazing) Developer – Polygot if possible. Building a good game is hard work, and you want a developer that can just deliver on anything that is technically feasible, without a skill gap coming in the way. Even simple games can get complex as you improve it in stages, or even have multiple moving bits (server-side processing for example), so I cannot overstate the importance of this. 

    How amazing? As much as possible, and then a bit more. Someone you would choose to build some software if your life depended on it. At such level of awesomeness, it really doesn’t matter whether the person has Objective-C/Android Experience, because they will learn it in days.

    It helps if you have another developer (maybe Game designer doubles up as developer, or someone else on the team). But one person needs to be an out-and-out technical guy/gal. And helps if he/she is a co-founder.

  • Artist – Someone to actually bring your ideas to life with pencil and colors. (figuratively of course, people use digital tools these days!) It took us weeks to find a good artist, but when we did, it was incredible. 

    Possibly on contract initially, I don’t think you’ll need a full-time artist till you start working on multiple games at once. But if one of the founders themselves is an artist, it can be a great advantage.

  • Sound Engineer – Sound is the magical, invisible ingredient that separates a great game from merely a good or mediocre one. Even if you don’t have a sound engineer, you will have to spend a lot of time working out the right sounds and music for your game. 

    Again possible on contract initially, unless one of the founders is a Sound Engineer or even a Musician themselves.

  • Business Guys - Yes, you need to start worrying about marketing, monetization, branding, fund raising, etc right from day one, so you can actually achieve your dream of building that awesome game.

If the Game Designer and the Artist both aren’t very familiar with Photoshop/Illustrator, then you might need someone with that expertise. But generally this is not the case.

Depending on your ambitions, you might need other people. Professional writers for your story, Translators for localization. But the above is what you start with.

Make sure you have an experienced or at least a very skilled team. There is no room for interns (unless they are exceptional), at least in the beginning, if you are building a game. But then I think you should never hire interns for a startup; what do I know!

Should A Founding Team Work Remotely?

This is a big question right now starting at makkajai, and here is my personal take on things.

The advantages of remote working are well-known – more options for a healthy, well-balanced lifestyle, better recruiting options, generally more productivity, freedom to travel without compromising on work, and so on. However, is this option to be limited only to employees, or can a founding team start working remotely, essentially building this into the company’s DNA?

Remote Working is Scary – it’s a huge departure from how things are traditionally done. Some of the points that could be seen as valid concerns -

  • Productivity – will productivity remain the same? Will it get affected? Will availability (or in-availability) of other co-founders outside of strictly scheduled times affect us?
  • Interactions between the founding team – This is a big one – what about all the informal and unplanned discussions founders need to have so ideas culminate, that did not just originate from one person’s head – how can that happen if we are not all co-located?
  • Investor dilemma – Would a potential investor see this negatively? Can questions arise, such as "if the founders are not even willing to move to be co-located, how committed are they to the startup?"

Let me try and address above issues one-by-one

  • Productivity – I think this is generally a non-issue. Having worked remotely as a consultant for couple of years, especially in teams that have never had a remote-worker before, I think clear communication and discipline can ensure that you are just as much, if not more, productive when working remotely. There are several reasons for this -

    • Lesser distractions – meetings and other important discussions need to be planned up-front, which is a good idea anyways, but doesn’t normally happen when working in-person; it’s very easy to just start a discussion with "hey, tell me something.."
    • Tools such as Skype or Hangouts make video calls quite cheap, as long as you have a reliable internet connection (Abhishek, I’m looking at you!)
    • Being remote, you can now be judged solely on what you contribute, compared to how many hours you spend on the venture. Personally, I think this is very, very important – it forces us to go beyond mere "sacrifices" and focus on "contributions" which is a more fair way to judge what a founder brings to the table. If, sometimes, uncomfortable questions need to be asked, they need to be asked and will not be pushed away with thoughts such as "at least he/she is working hard".
  • Interactions between the founding team -  I agree this is important – however I think the main point to focus on is Interactions. There are ways to enable this even remotely – for e.g. we can just enable a live camera 24*7 and let people just *pop-in* virtually on any team member, if that’s what it takes to get us comfortable. Skype, Slack, basecamp, and several other tools can relatively cheaply make virtual interactions not only a lot more feasible, but also leave a trail of discussions (something that doesn’t necessarily happen in-person) – which can be quite useful for later reflection or for new-joinees.

    The key here should be focussing on enabling the right infrastructure to making this work.

  • Investor Dilemma – this is I think, simultaneously, a real issue as well as the least important one; I agree that investors will probably give us some grief over this, till we show results. However that’s the key I believe – investors will always give us grief till we show results. I wouldn’t personally want to work with an investor who just forces us to work in an office, even if we have shown results working remotely; such level of operational interference can be painful.

    In fact, in some ways, this can also help us attract the right investors. Startups need to do something different from other startups, because 90% of them fail – the more different we are, the better chances of us standing out and actually succeeding. And investors do know that, so this can be an excellent PR strategy. Plus, if we quantify the cost-savings in terms of reduced salary and other expenses, I think it will help sway investors even more.

There are several key advantages too –

  • Ability to hire great people to work remotely – this single-handedly enables us to hire the best people in the world, without worrying about location; and not just for transactional roles, but important product, development and sales roles. Putting the infrastructure in place right at the start of the company will give us the necessary experience and processes that will help in putting such a hiring plan into action
  • Better Sustainability – there is no question that there is a better work-life balance for founders working remotely; given that most startups are able to drag-on for more than a year and have increasing chances of success, the longer it can sustain, I think paying attention to softer aspects such as being close to family can be a big deal to sustainability.
  • Lesser Costs – several personal costs are reduced for different founders in different cities – and this leads to lesser cash salaries and lesser burden on the company. Even with all the additional costs of supporting infrastructure, there will be a lot of savings on rent, commuting and travel.

As a summary, I personally think remote working is not just a viable option, but the best option available to even a founding team, especially one that is experienced, good at communication, knows each other well and is mature. The key would be identifying issues and taking concrete actions to resolving those issues rather than blaming remote working for them.

There are some really good posts on how to do this effectively, tools to use, and more –

What do you think? Can a Remote Founding Team work? Or are there pitfalls that are just impossible to avoid?

Git-Svn–Working With Multiple But Selected SVN Branches

(Starting from a trunk-only checkout)

Who doesn’t like Git? And who doesn’t have to work with SVN?!

It’s a fairly common practice in a project that I’m working on, for several developers to use git-svn to avoid having to deal with Subversion pain; rest of the team is not ready to move on from SVN, so this is the next best thing we, git-lovers, can do.

Since our work is limited to a particular directory in SVN and there are lots of other things in that same SVN Repo, plus we have a branch per release policy, my repo had only the trunk checked out (+ one of the old release branches). The .git/config file looked something like this –

[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdates = true
    symlinks = false
    ignorecase = true
    hideDotFiles = dotGitOnly
[svn-remote "svn"]
    url = https://<svnurl>/<ourSpecificDirectory>/trunk
    fetch = :refs/remotes/git-svn
[svn-remote "rb-1013"]
    url = https://<svnurl>/<ourSpecificDirectory>/branches/RB-10.13
    fetch = :refs/remotes/rb-1013

The two remotes, actually work like two separate remotes. The “rb-1013” would download all the data from SVN all over again, without worrying about what “git-svn” already had.

Now I had to checkout another branch – and doing it this way would take hours just to download all the data again. I could use the “-r” flag and start from a specific revision, but that too will still download all the artifacts at least – and I just din’t have so much time. It also din’t make sense to me that we need to download all those revisions when the trunk already has the same revisions as the branch uptil the point of branch creation. So, after quite some research, this is what I did.

  • Backed up my git repo (:D)
  • Removed all the rb related references from .git/config (the section for rb-1013 above – just to clean up, din’t really need that branch any more).
  • Changed the git-svn reference in config file from – >

[svn-remote "svn"]
                url = https://<svnurl>/<ourSpecificDirectory>/trunk
                fetch = :refs/remotes/git-svn

TO

[svn-remote "svn"]
        url = https://<svnurl>/<ourSpecificDirectory>
        fetch = trunk:refs/remotes/git-svn
        branches = branches/{RB-10.26}:refs/remotes/branches/*

Basically this is to ensure that the branches are related to the trunk, so same commits are not downloaded again. The refs/remotes/branches/* is a wildcard that creates remotes for each branch that is present. And the high-lighted portion is a comma-separated filter will restrict the branches we download.

Note that since the overall trunk path is still same, it din’t break the existing revisions in master (which pointed to git-svn).

  • git svn fetch

That took a long while with no response – after some more research, I found the .git/svn/metadata file – opening this showed that the file was indeed getting updated, something called branches-maxRev was getting updated – it started searching from revision 0 to see where the branches were created which are not yet fetched locally.

Note that it was *not* downloading all the revisions, it was just searching svn to see when it created the branch (because we don’t have that info locally).

Not fast-enough though – CTRL-C!!

  • Found the second reference below – basically suggesting if we know the revision on which the SVN branch was created, we can speed up the process. No problem right? Well, went to https://<svnbaseurl>/viewvc and used the browser client to see that the RB-10.26 branch was created on revision 29313
  • Re-run the above command but with this revision

    git svn fetch –r 29313:HEAD

    Ok, some things start downloading! I can see RB-10.26 in the refs path in git-svn logs.

  • After everything downloads, verify using “git branch –r”
  • BOOM!

And it works. Took a few minutes to download the diff revs, but now I have a new remote: /branches/RB-10.26. Now I create a new branch in git to point to this reference

  • git checkout –b production26 remotes/branches/RB-10.26
  • and verify

git svn info

Shows the branch instead of trunk – switching to master shows trunk.

The actual git-svn download took few minutes – I’ve never been able to download an SVN branch *ever* so fast, especially when using SVN, so this is a big win for Git, even when working with SVN!

 

References:

http://stackoverflow.com/a/10173516/297964

http://stackoverflow.com/q/10878976/297964

https://www.kernel.org/pub/software/scm/git/docs/git-svn.html

3 Laws For Software Developers

I now propose these three laws for any useful Software Developer –

  1. A Developer may not, through action or inaction, let the user do more work than necessary
  2. The developer may not, let the computer do more work than necessary, as long as it does not conflict with the First Law
  3. A developer may not do more work than necessary, as long as such it does not conflict with the First and the Second Laws.

Note: 2nd and 3rd Laws might interchange in priority depending on scale.

Bonus Law: You will make the world a better place. Break all 3 laws if you have to, to do this.

Inspired from Asimov’s 3 laws of robotics.

Religious Practices For Programmers

I was asked recently to come up with a checklist for developers to improve code quality. There are definitely a lot of things on the internet for this, but what the hell, here’s my $0.02 worth.

Apart from years of penance and discipline, here’s a few things that should definitely help. This is written targeting C# developers but a large part of it should apply to all developers.

Key things to keep doing daily –

  • Refactor – the first version of code that “works”, will more or less suck – it will be un-optimized, violate DRY principle, might have unnecessary code, won’t have enough tests, etc. It’s only refactoring that improves things. So consciously keep enough time to refactor the code once it is in working state. This is the single most important thing that people forget to do – it’s crazy even. With this one single rule, your code will improve several folds in terms of quality.
  • Remember that code needs to be read and maintained long after it is written – write code that people will find a delight to read or modify. Try to follow simple things such as –
    • Separation of concerns
    • Automated testing
    • Leveraging type system wherever possible for compile-time guarantees
    • Use better language constructs to keep code as concise as possible. A line of code that doesn’t exist is a line of code that can’t have a bug!
    • Higher and higher levels of abstractions
  • Keep on the lookout for repetitive code, or work that you are doing that did not make you think – for e.g. if you are just copy pasting from another place in the application, it means that there is a strong opportunity to refactor, such that you *don’t need* to copy paste (for e.g. a single method call, maybe with optional parameters for conditional handling).
  • Spend more time on thinking than typing – you are a developer not a typist
  • Have good typing speed though – you want whatever you think of to come on to the screen without breaking your thought process
  • Keep on the lookout for tools that will make life simpler. Resharper for instance, helps you with a lot of silly mistakes.
  • Don’t use the tools as a crutch though. For e.g. you should be able to make out good code from bad just by looking at it.
  • There will be occasional instances where you need to put in a hack – always keep this as the very very last option. And add enough comments to warn others that this is not a pattern to be followed
  • Do not sacrifice long-term maintainability for short-term gains – even if the business asks for it. Simplify things if possible – but don’t compromise quality. (for e.g. we might not make the feature extremely configurable, but still it can follow good coding practices such that it can be added later easily if needed).

Use better languages – F#, Haskell, OCaml, etc. I know you probably want me to tell you how to write better code with C#, but there is a ceiling we *will* hit with certain tools. If you use a kitchen knife to do a surgery, there is only so much you can improve via practices and skill. Just imagine how difficult it would be to do things in C++ and have same kind of quality that we have now with C# code (considering additional overhead in terms of memory management, for e.g.), spending the same effort. Some common C/C++ code bugs (such as memory leaks) just aren’t valid C# code in a lot of cases. There is a similar boost you get with F# and Haskell (where a lot of common bugs in C#, such as run-time null-reference exceptions, are just not valid code in F#/Haskell). That, along with tremendous conciseness, will make code quality better, even for the same developer.

F# Revisited

Sometime last year, I wrote an article demonstrating BDD with C# and F#. The accompanying source codes were hosted on github.

Now I’ve been doing some more functional programming recently and took an opportunity to revisit the F# code I had written then. As it turns out, I had written the first version in Object oriented style in F#. Switching to functional style has made it even more elegant and concise. The difference – 55 lines of code, versus 120 earlier (versus some 200 odd lines of code in C# for the same functionality).

Some of the differences –

  • Using Records instead of Types to encapsulate data (e.g Date)
  • Using base types directly wherever it makes sense (for e.g. int for Year instead of a separate Year type)
  • Using independent functions rather than enclosing them within types

These three go together – functions as first-class citizens means that we no longer need to define types just to house them.

  • Using simpler syntax – for instance, avoiding unnecessary braces
  • Using more powerful language features – using type inference, pattern-matching, higher-order functions a lot more aggressively
  • Some cheating Smile – smaller variable names, fitting more on one line (both, only where it doesn’t affect readability).

I find the new version a lot simpler to understand, with very little distractions such as instantiating objects or trying to access their properties.

The Power Of Functional Languages

I’ve been always intrigued by functional languages, learning bits and pieces of it whenever I got time, but recently I started skilling up on Haskell for building the backend systems for Makkajai.

This example below just emphasizes the power of functional programming vs imperating programming. This is an example from Learn You a Haskell for Greater Good.

“which right triangle that has integers for all sides and all sides equal to or smaller than 10 has a perimeter of 24?”

The solution to finding the answer programmatically in Haskell –

let rightTriangles' = [ (a,b,c) | c <- [1..10], b <- [1..c], a <- [1..b], a^2 + b^2 == c^2, a+b+c == 24]

If you observe carefully, the expression just resembles the problem statement, mathematically defined. There is no logic that needs to be written, no dirty for loops that iterate and check whether the conditions are met or not – and yet haskell is able to produce a result, which in this case is [(6,8,10)].

This is the power of functional programming – most of your code starts resembling your problem statement rather than the logic to arrive at the answer. Not only is it easier to write this code, it is also easier to read and maintain compared to anything you might write in C# or Java (go ahead, try it!).

The only mainstream language that is just as powerful is SQL – which is declarative again instead of imperative. Imagine if you had to describe to the database how to fetch the data, rather than just describe the constraints and let the database do it’s job? It’s surprising that SQL is almost universally accepted but similar concept in application programming has not yet become mainstream.

Kashmir–Heaven On Earth

Got badly sun-burnt, lost my sun-glasses, lost a water bottle, nearly got lost myself a couple of times – and yet this turned out to be my best vacation ever!

I went for a trek recently, visiting the great lakes of Kashmir. 21 trekkers, 5 guides, a team of helpers, tents, sleeping bags and mules to carry them – more than 80 kms in 7 days – all in all a trek to remember! There were at least 3 SLR cameras with semi-professionals operating them, so I did not bother clicking a single photograph. Luckily, others did.

The amazing Vishnusar lake – the water was icy cold and only 3 out of 21 ventured in for a swim; though no one lasted for more than a few minutes.

Vishnusar

(courtesy: Varuna Raina)

The pretty Krishnasar lake had a bit less water this time around – the land mass I’m standing on down there is usually submerged. All the good though, cause it made for a good amount of reflection!

Kashmir

(courtesy: Anand Rathi)

 

Vishnusar again – though now in early morning mist

Vishnusar (anurag)

(courtesy: Anurag Srivatsava)

 

The magnificient Gadsar lake –

Gadsar (anurag)

(courtesy: Anurag Srivatsava)

 

water-background

(courtesy: Khurram Haque)

 

Although the photos look great, nothing can describe the actual moments spent in the mountains – cold breeze kissing one’s face, sunlight dancing around the snow and water causing beautiful effects, valleys filled with colourful flowers, sheep and horses grazing lazily on the green grass – these just have to be felt. I can go on and on – a hot cup of tea or a warm camp fire in cold evenings, a refreshing swim in a cold lake after a tiring trek, the step that you cautiously take on a fast-disappearing trail, which if you miss, could be your last – all these just make you live in the moment and forget about past and future just the same.

 

PS: For a day-by-day account of the entire trek, head-over to Varuna’s travel logs.

Transactional DDL In PostgreSQL

Recently I came across a comparison of Transactional DDL support in various databases, on the postgresql wiki.

For me  this has been an eye-opener – having started my career with Oracle databases, I was brought up thinking that ddl statements are always outside transactions, without questioning why it must be so.

PostgreSQL not only supports transactional DDL, it does so in the most intuitive way – you just wrap these statements in a transaction block and everything can be rolled back if necessary. No auto-commits (like Oracle/MySQL does), no need for specific Isolation levels (like SQL Server) – works quite robustly without any problems.

Just one more reason for me to pick Postgres as the database of choice for my upcoming projects. Then of course, there is that thing about Postgres actually being the most advanced database and open source at the same time.