Architecture and system design are far more important than your choice of language or anything else.
Picking the “right” language or technology is worthless if you have bad system architecture.
Java is a compiled language (sort of) and as such, is faster than PHP.
However, in-practice PHP is faster on the web (usually).
Because PHP is designed for the web.
PHP frameworks are designed for the enterprise web.
Enterprise solutions are about architecture, not technology or languages.
Letting someone sell you on a language (like Java) without having a full evaluation and discussions about architecture and design is like letting a home builder sell you on buying a house you’ve never seen because his contractors use only the latest and greatest hammer (or sledge hammer in the case of Java EE).
Languages are tools.
You choose tools for the job at hand.
You choose architecture and design for the end goal.
Languages are tools.
That’s it.
Saying a language is not “enterprise” is like saying a hammer can’t be used to build skyscrapers because it is also used to build houses.
I have heard many a misguided MBA-type say something absurd like, “PHP is for mom and pop shops.
” No.
Poor design is for mom and pop.
PHP works just fine in the hands of a trained software engineer who knows how to design for the enterprise.
PHP has no shortcoming that prevents that and in the case of the web, PHP has many advantages over most languages.
If you focus on tools ahead of architecture, you may end up pounding nails with a battering ram (Java) when a hammer (PHP) would have been both sufficient and appropriate.
You will also quickly lose money investing in tools and staff that aren’t necessary.
If you want to build a skyscraper, then design a skyscraper.
Strong enterprise solutions are built with good architecture and design, not with a specific language.
Keep it simple stupid.
To get an idea to market you need a simple, fast, and inexpensive solution that will work now and scale later.
Anything else is to your detriment and can easily result in your eventual demise.
Unless you’re going to have a site the size of Amazon literally the moment you go live, your best solution is strong architecture and PHP (or similar) in a LAMP environment, not a monstrous, bloated Java Enterprise solution.
Build for scale now, but actually scale later.
Don’t let anyone tell you you have to build now with the exact tools you need later because someday you will be the size of Amazon or Facebook (both of which still use PHP and similar languages extensively).
What you need now is to design well and use simple, inexpensive tools.
If you have done your design correctly you will easily be able to scale later.
Facebook started on PHP, is still on PHP, and they look like they scaled just fine.
Wikipedia is PHP, looks like they scaled just fine.
Essential actions for non-technical founders and business owners running web-based businesses…Put your money into architecture first.
This means your first hire is not a run-of-the-mill programmer or your sister’s kid’s friend who is “good with computers.
” Find yourself a well trained computer science professional with experience who talks design and architecture first, code and language second.
Nothing is more disastrous for the long term viability of your web platform than a cowboy web developer who starts banging out code on day one.
I can’t tell you the number of times I’ve heard PMs and managers say, “He’s an awesome developer!” and when I ask why, they say, “He’s fast!” You will feel good about that at first… “Look how fast he is!” Then a year later you will be drowning in technical debt and that “web wizard” is long gone and ruining someone else’s dreams.
Stay technology-lean.
I have seen so many disasters with companies and projects that come right out of the gate with a team of Java Enterprise programmers because someone has sold them on Java’s speed and enterprise capabilities instead of taking the time to really assess their needs and resources.
One local startup I talked to hired 14 Java programmers and support staff to start their company.
They were convinced they needed Java to “compete in the enterprise space.
” That size team is a $2M per year proposition in the US.
They couldn’t afford that so they hired them in India for a total of $100k a year (against my advice).
Long story short, what ensued was a five year disaster that cost the company millions and left them with a bloated, outdated enterprise-level mess.
Even worse, by the time they were done, you know what was the new “right” language for their application?.Python.
They never recovered.
What they needed could have been done with two good LAMP (P could be for Python in this case) developers and one strong architect/developer lead.
That’s a $300k a year proposition that could have gotten their product to market quickly so they could adapt and evolve.
Choose your technical people carefully.
Nothing is more important than this.
In 20 years working in software development I have seen programmers who were geniuses and others that were abysmal, sitting right next to each other, making the same money, with the same titles.
There is no non-technical manager who can tell the difference, and the truth is sometimes technical managers can’t either.
I have seen the worst programmers touted as “the best” simply because they are fast but when you look at their code it’s an unmaintainable mess.
If you are a non-technical founder or business leader and you have to choose programmers, get help.
The person you want advising you has three qualifications without exception: a degree in computer science, extensive experience working as a software engineer, and experience leading software engineers.
They are proven hands-on technologists.
Accept nothing less.
Do not settle for technical recruiters or advisers that have worked in technology but have never written a line of code or designed a system.
They talk a good game, but if they don’t have a Github or Bitbucket account full of code and the education to back it up, they are not who should be advising you.
This post isn’t really about Java vs.
PHP (that was just for a little sensationalism on my part), you could replace those with any similar or analogous technologies for discussion.
It’s about cutting through the hype and remembering to focus on the foundational elements, not the bells, whistles, and glitter.
It’s about staying lean and designing properly.
It’s about remembering that if you want to pound a nail, you could use a bulldozer and explosives, but you should probably just use a hammer and good aim.
.