Category Archives: Outsourcing

Why Does Your Company Need to Outsource Software Development?

Outsourcing software development is one of the most efficient ways to take your company to the next level. Outsourcing software development can increase profitability, improve your competitiveness in the marketplace, accelerate business operations, and, most importantly, increase customer satisfaction — and revenue along with it. With the right outsourcing team, your company will be ready to keep up with the demands of the ever-changing marketplace.

outsourcing softwareAlthough outsourcing software development is not a new tactic for product development, many companies still hesitate to seek outside help. However, when outsourcing is done right, the benefits of contracting a specialized team far outweigh the disadvantages.

Here are some of the top reasons you should outsource your software development needs.

Focus on your business

In today’s marketplace, team members often wear several hats and deal with many operations within the company. Your company’s IT department may not be able to put aside their current responsibilities to concentrate on a new project. Hiring and onboarding new developers can take months, but you have needs that must be addressed now.

Wise business managers know that their employees perform at their best when given the time to focus their efforts and plan accordingly. Stretching employees thin can affect team morale, productivity, quality of work, and employee retention. By outsourcing your software development needs, you are freeing up your team’s time to focus on what they do best. As a result, your product will be ready to hit the market faster, and with the best possible team behind it.

Software applications may play a key role in your business, but they may not be your core business. Entrusting your product development to a firm whose core business is software development ensures that you have access to growth strategies and operating processes which will be focused on creating high-quality software for your company.

Find talented resources and experience

For businesses looking to gain a competitive edge, outsourcing projects can open up access to technologies that may be unattainable otherwise. A software development firm can provide a pool of experts to take care of needs that your team currently cannot meet.

If certain programming skills are in high demand, the hiring pool for in-house employees may be limited. Conversely, if you need a niche technical skill or an innovative emerging technology, you may not want to commit to a full-time employee. Furthermore, the more specialized a skill, the fewer the people who will be available to execute it. You also may need subject matter expertise from someone who has worked on several similar projects and has the exact skill and technical profile needed to carry out your vision.

Outsourcing your projects means that you can expand your team to cover the exact skills and specialties required to develop your project. If a new demand or technical skill arises, the software development firm can easily cover those needs. If a team member is unable to work on a project, the firm can easily find a replacement, saving you time, resources, and money.

Save time and money

While costs should never be the most important factor of a business decision, the time and cost savings of outsourcing your software development may indeed convince you to search for an outside firm.

The costs of hiring and onboarding a full-time employee don’t end with a paycheck. In addition to the taxes and benefits (paid time off, health insurance, and 401(k) matching) that are provided on an employee’s behalf, additional costs of technological devices, hardware, software, office space, and direct management need to be taken into account when considering the costs of a full-time employee. Contracting a team to deal with a specific project may be more cost-effective in the long run compared to onboarding another in-house employee.

Furthermore, when it comes to outsourcing, the world is indeed your oyster. You can contract a firm from anywhere in the world, especially since much of the work and communication can be done virtually. As the cost of living varies throughout the world, the cost of outsourcing services varies along with it.

In today’s world, it can be challenging to keep up with the demands of the ever-changing marketplace. Outsourcing your software development projects can help your team members focus on what they do best, ensure that you find talented resources and expertise, and save time and money in the long run. In our e-book, “Best Practices for Software Outsourcing,” we offer more information about the factors to consider when outsourcing your programming needs.

At Santex, we are committed to your team’s success through our quality and passion. Along with building long-lasting and mutually beneficial relationships with our clients, our custom outsourcing services provide flexible solutions to meet your software needs. Software innovation is our passion, and our teams offer “the best talent in the right moment” to help you achieve your technology goals.

software outsourcing practices agile methodology

Is Your Agile Team High Performing?

agile team software technologyHaving an agile team can make all the difference in how your company functions. Agile teams are known to be more flexible and high performing, enabling you to ship out new products faster and stay competitive. However, simply calling a team agile doesn’t guarantee success. Companies have to work at being agile and that requires having certain skill sets.

There are six important characteristics a team must have to be considered agile. We will discuss those characteristics here and then discuss how your company can make its teams more agile.

Communication: Is Your Team Communicating Enough?

Communication is vital whether or not your team is considered agile. It’s important to always keep the lines of communication open, whether that’s through regular team meetings, email communication, or some other method, such as a Slack channel. Both team members and management should be able to give and receive constructive feedback on a regular basis, outside of the traditional annual reviews. While those annual reviews are still important, it’s good to be proactive throughout the year to ensure that your team is performing well.

Another important aspect of communication is expectations. Managers should lay out clear expectations for projects right from the start, but also provide opportunities for team members to ask questions throughout the process. There should also be a plan in place to automatically update team members about any changes that might need to be made to a project. Frequent communication is key because it’s the only way to create the feedback loop that is a must for every high-performance agile team.


Cross-functionality is defined as a team with various functional expertise working toward a common goal. A cross-functional team will include at least one person each from multiple departments within a company. A well-rounded cross-functional team might have members from human resources, marketing, finance, and more.

The key to a successful cross-functional team lies in the ability of team members to work well together toward a singular vision. From the start, they have defined expectations and allow members the opportunity to let their strengths shine, while also learning other skills that will make them an asset to their current team and to other teams in the future.

Since agile tech teams require feedback from different teams so that product and software changes can happen faster, effective cross-functionality is a must.


A good agile team has the ability to collaborate irrespective of their strengths and weaknesses. The team members combine their strengths and weaknesses to create a team that is able to achieve multiple goals. Collaboration is best achieved when expectations are clearly set from the beginning of a project and teams are able to put their best foot forward.


A good agile team will be able to manage themselves without having to constantly be guided by a manager or a project leader. This isn’t to say they don’t need guidance, especially at the beginning of a project, but they should be able to take a concept and run with it, as long as they have the necessary resources available to them. A good agile team is also self-motivated and eager to prove themselves.

Is there alignment on performance objectives with other departments of the company?

As mentioned above, it’s important to measure performance objectives throughout the year and not just during the annual review period. Moreover, performance objectives should be aligned across the entire company. All employees should be striving for excellence, whether that’s within their team or within their individual role.

In this case, there should be an emphasis on product delivery rather than project delivery. If an organization hasn’t transitioned to a product structure, there may be issues in getting team members to align with one another. In such a case, the leadership should take on an expanded role in helping teams become more cohesive.


As with any business, people are driven by metrics. There should be tangible goals that teams are working toward and they should see the results of those goals. The measurement of goals should be clear and concise. Setting tangible goals with measurable objectives can help the leadership see where teams are excelling and where they are struggling.

There are many metrics an agile team can measure, including sprint burndown, team velocity, release frequency, and delivery speed. When looking at metrics, it’s important to look at what went well and what needs work. By measuring these specific metrics, teams will have measurable goals to strive for.

It’s okay if you don’t currently work for or have agile technology teams at your company. It’s easy to turn things around and create an agile team that can work for you instead of against you. Just follow the recommendations above and your company will run like a well-oiled machine in no time at all.

If you feel like your company needs further support in becoming agile, Santex can provide you with the tools and resources necessary to help your team become more agile and better able to keep with the agile teams that already exist at other companies. Be sure to check out our most recent e-book, Best Practices for Outsourcing Development, for more information.

software outsourcing practices agile methodology

What to Consider When Hiring a Software Development Company

software development

It can be challenging to find the best software development company to meet your needs. There is often more to outsourcing that meets the eye, and choosing the wrong firm can cost you time, money, and your project’s position in the marketplace.

What are your project requirements?

Do you need to make a web application or a conventional website? Will the most complicated feature on this site be a blog or shopping cart, or will your project need to be integrated with a customized back-end system, such as an ERP or payment system? Do you have a maximum budget or a strict delivery timeline, or is having features your customers will love your biggest priority?

If your needs go beyond what can be found in a plug-in or a ready-made program, you need to find a software development firm with a wide range of expertise, such as software engineering, user interface optimization, web analytics, traditional web design, and more.

Furthermore, with many technical services, compromising on price may lead to a compromise in quality. If your application or project must be created from scratch, then the firm will probably need to construct something that the developers have never created before. Investing in a team with creative, flexible, experienced professionals increases your chances of getting the details right earlier on, allowing you to enter the market much sooner.

Here are a few tips to keep in mind to help the process of outsourcing your software development project go as smoothly as possible.

Proven track record

Although a firm’s portfolio may be impressive, it’s essential to know more about what happened behind the scenes. Even if the projects and web applications themselves look great, you have no way of knowing if these endeavors were delivered under budget and on time. The final project may have come to fruition only after constant conflicts between the software developers and the client. Asking for references now can lessen the chance of unpleasant surprises later, and an established company should have at least a few satisfied clients who would be willing to speak with you.

If a firm’s portfolio or client list is attracting you to a particular firm, you need to know whether the same software developers and engineers would also be assigned to your project. Make sure to ask about the specific developers who would be a part of your development team. When possible, ask for a reference from a client who has worked with these individuals before.

Maintain constant communication

Transparency is key in any client-provider relationship, especially if you are considering outsourcing a project to people you may never meet in person. In this digital era, the channels to maintain communication are as numerous the people who need them.

If you want to receive occasional updates and follow the progress with a project management tool, make sure the team and project manager are willing and able to use these tools. If you need frequent updates with details along the way, make sure that the project manager knows this and budgets time for these conversations. If the software developers use their own particular process, consider using their tools to ease the process.

Regardless of the exact process and tools of communication being used, your team of developers should be able to provide clear milestones and delivery dates, as well a list of their requirements from you.

As your project and relationship with the firm are coming to an end, determine what type of assistance, if any, you will need once the final project has been delivered. Will you be able to contact the firm once the application is up and running? How many iterations are included in your package? Will you be given the source files once the project is over?

The source files, such as descriptions of your database structures, access to code repositories, login credentials for site hosting, and Photoshop and Illustrator files, are essential to maintaining full ownership of your project. If you hope to make even one slight adjustment to your project in the future, ensure that your contract is transparent about the delivery of the source files upon completion of the project.

Finding the best software development company for your needs should not be taken lightly. In our e-book, “Best Practices for Software Outsourcing,” we elaborate on the factors that your company should take into consideration when looking to contract your project or web application to a software development firm.

At Santex, our software technology professionals abide by the values of participation, trust, passion, and courage when building a relationship with our clients. Our multidisciplinary teams are constructed with the goal of having “the best talent in the right moment,” and our business model prides itself on being able to provide flexible, creative solutions to meet your needs.

Software Outsourcing Santex

Shall we dance?

Our Team member, Luciano Straga, share with us about his passion for dancing. He told us how he manages to combine being a developer and a flexible dancer.

Tell us, when did you start dancing?

Four years ago, in a gym. Nothing professional but oriented to people to lose weight in a funny way; as Zumba today. Definitely, nothing to do with dancing.  After that, I decided to start at a dance academy.

What attracted you the most about the dance?

Totally different from the technical stuff I usually do, I consider myself as a different developer. I love technical things, but I need something that trains my brain in another way. Dancing has become a challenge for our mind, so you make more effort in learning rather than moving.

What is the rhythm that you most like to dance?

I like urban styles, so Hip Hop or Jazz Funk are the dance classes I take.

Have you taken dance lessons?

Yes, of course, I take not less than 5 per week. I try to dance every day. That’s the best part of working remotely in a flexible schema. I love taking classes in Los Angeles, the best place in the world with the best teachers.

When you took classes in Los Angeles, what was your expectation before taking them?

I was afraid to not to be prepared. The classes are design for professionals, so it’s always a challenge. L.A. is the hardest place to train. Luckily, I could make it, but I had to bring my best from minute zero.

What did you learn the most from your L.A. classes?

Taking those classes is the best thing you can do if you seriously like to dance. There you can learn how to take a class. It’s not a game it’s a professional thing. Teachers go incredibly fast, and you have to be extremely concentrated. The choreos are longer than here, and dancers are beasts.

Have you thought about becoming a professional dancer?

Never. I don’t like dance as a profession. I love what I do, and I’m better at software development. However, I train almost like a professional. It is a challenge for me, and I want to dance like a pro.

Do you have any projects related to the dance that you want to share with us?

No, I did not participate in any project. It is just only a challenge for me and a great workout.


Cooking for fun

Our Santex Team Member, Juan Giacosa, tells us about his passion for cooking and preparing meals for his family and friends.

How old were you when you started cooking?

I don’t remember exactly. I know that I started to become more interested in cooking when  I was 17 and had to move to Cordoba.  At my family’s house, my mom was the cook, so I would only prepare food  if she was not around.

What motivated you to start cooking?

The need to feed myself haha. As I said, I was all by myself in Cordoba and  had to take on new responsibilities. As I enjoy eating a good meal, I decided to start doing some research about food preparation and recipes and gave it a try. That Was When I found out that It was not that complicated and decided to start cooking recipes that involved better and more complex techniques.

Have you studied or taken cooking courses?

No, I’ve never studied anything related to cooking in a “professional” way. Everything I know  Is due to practice and reading on web pages and cookbooks.

Do you have a dish that you like to prepare?

More than a dish, I really like to prepare and bake doughs…namely bread, pizza, pasta, croissants, etc. I also love roasting and grilling meat, and recently I’ve grown interest in using vegetables on my dishes.

What do you like most about cooking?

What I enjoy most about cooking is that it allows me to prepare delicious food for the people I love and see them enjoy it. There’s no greater satisfaction for me than knowing they like what I’ve prepared. For me, food is a way of showing appreciation and gratitude. It’s a way of saying “thank you” or “I love you”.

Do you cook only as a hobby or do you plan to carry out a project around the cuisine?

For the time being I only cook for friends, family or acquaintances.I plan on taking my chances in the field at some point in life. It could be managing a food store or opening my house to host culinary events for locals, strangers, friends and whoever finds out about it haha.













Git Basics: Pull Requests

By Agustin Aliaga – Developer at Santex

Git is a powerful version-control system designed to make software development collaboration easy. It can be used for personal (single contributor) repositories, but it really stands out in projects where multiple developers modify the same codebase every day. Multiple branching models can be adopted. However, in most cases, a Pull Request (PR) will be created when a bug fix or a new feature is ready to be merged into the main branch. The PR itself is an attempt to merge specific changes from one branch to another. Let’s explore the Pull Request workflow in detail.

PR Creation

Whenever a PR is created, the following good practices should be considered:

  • Adding a helpful description to the PR that answers the following questions: What is the requirement or bug? Is there a link to the issue (e.g. on JIRA)? How does your code fix it? Is there anything else the reviewer should take into consideration?
  • Making small, consistent and logical PRs: We want our PR to be merged as soon as possible. Imagine how hard it would be to review hundreds of file changes at the same time. If this happens, it is likely that the reviewer won’t even have the time to do it properly. So try to keep it simple and concise.
  • Making sure the PR’s metadata has been set. For example, by assigning the reviewer (to trigger a notification), setting the assignees, adding a label (if needed), etc.
  • Configuring the repo’s branching security settings to keep developers away from self-merging their PRs or pushing to a shared base branch. I recommend enforcing Github’s branching security settings. When a large team of devs is collaborating in the same repo, accidents may happen. A single miss click in a “merge” button can cause terrible headaches. Protecting important branches is something I’d advise most of the times.
  • Avoiding submissions that include unresolved conflicts. Fixing those conflicts shouldn’t be a reviewer’s responsibility. PR creators should dedicate time to solve them either by using Github’s conflict resolution tool (when it’s simple enough) or by using your favorite diff tool locally. You can achieve this by pulling the base branch and merging it into your feature branch. After you pushed it to the remote repo, the PR will automatically update.

Automated tests

If a Continuous Integration system (such as Jenkins, Travis, or CircleCI) is set up, a bunch of hooks can be configured to run unit tests on PR creation. This will allow the team to detect and catch bugs rapidly, as well as prevent conflictive code from being merged. This is a long topic that requires its own blog post, so I’ll just move on to the following stages.

Code Review

After everything related to the creation of the PR is dealt with and the CI tests passed, it is time for a code review. Projects tend to have tight deadlines, which sometimes makes code reviews seem like a waste of time by other team members or external agents. Ironically, code revisions actually help to increase productivity and reduce rework because we avoid bad practices in our code and share knowledge between contributors.

Some benefits of implementing code reviews are:

  • Less experienced devs get to learn from their mistakes.
  • Experienced developers consolidate their knowledge as they teach others.
  • A high-quality codebase is ensured.

Humility: a soft skill that matters

Sometimes, as work starts to accumulate and things get tense, some engineers tend to become less aware of their attitude towards their peers. It is always important to avoid egocentric behavior, listen to our co-workers, and moderate our communication when reviewing other people’s work. If we write a PR review in a disrespectful/arrogant manner, we could be damaging the team’s confidence and the work environment.

The “reviewer” role

Ideally, teams should implement peer reviews. This means that anyone should have the required experience and skills to review other’s code. In practice, collaborators regularly have different levels of experience on both the technology used for the project and the codebase itself, including its set-up, architecture, code styling, deployment, etc. In this case, experienced developers should be conducting the reviews and newer team members should be included progressively as they get comfortable with the project.

Merging the PR

After the PR was approved, it’s time to merge it. We have a couple of options to do so. Let’s explore them:

  • Create a Merge Commit (default): This option will merge all the commits from the feature branch plus a new merge commit. This is the safest way to perform the merge, since it is a “non-destructive” operation. The downside of using this option is that since it creates a merge commit to tying together the history of both branches, it pollutes your history tree with multiple “irrelevant commits”.
  • Squash and Merge: This option will “squash” all the commits into a single one. If the PR includes a lot of commits, this could be the way to go. It will make your history tree much cleaner and easier to read in your base branch. Nevertheless, you will lose granularity due to the bigger size of the resulting commit.
  • Rebase and Merge: The “rebase” operation is another way to combine commits from two different branches. This will put your feature branch commits on top of your base branch’s latest commit, and effectively rewrite the commit history. After this, it will perform a fast-forward merge, making it look like all the work was done on the base branch. This is extremely dangerous when the rewritten branch is public and shared with other team members. Generally, the rule of thumb is to keep rebasing operations for private-only branches.




We were talking to Leonel Romero about his magnificent experiences traveling by bicycle. He told us how his desire to cycle began and the places he has visited.


  • How did your interest in traveling begin?

I think I always had it. To visit new and unexplored places and meet new people have always been my favorite things.

Over time (and traveling), I began to understand that traveling is not just about getting away from your routine for a vacation. I know that vacations are the most common trip because most people do not have time or money, or don’t feel comfortable due to safety. Traveling is more a learning experience and an exchange of cultures,  that generates a deeper knowledge of oneself.

  • At what age did you start traveling and what inspired or pushed you to do it?

My first trips were on family vacations, always in Cordoba and sometimes to the Argentine coast or Mendoza to visit family.

As a cyclist or bicycle traveler, I started in 2015. I was 25 years old when I was in Europe for a trip organized by AVEIT, a student organization of the UTN of Córdoba that aims to do a study/tourism trip at the end of the engineering degree. I went to Croatia with a friend and went into a very large sports equipment shop and we bought everything necessary to start what would be my first “adventure”. That time we went from Croatia to Turkey by bike, passing through Montenegro, Bosnia, Albania, Greece, and Bulgaria.

  • Have you ever been in a dangerous situation during a trip?

In regards to security, I think the perception of danger depends on the person. You could be robbed in Cordoba or you could be in a “dangerous” place and nothing happens.

I was robbed twice in Colombia. The first time was an assault on the street in a very touristy place because of being careless. The second time a truck gave us a lift because we were in a very hot region and we did not want to keep going.  We put our bikes on top of the truck. After a while I saw a trainer up there: a guy of about 20 had climbed on top and was sitting there quietly. We continued traveling but were aware of our the unknown travel companion. After 5 minutes I saw him opening a bag so I told the driver and we stopped. The driver got out with a baseball bat and started screaming at the boy. The boy had nothing with him, not even a backpack, or our belongings, so we thought he hadn’t stolen anything and we let him go. He crossed the road in the middle of the field and a motorbike appeared that picked him up and they left.

The we realized, that he had thrown things onto the road and then collected them after. Luckily, we didn’t lose anything important.

  • Which places have you visited and which one did you like most

By bike, I have visited Croatia, Montenegro, Albania, Greece, Bulgaria, Turkey, Bolivia, Peru, Ecuador, and Colombia.

I can’t decide which one I like the most, everywhere has it’s benefits.

  • What advice would you give to someone who want to start traveling by bike?

Don’t be afraid or listen to what they say on TV. Just go out to fulfill your dreams. No matter how cliché it seems, people have to stop saying that they want to do something and just do it!

Code documentation good practices

By Francisco Verastegui – Santex’ Technical Board Member

Code documentation is an important practice of the development process and it’s worth the effort in the long term as the application gets bigger and more complex, letting us save time and minimize the learning curve to understand the functionality of the API, libraries and applications. Here we explain 4 practices that we hope you embrace as part of your development process.

  1. Document your APIs in a simple and concise way

Libraries and APIs are made to be used by people that might not have time to read the code or just might not have access to it, so documentation should reflect your code objectives in a simple (easy to understand) and concise (focusing on the important facts) way.

  1. Keep your documentation code up-to-date

Update your documentation each time you change your code – especially if business rules are affected. Software evolves over time, and so does the code. Therefore it’s important not to start documenting too early in the stages of the code because you might be forced to change it a lot of times.

  1. Focus on the ‘Why’ not the ‘How’

The main idea of this principle is: “Your code documentation should explain the ‘Why’ and your code the ‘How’”.

Good source code can be self-explanatory, but we should give it meaning. So we shouldn’t repeat the how. The following examples explain the same method with different code documentation approaches. The examples are in Java, but we are able to apply these concepts to any other programming language as well.

Example 1

In this case, the code documentation (JavaDoc) just explains the ‘How.’ The context isn’t clear, and neither are the business rules that are the reason of the creation of the method. Basically, the documentation is providing the same information that we could get reading the code.

Example 2

In this example, the method’s JavaDoc focuses on the ‘Why,’ explaining the context and the business rules that support it. It is also important to explain the business reason behind an exception that the method might throw.

Detailed explanation

“When we are editing a recurring series”: This is the context – whether to include it or not will depend on if it is a business-related method or just an ‘isolated’ method like the ones we can find in a utility class (reused by different parts of our code).

“we have to enforce the rule that recurring {@link Order}s can’t exceed a period of more than 24 hours”: This is the main part providing the ‘Why’ because it explains a business rule and the main reason for creating the method. A method can explain, or be supported by, more than one business rule.

“If the remove TIME portion is less than the install TIME portion, then it is safe to assume that the remove date has rolled onto the next day (e.g. June 1st 7PM -TO- June 2nd 3AM, is still a 24 hour period)”: Business rule considerations are important to have a good understanding of the method behavior. To include it or not will depend on the complexity and conditions of the rule we are trying to code.

@throws OrderEditException

– if the order was already deleted by a different user: Explanation of the reason (Why) the method is throwing a specific type of exception. It is recommended to do this for any application business exception.

It is important to realize that it is perfectly possible to understand the meaning and the business implications of the method just by reading the code documentation. This is a key concept for APIs that are public and designed to be reused throughout different projects and applications.

  1. Don’t document trivial code

Avoid documenting getter or setter method (unless it does something business-related), so remove it from your IDE’s auto-generated code template. Avoid documenting simple procedures perfectly explained in reading the code. For example:

As you can, see doing this only makes code harder to read.

Good committing

By Jose Torres – iOS Developer at Santex

People in software development know there are a ton of difficulties a team faces when working on software projects. That’s why best practices were introduced as a way of preventing  common problems that software teams eventually face. Best practices cover many aspects, from the environment setup to the way we write code and produce deliverables. Unfortunately, one aspect usually forgotten or underestimated is the handle of the repository. This usually happens when the team is small – if you are the only member on the team, you are prone to get disorganized. This can dangerously hide other potential issues usually faced when the team grows and you find yourself in complicated situations or flows. As the team increases its size, a lack of good practices will reveal itself and problems will surface.

As engineers, we should understand the importance of doing things right. It shouldn’t matter that our current context shields us from facing complex situations. We have to be prepared for when the context changes and things start to scale. It happens often that engineers have this feeling of “things are working fine,” so therefore the context is “that should mean we are doing things well,right?” Not facing issues in the moment is not a guarantee that things are being done right.

There are many areas of good practices surrounding Software Configuration Management. Let’s focus on some of the best practices when committing code.

When committing code, we are introducing new code changes to our code base. In distributed version control systems, this is done first in our local repository and then the code is applied (“pushed”) to the central repository. There are multiple approaches on how to handle the branching model of a repository, but we will focus only about the committing. It is basically a general rule that a commit in code should reflect an atomic change. This means that it can only be applied entirely, never partially. And, of course, it should not break the build. All build routines and tests should run successfully.

When committing code, we also have to include a commit message. This message is meant to give more information about the code changes that have been introduced. Such a message will last through eternity, and it is our duty to use it wisely.

Image 1: Sample git log

Limit your commit first line (title) up to 50 characters

This is one of the most common suggestions, but it is still forgotten. The first line is treated as the title of the commit. This means it should be brief and concise. It must be no longer than 50 characters, and ideally should not be too short either. This characters length may not be a hard limit, but having it in mind ensures that the author thinks for a moment on how to concisely describe the commit. This helps to get quick contextual information when navigating through the git history and ensures that all clients will display the commit info properly.

Consider a blank line before the description

In order for Git to differentiate the title from the body of a commit, a blank line must be added. Of course, this is only required if we want to add a description. Whether a description is needed or not is up to the author. However, it is a good practice to include a description that adds an explanation of the changes introduced and also some contextual information, like a related ticket number or link.

Include a link related to the issue on Bitbucket/GitHub/JIRA/etc

This is related to the previous suggestion. It is important to have a reference to the source of the request, so we can have more context of the change overall. This should not be part of the title of the commit, but rather part of the description with the full link. If it is a bug fix, requirement, enhancement, etc., most of these are tracked with software development tools that assign them a unique identifier which makes it easier to track development. On one hand, it helps each commit in the repository to have a full reference. On the other hand, it gives visibility to external tools about when, by whom and in which branches the changes are applied.

Write the message using present tense/imperative mode

Finally, the golden rule of committing: all the writing must be done using an imperative mode like [FIX] and not using past tense like [FIXED].

Define a template

Having all of the previous considerations in mind, the team should define a template. After discussing what should be included in the ticket as the description and syntax of the titles, your team will have a clear idea of how they should commit code. Here is a sample I use for my current project:

Image 2: Sample of a git commit structure

All of these good practices will be useful in many situations that software teams often face.

Help during the review process

When doing code reviews, we have to check all of the new code that is introduced. Having a clean commit history with descriptive titles and useful messages helps to understand the reason behind the changes. Also, as the reviewer will have access to the description with a link to an external tool, he/she is able to understand the full context of the change.

Help when handling merge/rebase operations

This is my favorite. Every time we have to deal with rebase operations it is extremely useful to have a clean commit history. This helps to make sure you are moving the right code changes from one branch to another. Without this information, it will be almost impossible to do without having assistance from the original author, which as we know may be impossible sometimes.

Help when writing release notes

At the moment of preparing the release notes, a clean commit history is useful so we can see all changes that are part of our release branch (or any branch we are using to prepare a release).

Help during maintenance

Finally, one of the most important reasons for having a clean commit history is so that we can understand changes that were introduced a long time ago. Often as software engineers, we are in a situation of not understanding why a specific change was made or why a piece of code was originally introduced. A well written commit will bring together all of this information, and will give important insight for the new authors to avoid having side effects when performing a change.

Image 3: Sample of a rebase operation for moving code between branches

There are really a ton of recommendations and conventions for good committing. These were just some of them! These are the ones I think are the most basic and need-to-know, and are based on the official Git Man page1.

Let me know if you have any others you would like to add or suggest.


– [1]

Music that Moves You

Maria Alejandra Diaz tells us about her experience playing the cello in her homeland of Venezuela, and the hopes she has for the future in her new home, Peru.

What made you decide to study music? Was it a personal decision or something your parents made you do?

Honestly, ever since I was little I’ve been very interested in the fine arts. First it was ballet and contemporary dance. Later I took up painting. Now that I’m an adult, I’ve entered the world of what is known in Venezuela – and internationally – as  “El Sistema,” which was founded by maestro Jose Antonio Abreu. His main objective has been to broaden the horizons – culturally and musically – of the country and get the youth interested in music.

My parents were always the first ones to support me in any initiative I may have had surrounding my curiosity for the fine arts. They supported me in developing other skills not just related to academia, although the decision was always mine to pursue such activities. They encouraged me to stick with such activities and not just abandon them further down the road.

Why the cello and not something else? Did you ever consider pursuing other instruments as well?

At first, I was most interested in the violin. My dad took me to see the Children’s Orchestra of Tachira, which is the province of Venezuela where I’m from, so that I could get a better idea of what instruments caught my attention. From that moment on, I decided I wanted to learn to play the violin.

Later, I auditioned for the Youth Orchestra Foundation “Luis Gilberto Mendoza” which was the base from which El Sistema operated. They evaluated aptitude for rhythm and solfege which is the fundamental basis for every musician. They loan out instruments and let you use their facilities until you can raise enough money to buy your own instrument.

When they asked me which instrument I wanted to play, they told me that there were no violins available to loan out, and they only had cellos and trumpets available. Of course, the trumpet was never to my liking, with the mouthpieces and parting of the lips and everything, and therefore I stayed with the cello, which was the best decision I could have made. It is an instrument with a unique sound and accompaniment and is – according to expert opinions – the sound that most resembles the human voice.

Are there musicians in your family?

My great-grandfather, on my mom’s side, had an orchestra called “Filo Rodríguez y Su Orquesta” in the 1940s. He was a trumpeter and the director. One of his sister’s was also an opera singer in a circus in Italy during the same time. My mother played piano, my father participated in the Christmas masses in choirs and playing, and my sister is an opera singer (Mezzo-soprano).

How old were you when you performed at your first recital? Where was it?

They usually recommend that you start studying music at an early age, not only because it’s common knowledge that children pick up new skills more easily, but above all because of the muscle memory that comes with studying string instruments (violin, viola, cello, bass). Starting early helps your fingers develop accordingly. For example, for the case of the violin, it is best that players have thin, not so large fingers. In my case, I started at 14 years old, and I had my debut 3 months after starting at the Pre-Children’s Orchestra in San Cristóbal – Táchira State.  This was, of course, very ironic because of my age, but it was the group that It started at the same time that I entered “the system” and it was for ages 8 to 12. There was already a Children’s Orchestra, so we could not call ourselves the same thing or play the same pieces as them because of the level of difficulty .

Then I moved quickly to the Children’s Orchestra and then to the Youth Orchestra. It was in the latter that I had the opportunity to play as a guest on 2 occasions with the Simón Bolívar Symphony Orchestra of Táchira. A year and a half later, I formally joined that orchestra.

With the Simón Bolívar Orchestra, I had the opportunity to be a soloist and play with musicians of international renown – such as violist Frank Di Polo, pianist Arnaldo Pizzolante, and guitarist Alirio Díaz, among others.

Who are some musicians (past or present) that you admire?

Among the musicians that I admire most are Jacqueline du Pré and Yo-Yo Ma. With rock, I like Apocalyptica, which is a symphonic metal band formed by 4 cellists graduated from a classical music academy called Sibelius. In the beginning, they covered Metallica songs which then made them famous. Also, 2cellos is a duo of Croatian cellists who make versions of songs by Michael Jackson, Guns and Roses, Jimi Hendrix, and more. It’s really fun to listen to them.

How much time do you dedicate to practicing cello?

In Venezuela, I devoted every afternoon to studying and practicing cello. The Foundation had an academic center where they teach classes in rhythm, theory and solfege, harmony and then classes related to each specific instrument taught by a professional – usually members of the Simón Bolívar Orchestra. All of these classes were distributed throughout the week.

In addition to the classes, there were also rehearsals with the Orchestra, which were everyday, Monday through Friday from 6pm to 9 or 10 at night, depending on the difficulty of the work and the time needed to rehearse. If they were complicated pieces to execute, each leader who was a kind of representative of the group of musicians for a particular instrument, would host additional workshops to go in depth and see the synchronization, harmony, solos, and tuning.

It really was a full-time commitment. But when you like what you do, you’re not aware of how much time it takes.

Do you have plans for the future with regard to music?

Since I moved to Peru, I have not been able to continue with music because when I left the country, I didn’t know where I was going to settle down. Also because of economic issues, I had to sell my cello in Venezuela to help my mother with medical treatment. I’ve been checking with friends who still belong to El Sistema to find out if there are organizations like the ones there which can help me with loaning a cello while I save to buy my own, and also where I could resume my classes. In the near future, I hope to belong to another orchestra and continue enjoying this most beautiful form of art.