In this three-part series, you’ll learn the process of selecting a tech stack for a project.
With every new project comes the requirement of selecting the most appropriate set of technologies to help it succeed.
I’m going to explain the process of determining the best approach to select a client’s technology, mainly a programming language.
Requirements For Most New Projects
Most of the projects with which I am involved are centered around IoT, distributed architectures, services, some sort of web UI and possibly some cool mobile angle.
For most of those projects, these are the architectural considerations that any language/stack candidate must fulfill:
- Support Web Services, potentially Micro-services Design
- Easy Asynchronous Processing
- Ability to Horizontally Scale at the Component Level
- Distributed Design of Smaller Applications
- Ability to Use Containers
- Availability to Connect to External Services (databases, queues, external vendors)
Fulfilling these requirements is only the beginning for the stack candidates. There are still a slew of other avenues to consider.
For the development team, this is not a set of decisions we take lightly because, in addition to the client having to live with our solution for years, we will be on the front lines of that decision for the next several months of development as well as on the follow-up support tasks.
One of the most important considerations outside of whether it can technically do the job is the client’s ability to take over once we’ve gone.
In most cases, the client already has a fully matured IT function (which, to be honest, can actually be a hindrance to the project), and they’ve got approved stacks, trained people, a ton of infrastructure and sometimes even a blacklist of things that are not allowed to be even talked about, much less considered for deployment.
If that’s the case, then our selection process fits neatly within the box with maybe a few “pokes” to see if they’re open for things like Docker, or git, or the cloud, or even TCP/IP (I had a client once that was a staunch Token Ring/SNA proponent).
I define technology baggage as the set of commandments an IT shop has to follow because they were mandated at some point in time. These commandments take the form of “Thou shalt always do…because we always have” instead of “Thou shalt not…”
If the client has no technology baggage or does, but the project in question is not to be part of it – or if it is a startup – then we are off to the races! We can then work with them to see what kind of technology shop they want to build and begin laying the foundation for their future.
If the client has no technology baggage, but a country’s worth of technical debt, then the old “detonate and innovate” approach works best as long as we can do the same overhaul to how the business is expected to interact with the system.
With many of the assessment and improvement projects I get involved with, there typically is some sort of vendor selection, which invariably includes making a vendor viability judgment.
Vendor viability speaks to the ability of the vendor to be able to provide services to meet the requirements as well as their ability to service the client by being able to stay in business or not discontinue whatever product or service we are attempting to engage them with. As you can imagine, picking the wrong vendor can be disastrous for a project.
Determining the viability of a programming language is a bit different. There is no profit/loss sheet to look at since languages, for the most part, are free to download and use. You can’t really call for references because every client has an environment designed to suit their own needs.
They’re solving different problems with different variables, which probably don’t apply to you. In the end, the decision on the most appropriate language can come down to a few basic considerations:
- Ability to solve the problem at hand
- Ability to find or build resources to work in the language
- Availability of training and educational resources for that language
- Support from either the community or another entity dedicated to furthering the languages’ evolution to meet future needs
Now most of these points are self-evident if a language cannot solve the problem, or nobody knows how to build applications in it, or I can’t Google any examples, I’m most likely not going to select it for my project (nor my client’s).
Support is a little trickier though. Back-in-the-day (think 1990), language compilers and interpreters were just another piece of software you bought. Turbo Pascal, QuickC, even BASIC were shrink-wrapped software that came with manuals, floppy disks, and honest-to-goodness telephone support.
Today though, languages are offered for free downloads backed by no one other than the individuals who dreamed it up. Sometimes there are companies backing these languages (e.g. Google for Go, Dart; Ericcson for erlang, Oracle/Sun for Java).
But sometimes it is a foundation or loose collaborations of non-profits that oversee the distribution, updates, bug fixes and future of the language. This arrangement has to be factored into your decision about adopting a language for your stack.
The End Of Life date (EOL, sunset date) for Python 2.7 has been moved five years into the future, to 2020. This decision was made to clarify the status of Python 2.7 and relieve worries for those users who cannot yet migrate to Python 3. See also PEP 466.
This declaration does not guarantee that bugfix releases will be made on a regular basis, but it should enable volunteers who want to contribute bug fixes for Python 2.7 and it should satisfy vendors who still have to support Python 2 for years to come.
There will be no Python 2.8.
Aside from Python 2.7 being a popular language that is generally suited for for a wide variety of problems, I cannot count on it being available long enough to support the life-cycle of most new development efforts. That’s why Python 3 is forced to stand in its place, and based on this, it would need to be evaluated sans its history.