In the first part, we discussed the design and project management aspects of the software development process. Here is the link to the complete post. If you have not already read it, please consider reading it first for better continuity.
Code Hosting & Version Control
The code that programmers write is generally stored in text files. Over time, as they add features, the code in these files is modified and every modification renders a new version of your product. At some point in the future if you decide that some of the modifications were a bad choice, and that you want to go back to a previous version, it cannot be easily done without what is called a ‘Version control software’. In short, it is the time machine for your product which lets you go back to past versions without much trouble. At Codemancers we use Git, a popular opensource version control software.
For a further understanding of the basics of version control and the options available, read here.
When code is written, the files are created and stored locally. But it is a good practice to use a code hosting service like Github (or Bitbucket or SourceForge) to store code because it provides a reliable backup, makes it easy to review changes, and have discussions about the code itself.
Github has become an important part of the development cycle not just because it is a great place to host code, but also because of the way it integrates with the rest of the tools in the development process.
We develop features or modify existing ones as guided by the stories in the project’s Pivotal Tracker. These additions/changes in code are then uploaded to the code repository on Github. These code submissions (in the context of version control) are called commits.
There is an option to add a message to every commit to make it easier for other developers to know what has been changed. We also add the Pivotal Tracker story ids in our commits. This helps in pulling out code commits associated with a specific story — another name for a new feature for the product in Pivotal Tracker parlance.
The advantage of doing it is that if, some months from now, someone looks for answers on why a particular commit was introduced, he/she will be able to extract the Pivotal Tracker id (or Jira id as in the screenshot) from the commit message and find out complete details about the bug or feature for which the commit was introduced. This can also be done if you are using Github issues instead of Pivotal Tracker for project management.
A screenshot of the initial wireframing of a project done using Balsamiq
Continuous integration is the process of integrating incremental code changes to the product on an ongoing basis instead of integrating everything as one big change. This process is particularly critical if your product is already live. We have outlined the need for continuous integration and continuous deployment in a post about design and development process.
There are quite a few tools available for automating and managing the process of continuous integration.
We use Jenkins because we can host it ourselves and it has a large ecosystem of plugins which allows us to configure build-pipelines, auto-deployments and quite a lot of things which are simply not possible with other proprietary solutions.
Since we also use Github pull requests for code reviews, we absolutely love the Jenkins integration with Github.
Code climate & Coveralls
Tools like Codeclimate and Coveralls offer feedback on code quality and information on test coverage respectively. Even if you don’t understand everything about the code written, the feedback from these tools should help you check if the team is at-least sticking to some of the software development best practices. As for the feedback itself, if you find something amiss, we would encourage you to have a discussion with your team than jumping to conclusions about the quality of the code. The boilerplate reviews are not always right but they offer a decent guideline for a healthy discussion.
Github integrates with these review tools, thus making it possible to run a review automatically every time there is a pull request in Github.
These tools help us check if the code has proper coverage, if the code metrics look good and if we have a green build in general. This feedback on every pull request is valuable in fixing things as we make progress instead of struggling with the software in its entirety at a later stage.
When team members are geographically distributed, having private chat rooms go a long way in bringing a semblance of proximity to discussions. Having a system for internal communication also ensures that every conversation gets documented for future reference.
There are several chat tools available — Hipchat, Flowdock, Campfire,
Slack are some of the popular ones.
We use Hipchat. It is free and it integrates with Github and the other tools that we use. We have notifications set up in Hipchat for all activities — from code commits to comments on pivotal stories.
The basic idea behind the tight integration is to get every member on the team up to date on the progress without the need for verbal communication through meetings and conference calls. While it would be absolutely necessary to sync up via phone calls every now and then, majority of the communication should be done using asynchronous communication tools. This ensures that everything is documented for reference and nothing is lost in translation.
This post and the previous one are intended to give you a taste of the entire development process. We have explained the ‘What’s and ‘Why’s of the process than the ‘How’s. If you have questions or need elaboration on anything in particular, please feel free to mention that in your comments. We will be happy to address those in our forthcoming posts.
Software development process can be considered a machine into which you feed ideas to generate finished products. When it comes to building products, it is not just raw programming skill that contributes to successful engineering. The development process employed and the tools used to put such a process in place contribute as much to product success. (Read more on this here). This is especially the case in remote engagements. Your choices determine the shape and health of the process. Using the right tools is absolutely necessary to have smooth workflows and minimal overheads.
Here, we will discuss briefly about the process and tools used internally in Codemancers. This information is a good starting point for you to be able to participate in conversations with your offshore team about their process and tools.
Mock up & Design
The ability to visualize and express a product in all its detail even before its implementation is an essential pre step to product building. The ability to express and have discussions about how the user will interact with the product and how the different modules of the product will interact with each other plays an important role in building usable products.
While most people are comfortable using pencil & paper for quick initial sketches, there are significant advantages in using the online tools available today.
- You will have a record of all your initial sketches and ideas
- You will be able to collaborate over the sketches and discuss even if members of a team are geographically distributed
- It gets easy to integrate the design step with rest of the process to render a smooth work flow
We chose to use Balsamiq because, it is easy; it is pretty; and it integrates with our Project management tool. Every UI screen that we mock up and agree upon is exported to our project management tool where it is discussed in terms of features and implementation.
If we were to skip this step to discuss implementation details straight away, the product will end up being a crude hack instead of being a usable piece of software.
A screenshot of the initial wireframing done with Balsamiq
A good way to approach web application development today is by employing a methodology that supports Agile process (incremental and iterative development). Instead of designing and implementing a product in its entirety, in this method, you start with a minimum set of features that will add value to an end user. Once it gets implemented, you can start working on the next set of features. These features themselves are fine-tuned over several iterations.
The advantage of the Agile methodology is that, it is easy to change or modify the direction of the product roadmap based on feedback from actual usage of the implemented features.
Pivotal tracker is our choice of project management tool because it supports iterative development and is easy to use. Also, it is the perfect tool for a non-technical product owner to get a quick understanding of the agile process. Once you understand how to be agile the Pivotal way, progress gets smooth and predictable.
Here, we first break the product idea into features (also called stories). Each story has a description which explains the feature in detail. Once a feature is detailed and discussed, it is translated into specific actionable tasks for developers. At Codemancers, we prefer to document all stories and descriptions before translating them into tasks in Pivotal.
Any of the following tools will work for this purpose - Basecamp, Google Docs, JIRA or Github issues. The only thing to be taken care of is that, if a story requires collaboration of several team members, the tool should have features that support commenting and attaching of mockups or any other required file to aid such a discussion.
A screenshot of the stories done the Agile way in Pivotal
Some of our technically savvier clients who do not want to go the Pivotal way, insist on using Github Issues. In such cases, we use Waffle with Github issues to have the necessary storyboard like visualization.
A screenshot of the storyboard visualization of Github Issues with Waffle
As somebody who oversees the creation of the product, you should be able to evaluate a team not just based on their technology skills but also based on their ability to put a framework in place. In the next post, we will discuss the rest of the process - about Code hosting, Continuous integration and tools that can be used for internal communication.
Remote engagements are hard by their very nature. In a set up where people involved in the project are separated by time and distance, having a well worked out process is the only way to ensure smooth engagement and steady progress. However, process implementation requires a fine balance - There should be enough of it to drive frictionless communication but not so much that adhering to it is in itself hindering progress.
In this post, we will describe the barest minimum of a process you need to put in place to be able to effectively carry out long term engagements with offshore teams.
As a product owner, you play an important role in the development effort. Since you are the best person to present the customer perspective for your product, your continuous engagement is highly recommended. The communication process can be streamlined by identifying a single point of contact for you in the development team. Deciding roles, expectations, frequency of communication and points of contact right at the beginning of the project will help in making sure there are no ugly surprises later on.
Process For Design
Once you have had calls to discuss about product and features, the next important step is to mock up those ideas. It is not a good practice to start development right after discussions. Though this point is stressed enough in several blogs and books, programmers sometimes dive straight into development in their enthusiasm to get their hands dirty. Translating feature discussions to product development by skipping the intermediate mocking up stage may look like a time saver initially. But if expectations are not met, iterating on the actual product will end up being much more expensive than iterating on a mockup.
There is a definite advantage in adhering to the processes and best practices we are outlining here even if your interaction is limited to an Elance developer and not a full-fledged development firm.
Mockups and Discussions
Since whiteboard discussions are not an option in a remote setup, you will have to necessarily employ tools that aid your design discussions. There are several online mockup tools which you and the team can use to sketch your ideas.
As for feature implementations, either you can provide the development team with the necessary mockups or get the UX person from the development team to come up with the mockups to be validated from you. Once a few key pages and features are mocked up, the team can get on with the development efforts while you and the UX person from the team continue with the discussions for the next set of features.
Following an iterative and an incremental approach to development substantially reduces the risk of ending up with an unusable product. In this model, you will implement a small set of meaningful features which is finetuned iteratively with actual usage. Each set of features is then added incrementally to the existing product and finetuned further after usage. This approach even offers the ability to change the feature set based on your feel for the product from initial usage.
Development cycles & Product demos
Your development discussion with the team should focus on deciding the duration of development cycles and what can be achieved in those cycles. As a product owner, your contribution is valuable in deciding the right set of features for implementation in each development cycle and also in providing feedback after usage. Most companies offer a weekly cycle with a demo at the end of it to help you measure progress.
Continuous Integration & Continuous Deployment
Continuous integration and deployment are software development best practices which, if employed, will considerably reduce the amount of time spent in testing and fixing bugs. A company with this set up will be able to discover bugs as and when they are introduced which inturn will help in easy isolation and fixing. Compare this to a scenario where you encounter a whole set of bugs and broken features after deploying your product. The time spent on fixing it this way is so huge that it is smarter to set up an environment for continuous deployment and integration. We recommend this irrespective of how complex or simple your product is.
click here for a detailed reading on this subject.
Project management tools play a key role in helping you set expectations and deliverables; track progress; and reasonably estimate development time for features. Thus it is important to choose a tool which you are comfortable with. The process should be managed in such a way that at any point during the project, you should be able to assess progress without having to actually communicate with any of the team members.
Code Quality Metrics
If you are not a developer, you may not be fully equipped to check the quality of code the team produces. You can solve this to some extent by using tools like Codeclimate which will give you a broad idea about the health of the code.If there are any red flags, you can take it up with the team for a discussion.
Once you have figured out the process and communication for the first set of features, it is all about going through various cycles of the same procedure. Rinse repeat till you get to the launchable version of your product.
The idea of this post was to bring out the importance of having a process and the role of management tools in achieving effective communication. In the next post, we will discuss some of the specific tools that we use internally for our design and development process; and our interaction with clients.
India has come a long way in the past decade with respect to software talent
and contribution. The number and the quality of conferences; technical meetups;
and API hackathons, especially in cities like Bangalore, indicate the positive
change the industry has seen in the last 10 years. Such events have led to
more open source contributions and a much more passionate generation of
developers who love programming for the fun of it.
This shift in the industry definitely renders India to be a reliable and
cost-effective outsourcing destination. But, here’s the caveat: India has a
large number of programmers and by law of percentages it also has a
proportionately big pool of the bad ones. This means that even though there
is an attractive talent pool and a compelling cost advantage in outsourcing,
there is the potential risk of ending up with a bad firm and burning your
fingers in the process.
If you are a company stationed outside India but looking to outsource,
how will you discern the quality of a firm or its developers sitting so
This post is intended to help you with a basic framework to make the right
choice when it comes to finding your development partner.
Defining the scope for your project
This is the first and the most important step in your agency finding exercise.
While many might argue that a good firm should be able to help you with defining
the scope and details, it is necessary for you to do it yourself as a first step
to be able to get to the right firm.
How you go about finding a firm will depend on the nature of your project. To
give an example, if you are looking to build a basic first version of your
product, you will have to shortlist somebody who is willing to work closely
with you to understand your domain and market needs and has the necessary
technical depth to make the right early decisions. If you already have a
working product and you are looking for a firm to optimize the existing code
or build particular modules, you may want to look at firms with deep backend
expertise. Further still, if you are looking for a firm to just develop the
mobile app version of your product, you may have to choose somebody with that
Channels for finding right agency
Mining your personal/professional network for references is undeniably the best
way to start your search. References generally come through only when somebody
has had a great experience and this filter makes your selection process easier.
Even if you don’t have immediate connections, with networks like Linkedin, it
should be possible to take advantage of 2nd or even 3rd level connections.
If you have decided on the technology to use, you can reach out to developers
through mailing lists for that technology in the region that you are considering.
Developers from a good agency will have an active participation in discussions
and it should be a good place to get in touch with the ones relevant to you.
Conferences and networking events
If you have the time and budget, it is best if you can make a trip to India to
attend local conferences and networking events. A good development agency usually
has speakers at key events in the city. Attending such events will help you make
your selection after face to face meetings with the prospects.
Once you have a shortlist of companies, the next crucial step is to see who will
best suit your needs and working style. The following points will give you a
framework for that decision making.
Depending on the scope of your project, you may want to see how many developers
need to be engaged full time on your project and what their profiles are. Even
if the founders and some team members have impressive profiles, the quality of
the work delivered depends very much on who is working on your project. Be sure
to evaluate the profiles of members who will be working directly with you.
A confident firm will discuss about projects done, share their project portfolio
and will also willingly extend customer references. Not all details are published
in a company website because sometimes client projects are confidential. In such
cases you can ask the firm to mail you the project portfolio that talks about all
their projects and processes.
Also, it will definitely help in your decision making process to talk to their
clients about what they liked/disliked about their engagement with that firm.
Customer testimonials offer credibility and provide insight into the company.
Eventhough a company will only publish the positive feedback from clients as
testimonials, a quick look at those testimonials should help you understand what
the firm is doing right.
Open Source contribution
If your choice of technology is open source, you are better off choosing firms
who contribute to Open Source and more importantly firms that encourage
contributing to Open Source. An active participation and contribution in the
development community generally indicates a love for their own craft. It goes
without saying that the ones that love their craft produce quality work.
You can can check a company’s contributions by asking for their Github profile and
checking the projects the company has created or contributed to.
The advantage of this method is that you can even engage somebody independently
to check the quality of the code contributed before you make the decision to hire
Development firms everywhere have the tendency to use technology buzzwords to
appeal to their clients. If a team claims they follow agile processes, make sure
you get them to explain what it means for you in layman terms. Does Agile mean
weekly updates? Does ‘pair programming’ mean higher costs? Make sure you get
them to explain their processes. This will help you in understanding how your
everyday interaction will fit into their processes.
Most offshore engagements fail due to poor communication. Even if the firm has an
impressive background, if you are not convinced about their communication skills,
you are better off letting go. Communication problems only worsen over time
especially with the time zone differences. By communication, I refer to the
ability of the team members to listen, understand, ask the right questions and
convey their points of view to arrive at an agreement over discussions.
‘If you pay peanuts you will get monkeys’ holds true when it comes to software
outsourcing in India. If you are looking to hire someone at a rate of USD 10/per
hour you are likely losing your entire budget without getting any work done.
It takes anything between $2000 to $7000 per month per developer or more
(depending on complexity) to engage a firm that will deliver on its promises.
Even at this price point, the costs are lower than hiring a full
time developer in the US or Europe.
More often than not, mending bad code ends up being more expensive than building
from scratch. Cost is a decent indicator of quality and hence you should have
your guards up if you come across ridiculously low bids.
The evaluation process plays a crucial role in your success because making a wrong
choice can cost you dearly. Our advice here stems from years of experience of working with startups around the world.
While this post will help
you in finding the right firm, it is only the first step. In our successive posts,
we will have discussions on design and development processes that will help you
engage with your offshore team effectively.