How To Choose a Technology For a Commercial Project. Harmful Advice
Tags: leadership, harmfuladvice, career, management
Published: 2017-08-20 00:00:00

---
title: "How To Choose a Technology For a Commercial Project. Harmful Advice"
published: true
layout: post
date: 2017-08-20
location: Austin, Texas
description: About to start a commercial software project? Great, I have some harmful advice for you. Check out if you already follow them.
comments: true
cover_image: https://thepracticaldev.s3.amazonaws.com/i/ttp109slrtok8n5ygmjd.png
tags: [leadership, harmful advice, career, management]
keywords:
  - how to choose a technology for software
  - technical leadership
  - choose software technology
  - choosing a technology
  - commercial project
  - harmful advice
  - bad advice
---

*Originally published on my blog:* [All You Need Is Backend](http://allyouneedisbackend.com/blog/2017/08/01/choosing-a-technology-harmful-advice/).

![Dont Do This](https://cdn-images-1.medium.com/max/1600/1*V1ie5nWIZfW39jfXF_j7lA.png "Dont Do This")

Your company starts a new project. You and the team are excited about that. The current one became boring, smells a bit poorly, and the amount of duct tape across the codebase is monstrous. A good moment to start a new adventure.

The business scope of the new software looks defined, the budget is allocated, and you're eventually asked to pick a technology stack for it: programming language, data storages, frameworks, libraries, development process and so on. You learned all mistakes in a hard way and going to make everything right **this time**.

Are you ready for the new journey? Excellent, I prepared some **harmful advice** for you. Check out if you already follow them.  


<!--more-->

****

**Be trendy!**
All the latest technologies are waiting for you. You already know what's sexy for you. It might be:
* a programming language which you never used but everybody is crazy about
* a brand new NoSQL database released yesterday
* or well-known storage reimplemented with another programming language
* experimental version of the RDBMS which you used for decades; you should build core functionality of your application around these newest features

A bit smaller things also count:
* a new framework implemented on top of existing one; now your HTTP-requests can be processed in a _modern way_
* a library which has the same functions as standard one but performs that in a functional way; _bonus points if your friend wrote the library in a bar_
* new deployment pipeline about which you heard listening to a podcast during morning commute

You are thrilled to try them all in production. Why? <br/> Because using new things is always fun. And you will have something to share with your friend in a bar.

**It's time to build new skills.** Never choose a technology which is a part of the current stack in your company. Because if you do that - you end up with someone teaching you how to do your work. Unacceptable. In The New World of a new project, you need to be The Expert.

Again, you should not have any expertise in the new things before the project. And nobody around you should have it either. It's time to learn and train. Your employer was selected to pay for that.

He (or she) will thank you later and give you a bonus for developing new competencies within a company. Business goals can wait while you're doing that.

**Become a GitHub rock star. At Work.** The technology should have as less ecosystem as possible. Batteries not included. You got it.

It provides you the opportunity to pump your GitHub account, become a maintainer and core player of the rising technology. Do you remember the euphoria in your brain because of pushing code to popular open-sourced GitHub repo? <br/> You were proud of it!

So, if you choose a technology without batteries, the contribution will become a daily routine for your team. And y'all will be paid for that out of the pocket of your employer. Sweet.

It also promotes a good brand for your company across developers community. Win-win-win. If your PM asks you about deadlines or delivery dates - explain to him that you're changing the world. Not with the product, but with code.

 > #### Pro-tip: Suggest him to build a new business offering around the code which you wrote. It might be a perfect time to change the business focus.  

**Be independent.** Corporations want to control our lives. From Oracle and Google to Docker Inc., and JetBrains all of them open source their tools only to make us use them. And after some time we cannot live without the tools: a database, a programming language or a container platform. Eventually, we're dependent on their goals and priorities.

It only looks like they are open to community and everybody can make a difference. Do not trust them. Your project is different from others, and you need to protect it from the bad influence. Spread ['Not Invented Here'](https://en.wikipedia.org/wiki/Not_invented_here) motto within your team.

Yes, now you should build everything from scratch. Need a database? Not a problem, your DBA can implement a prototype over a weekend using the knowledge he got in university 16 years ago. It might not work in production as reliable as your business owner expects. Tell management about the conspiracy of the corporations and you will get buy-in to reinvent the wheel.

**Make your company unique.** Check job openings in your local market. Not for changing a job - you just do not need that since you're starting a new project with the awesome stack. Look for primary required skills in vacancies. You might find something like *Django*, *PostgreSQL*, *Redis*, *Docker*, etc.

Never use the _combination_ of technologies from such list. It's just boring. Only average companies do that. Your business is Different. Select technologies for a new project to make their combination in job description unique and easy to remember. Who notices that a project uses *Django* and *PostgreSQL*? Nobody.

My harmful advice: add a few other web frameworks to your stack. Like *Ruby on Rails*, *Grails*, and *Catalyst*. Yes, each of them is written in a different programming language *Ruby*, *Groovy*, and *Perl* respectively. In addition to *Python* which you already have. Have fun.

Okay, they all might solve the same engineering problem. But now everybody on the market knows your company and the project **because your stack is unique**. And only the best engineers are worth working with you. <br/> Your manager asks you why you still don't have a project team? Not a big deal, you're just waiting for *A class generalists*.

**It's time to raise your StackOverflow karma.** Googling and looking for answers at StackOverflow is an important stage of software development process. We always have a lot of questions how to make something ~~syntactically correct~~ working. If a technology has the [own high-rated tag on the website](https://stackoverflow.com/tags) - it's a bad sign. Even having a tag can be dangerous.

Popular and mature technologies have dozens of people able to answer questions. And it's competitive to be The Expert in such area. You need to pick something unusual or even weird and put this into your tech stack. To be the most qualified person. Ever.

The company will be proud that the highest-rated expert of technology X works for them. No worries if the whole team struggles with essentials while you be gaining your expertize and answering questions from somebody from the Internet. Significant achievements always require sacrificing something. This time itâ€™s a timeline of a project.

**Be the first who talks about that.**
A Software Engineer never stops learning. It's impossible to be competitive if you do not upgrade your knowledge continuously. People learn from watching online courses, meetups, and conferences. Check if some tutoring is available for a technology which you're considering.

If you can find free or paid materials for that - hold off. Find some other technology. You need to be The Expert. Learn from scratch and teach others. Instead of resolving JIRA tickets (or cards on your Trello board). Work can wait.

 You may end up being a bottleneck and only one knowledge owner for the whole team. Or the Whole World. Your boss will recognize your knowledge sharing skills and will push deadlines for the project back. Or even cancel it.

***

That's my list of harmful advice for picking a technology for a commercial project. *Only a commercial one.*

But from educational or personal projects perspective the 75% of the advice is helpful :)

**Do you recognize yourself or your teammates following some of the advice at work?**


**What's your harmful advice for choosing a technology?**

Further reading for y'all from another author: [Choose Boring Technology](http://mcfunley.com/choose-boring-technology)