The Right Tool for the Job
It is important to select the best technologies and tools when building software solutions.
There is no such thing as "one size fits all" when it comes to building software,
as the best tool for the job relies on a multitude of factors, such as the team building the solution,
the existing infrastructure and processes, the hosting environment, the future plan for the software
and of course the requirements.
Existing Infrastructure & Processes
Assuming that your organization already have inhouse infrastructure and processes with regards to developing and
delivering software based products to users, it is essential that the upcoming solution takes these into account,
i.e. by adapting the new soluion to the existing environment or adapt and optimize the existing processes and
infrastructure to the new solution as it is being developed.
We have had success using tools to automate many of the processes regarding the software development and deployment process.
We use tools and processes such as:
- Configuration Mgmt.
Configuration management tools like Puppet and Chef can fully automate server setup, resulting in many hours saved when setting
up multiple environments, i.e. testing, staging, production. Servers being setup in a matter of minutes also makes it very
simple to scale horizontally, by increasingthe number of servers based on the load, while at the same time enforcing a
homogeneous hosting environment.
- Continuous Integration
Continuous Integration servers like Jenkins and Teamcity, make it simple and effective to execute tests and build releases on
every change to the underlying codebase. This ensures higher quality of releases as well as making the build and release
process as automated as possible, which helps avoid big bang releases and instead focuses on incremental improvement of the product.
- Semantic Versioning
When other teams and systems are dependant on a system, e.g. an API, it is important to manage the changes in the software and
communicate these to other parties in a simple and effective manner. We often use a semantic versioning scheme along with descriptive
changelists to ensure that the inevitability of changing software does not result in a bad user experience.
- Cloud Hosting
Depending on hosting requirements, hosting a system (or parts thereof) at a cloud hosting provider such as Amazon or Linode can
provide great cost savings as well as the ability to scale horizontally when needed. That being said it is important to note
that cloud hosting is not a magic bullet, just as your physical hosting infrastructure needs attention, so does a cloud hosting
infrastructure. Furthermore the potential cost savings of utilizing cloud hosting also depends heavily on the ability to, and ease of,
deploying the software, because you have to scale the amount of servers down in times of low activity and up in times of high activity, to
achieve any cost savings compared to physical servers.
- Open Source Software
When building software, there's often little to no reason to reinvent the wheel, meaning the are a multitude of high quality
open source software products, libraries, platforms and frameworks in existence, with very permissive software licenses. We
often utilize these when building sofware solutions simply because they provide great quality at an affordable cost as well
as enabling fast time to market when developers who are familiar with the given platform, can focus on providing value to the end-user.
The Current & Future Requirements
The fact that requirements change is a well known fact in todays software world, where things usually move relatively fast.
Taking that into account from day one, when building a software solution, greatly increases the chance of success, however that
is defined for that particular project.
- Agile Methodologies
Instead og seeing changing requirements as something scary to be avoided, agile software development methodologies embrace
changing requirements as a fact and have processes built from the ground up with that fact in focus. We have had great success
in using both Scrum and Kanban for projects. It is of course important to note that the agile methodologies value doing what
works as opposed to implementing a process because a book says so. In that way, the agile methodologies themselves are constantly