For many years many people have the exact same concern in mind:
I’m starting this new project, what technology do you believe I should use?
Often these people fit in one of two classifications:
- Technologists who’ve already comprised their mind
- Non-technologist business owners who have to be reassured
A fantastic idea can be constructed with virtually any technology. They all have their pros/cons. No matter what stack you pick, you’ll pay a particular price for whatever benefits it provides. However really, the success or failure of your project has more to do with vision, leadership, execution, and market than technological selections.
When you pick a certain technology, you need to have the ability to justify the choice to yourself, your partners/employees and prospective financiers. You make technical options based upon the project and company’s vision.
For a project to be effective you need to have a strong vision. If you can transform your vision into a set of values to benchmark every choice, your course will be clear and it’ll be simpler to discover the right people to join you.
Besides the vision, a great deal of startups focus on culture. It is frequently said that the culture is specified by the creators, the very first couple of workers, and the product itself. However, what isn’t frequently discussed is that the technical decisions will have a direct result on the company culture.
Whether your new startup is based upon J2EE/Oracle, Perl, PHP, Rails, Node.js or.NET, the group’s engineers will have various expectations, different values, and different concerns. None of these technologies are fundamentally bad. Excellent things have actually been built with each. However they do feature a culture.
This choice clearly set the engineering culture and defined the team of individuals who might work or be interested in dealing with the project.
Asking a Different Question
So maybe instead of asking what technology you need to use, we need to ask ourselves: Does this technology fit my company’s core values?
That’s a much more difficult question since you need to really comprehend your core values. That understanding is key to constructing a successful product.
You cannot thoughtlessly copy a tech stack in the same way you can’t copy a business plan. It’s a part of your company’s identity. Your core values, your goals, your group and your expectations are different.
The entire “it worked for X” argument is rarely valid. Look, Facebook utilizes PHP, it “worked for them”. Does that mean we should all use PHP?
Here are some of the “classics”: languages that have actually been used for a while and have proven their values. They’re widespread, but do not motivate much interest any longer.
- Get stuff done, that’s what matters
- It’s like Basic for the Web
- As long as there is a method to do it, it ain’t broken
- It works and it’s quickly, anything else is pointless
- Do not be too scholastic, our language is accessible and anybody can be begun in no time. Try to do the very same thing with Java!
- Object orientation as an afterthought
Typical use case
- Your first web app
- Extending WordPress/Drupal
PHP had its days of magnificence. It actually made web development simple and easily accessible. Nevertheless, probably due to the actually big amount of new developers who started with PHP and a not so opinionated community, few people can write good PHP. Good idiomatic code examples are difficult to discover and I’m not even sure there is such as as idiomatic PHP. The result is a community understood for poor code quality, absence of tests, security problems and an after taste of the early 2000s.
Strong PHP teams with well developed conventions, processes and guidelines can achieve excellent things, however such groups are uncommon.
- The power & performance of C/C++ however with automatic memory management
- Cares a lot about object-orientation
- IDE needed
- Memory is cheap so we consume all of it
- Threading is the way to go!
- Do not mention Java applets
- Look at my beautiful JVM!
- Open source (however owned by Oracle).
- Slower however more secure development cycles.
Java is quite interesting. A couple of years ago a lot of developers got tired of Java and checked out other lands. They often switched to analyzed languages such as PHP, Python, Ruby or more mystical languages like Erlang.
Nevertheless, Google by means of Android had the ability to show that Java in itself isn’t really as awful as we kept in mind (as long as you don’t have to use J2EE or Swing). There is also a “hipsterish” trend that seems to show that Java is in fact cool once more. A lot of that relates to 2 things:.
- the JVM
- the amazing amount of high quality libraries.
That said, for a great deal of us, composing Java all day doesn’t sound enticing. If you are going to rely on the Java stack, there is long list of other JVM languages which are mature and play well with Java libs (i.e: Scala, Groovy, JRuby, Clojure). You can always to blend and match.
Hiring Java developers isn’t too hard because the majority of students coming out of school found out Java, but discovering fantastic early-stage startup engineers who wish to compose Java is fairly challenging.
Also if you are targeting Android, keep it basic, stick with the official stack even if you may elegant another JVM language better.
There are still many needs to use Java’s technology for your new startup, however you might also consider using a more “rapid/flexible” solution in parallel (Ruby, Python, Node …). A multilingual environment brings a lot of value to both the company and the engineers, which is something the Java community seems to be gradually but surely finding.
Java mainly brings in more classically trained engineers looking for comfy, repeated, well known patterns. They will be utilized to the language, its tools and its natural rhythm. They may not be the most curious developers however they are trusted.
- A much better Java.
- Initially developed for desktop and embedded apps.
- We have a better IDE than the Java individuals.
- We are enterprise serious but we can offer you most of Rails’ cool functions.
- We have a conflicted vision of Open Source.
- Slower but more secure development cycles.
For many years, 2 dynamic languages ended up being valued by start-ups: Python and Ruby. The two languages are in fact fairly similar. These days Python is quite popular for backend apps (NLP, biotech, APIs, SOA elements) while Ruby is more popular for consumer-facing apps. Both of these languages deal with the very same constraints (generally performance and concurrency) but their core values and communities have different focuses.
- Only one evident method to do things.
- Code needs to be beautiful, basic and specific.
- Documentation is vital.
- Strong language design leadership.
In some areas, Python has some of the best libraries out there, and depending on the issues you are tackling, Python might be the right choice. Python developers understand how to communicate about their code. They record what they do and are process oriented while being pragmatic about their techniques.
But Python was created way before the internet became popular and if concurrency and high throughput is a concern for you, a dynamic, analyzed language with bad concurrency might not be the right choice.
Python mainly attracts more pragmatic, experienced, full-stack developers desiring a contemporary but well-proven language.
Ruby/Ruby on Rails
- Created for human beings, not devices.
- Extreme versatility: if you screw up, it’s on you.
- Everything has to be simple, elegant and enjoyable.
- DSL on top of DSLs on top of DSLs.
- Testing is critical.
- Things move quickly, learn how to keep up.
- Passionate and vibrant community.
Rails is really an incredible web framework making many web jobs simple to carry out if you know the best ways to use the tool. But the flexibility and rapid development cycle also have downsides. Be ready to invest a huge portion of your time keeping your code base as much as date and moving away from abandoned libraries. If you cannot count on caching, the throughput of a successful app will commonly be restricted by the lack of excellent concurrency support.
Ruby developers are generally Rails developers and an excellent bulk might have a hard time having the ability to determine core language includes versus framework features. They are frequently curious, opportunistic (in a good way), somewhat pragmatic and care about code quality/structure and test protection. Rails developers are generally early adopters due to that the framework itself uses some new technologies by default (coffeescript, turbolinks, CSS pre-processors).
Ruby and Rails mainly draw in developers wishing to get things done rapidly however elegantly. These developers are commonly product-oriented and care more about the function and customer value than the lower-level computational information.
These are the languages/technologies that get people thrilled. They represent the new wave of programming languages designed to run in “the cloud”.
Node.js isn’t a programming language but it’s the most popular way to run JS server side. The same way most of my comments about Ruby were about Rails, I’ll concentrate on Node more than JS itself.
- Developed for real-time driven apps with high throughput, low latency.
- Small core, the rest depends on the community.
- Coupling is a sin.
- Found out lessons from Ruby/Python.
Event-driven structures have actually been utilized for a while however Node has two major benefits: * most JS libs are non-blocking * a lot of web developers need to write some JS anyhow.
The idea of using the same programming language both in the front end and the back end appeals to numerous, but the value is still unverified.
Node provides fantastic throughput (as long as you stick to IO operations), is easy to obtain started, and is enjoyable to compose. Due to the nature of event-based programming, debugging and testing is challenging. Dealing with callbacks can be maintenance hell.
Node developers are absolutely early adopters and comfortable producing a custom structure/pattern rather than following convention.It draws in developers wanting to use a known language (JS) to manage high levels of concurrency. Node as a framework is lower level than the classical MVCs which is a plus for hackers. Node developers also actually like the idea of using the same programming language on both server and client.
- A practical and contemporary Lisp.
- Everything is data.
- Concurrency, concurrency, concurrency.
- States are evil.
- Excellent Java interoperability.
- A bit on the scholastic side, however still being pragmatic.
- Have the best of both object oriented and functional programming worlds.
- Let the compiler do some of the work for you.
- Concurrency matters.
- Less event than Java, however going for exact same or better performance.
- Reside in consistency with the Java environment.
- A much better C.
- Memory management is handled for you, but don’t be wreckless.
- Explicit is better than implicit.
- Rich built-in functionality.
- Fast. everything (from compilation to execution).
- Concurrency built-in and facilitated.
- Documentation is critical.
Technology Drives Culture
Technical choices have cultural impact. Believe plainly and thoroughly about how your technologies align with your company’s core values. Make the right options and you’ll invest less time combating about technical information and more time building an excellent business.
[blogCall2Action title=”Front-end, Back-end, UI/UX, Design” toptitle=”Geoviz is full stack Java software development” text=”
Let us build a full-stack team that meets your needs. Our flexible structure allows you to scale up with the resources you need, when you need them.
We are driven to help our clients succeed. Our culture is led by our core values and commitment to shipping high quality products.
Let us get to work!” video1=”http://geoviz.co/wp-content/uploads/2015/10/geoviz.mp4″]
[gravityform id=”6″ title=”false” description=”false” ajax=”true”]