MVP, frameworks, languages and programmers

MVP, frameworks, languages and programmers

So you got your idea, maybe you already have a website hosted or in the cloud. Now you need to execute on that idea. Assuming this idea involves a software project, how do you proceed? Well, I’m going to share an small part on what’s needed to know in order to execute better, or at least with less pain.

Programmers and choices of languages

In order for this software idea to be made a reality you’ll need a programmer. This person (he or she) can be in the form of freelancer, employee, contract etc. Like any other profession, programming tends to be specialized. Like lawyers can specialize in IP, criminal, or whatever, or like doctors specialize in surgery, neurosciences, endocrinology, etc., so do too programmers. For the programmers situation, they can specialize in back-end, front-end, mobile etc. Different that other professions, the fact that someone mainly does back-end, doesn’t prevent them to learn or develop front-end, which can be done relatively quickly. As software is more general in that regard. There will always be specifics, but certainly a neuroscientist Dr. shouldn’t do a heart operation, for obvious reasons. If you think I’m going nowhere, bear with me, because, this distinction among software developers is important and it will affect the execution of your project.

Additionally and different to other professions, software is made in languages. A programmer generally handles two or three languages. That’s it! Not because they can’t learn more, is because they don’t need to. And because it’s software, they can do back-end, front end, and even mobile with one or two of those languages. While there are some limits to each language, those limits are blurry. Normally those languages preferences are completely personal, not technical at all.

Demand for programmers

It is not a secret that people don’t study STEM careers, all around the world. As such, there’s high demand for us geeks. This is a big factor, because it will mean a developer will frequently have several job offers on top of him/her. This is the reality for them: there’s always somewhere else to work. Getting a job is not a problem. We know the real world for other professional activities is not like that, but their world is like that. This reality distortion field makes programmers to chose and pick their jobs.

As you can see, up until now, I’ve only spoke on human factors, because those factors determine how programmers see the world and how they react. Obviously this applies to any person (not just programmers), but for the purpose of your software project, it will be significant.

Depending on the programmer you chose or the one willing to work with you, they’ll propose to do it how they know -naturally-. Warning: remember programming languages are a personal choice, thus the programmer will chose a certain language or framework to deliver your project. Once he/she decides that, your project is married to that technology. AND, if the programmer likes obscure languages, then it might become a challenge for someone else to continue or see that code. This is very important for the mid to long term of any project. Maybe you’ll need to add more people to the team, but those people will need to know that language the initial programmer chose. And since programmers can pick jobs as they wish, it could become a challenge to find one that know how to continue or join the team in your project.

With the previous in mind here are the most popular programming languages:

computing languages

Source: Chargebee

It is no coincidence that we in Mollejuo prefer to work with PHP. It is a powerful language that many programmers know and -some of them- love!

Regardless of the language and framework to be used, do factor in what language and framework your project will be done. You don’t need to learn the framework or how to program, but you should at least have an idea on the tools used to build your app, mainly for management reasons.

One last suggestion:

It is a common practice in software that when someone doesn’t understand or doesn’t like the way it was built, they suggest to rebuild the whole thing. Unless it is a really really really a bad app, don’t do it right away. If necessary, rebuild in phases, or discard that suggestion at all. Request to explain the rationale behind the rebuild, but bad code shouldn’t be a reason, specially if the solution is working fine. ”Bad code” is completely subjective. Rebuilding/rewriting software is not a good idea.

Now you know … on a future post we’ll explore the idea of mobile web vs native.

Image source: 9gag