Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We have a very large, 10 year old LAMP (Linux, Apache, MySQL, PHP) web application that is out of control and poorly written due to a large number of patches and possible hundreds of programmers.

If we were to do a re-write, what are alternatives to the LAMP stack? One of the reasons behind LAMP was that it's easy to develop and cheap. Now the company can afford to spend more time/effort/money on a new system. I thought about Java or C++ with Oracle? Is there a common 'Enterprise' stack companies use?

Many thanks.

share|improve this question
11  
If you haven't solved the (people) problems that lead to the original code being poorly written, a new dev stack won't help. LAMP is perfectly suitable for enterprise applications, if you haven't experienced any problems with it why switch? –  Yannis Rizos Mar 8 '13 at 15:26
1  
"Is there a common 'Enterprise' stack companies use?" - yes, there are many. IBM, Microsoft, and Oracle all have 'enterprise' stacks. There are others too. Without more detailed requirements and constraints (such as budget, hardware platform, peer system integrations, etc..), I could probably recommend any of them with equally good reasons... –  FrustratedWithFormsDesigner Mar 8 '13 at 15:27
3  
This is not answerable currently. Your actual question is, or should be: What is the best stack for my project? What it was before is not yet the most interesting point. So ask another question or rewrite your question based on good points. Now it is a standard this is old I want new technology which will lead to nothing. Also read about rewriting from scratch, lots of great documentation on that is available. –  Luc Franken Mar 8 '13 at 15:29
1  
Don't forget to consider the learning curve if you're switching to new languages and libraries –  Jan Doggen Mar 8 '13 at 15:36
    
Why would you ever consider C++ unless you are a top 5 website? Even then...I mean even twitter is mostly not C++. If you have a real business requirement to move off lamp that can't be answered by a refactor you need to find the bottleneck other than bad previous design or a technical hurdle. Whether the stack is "common" is a minor requirement next to if it fulfills a true need. –  Rig Mar 9 '13 at 6:35
show 1 more comment

6 Answers

up vote 10 down vote accepted

Congratulations, you've embarked on the single riskiest type of project that is possible.

Complete rewrite, second system, unresolved people problems, lack of technical direction, up front willingness to make it big - any of those are red flags that would cause sane people to run screaming the other way. The only bonus is that it would be hard to pick a worse language than the one you have now.

First we need to set a baseline expectation with some rough figures. On average an "enterprise software development project" upon delivery takes 200% of estimated time, 200% of estimated budget, and delivers 50% of initially promised features. Those aren't the failures - those are the successes. Failure is extremely common, and looks the same as success until the organization pulls the plug because there isn't a working deliverable. That is average. Given the list of red flags that leapt out at me, your baseline expectation should be that you're at severe risk of starting below average.

I wish I was exaggerating. Unfortunately I am not.

You're going to need to start counter-acting that with some positives.

First of all the platform. There are a ton of acceptable platforms that will do just fine for you. If you want to move away from PHP (I'm biased - I would), then I strongly recommend that you embark on pilot programs in different environments to see what works for you. Then go with whatever had the best reception among important stakeholders (including developers!). What you choose will not be more important than whether stakeholders are happy with the choice.

Secondly the feature set. You're building a second system. Your top priority needs to be avoiding second system syndrome. Everyone knows what they do not like in the current system. Everyone has their, "I wish" and "what if" lists. Individually those look great, and they are informed by experience with the first system. But when you pile them all into the second system, it will fail. Therefore someone must be in place to say no to feature requests, and must be ruthless. (Read The Mythical Man-Month for a classic book inspired by an architect of a second system trying to figure out what went wrong.) As a general rule of thumb, on a first system the inexperience shows and a third system generally goes well, but a second system is the most likely to fail.

Thirdly software estimation. Run, do not walk, to pick up Software Estimation: Demystifying The Black Art by Steve McConnell and improve your organization's ability to produce accurate estimates. Very few organizations are any good at it, and improving on this is a top priority before trying to embark on any large project.

Fourth, shy away from the "enterprise" label. In general enterprise software means software that is sold to executives who are disconnected from the actual work. Therefore it possesses excellent marketing and only occasionally technical merit. Oracle would love to get your business. They would definitely make you pay top dollar. But unless you have something specific that you'd gain from them, they don't really have much to offer technically that PostgreSQL doesn't have. And, speaking personally, the largest database that I've seen was a MySQL database at Google. If Google can make it scale to their needs, it can scale to yours. (OK, so Google was able to back it with what was effectively a RAM disk built on top of a redundant array of inexpensive computers. And Google doesn't use MySQL for most of their data storage needs.)

Good luck. Hopefully I scared you. You should be scared. This is definitely a high risk project. But it is not impossible - just very, very risky. A failure to accept, understand, and actively mitigate those risks is a guarantee of failure.

share|improve this answer
    
To be fair it is risky but if a company prepares and plans well it can be mitigated. Having previously solved the business problems and noticed the flaws in the old design plus bringing in experts/training can help mitigate the usual terrible outcome. –  Rig Mar 9 '13 at 6:40
2  
oh no - bringing in "experts" is usually a sure-fire way to make it fail, only later when said experts have milked you for as much cash as they can. Training just means you now have inexperienced developers who now know the basics of the tooling but don't know how to really apply them. btilly said it right all the way, you have to be very much on top of this kind of problem. –  gbjbaanb Mar 9 '13 at 15:11
add comment

Ask yourself why you want to move from LAMP; is it because of deficiencies in the stack, or deficiencies in the practices and design around the original application? Bad code can be written in any environment, from assembler to the most astronautical architectures.

Currently, my company runs a highly scalable set of web services on Linux, nginx, MySQL, and Python; the biggest hurdle has been the problem of poorly written legacy code, not the scalability of any of the aspects of this stack. You could do the same thing in Java, or .NET; it really doesn't matter, as long as you have the expertise in that stack to make it effective.

share|improve this answer
add comment

I don't see any path from this that isn't full of failure - one of the biggest draws of the LAMP stack is that PHP has a lot of libraries, and if the code is already in PHP you're certain that PHP supports anything you need to do.

You can write bad, unmaintainable code in any language, but your choices for "Enterprise" web are basically Python, Ruby, C#, Java, or PHP. The only benefit of moving away from PHP might be moving to a statically typed language - that's one argument I could agree with, but for anything else I don't think there's a strong reason from moving away from PHP as a language.

share|improve this answer
3  
We disagree strongly on this. PHP has a deserved reputation as one of the worst languages out there, and competent devs who care about their language actively seek to avoid PHP. If you want to hire those devs, getting rid of PHP gets rid of a major red flag. –  btilly Mar 8 '13 at 16:57
1  
Then again I'm biased. I have programmed professionally in a variety of languages, and at this point you could not pay me enough to even consider doing anything nontrivial in PHP. –  btilly Mar 8 '13 at 16:58
2  
@btilly Your opinion shows a lot of bias, and is highly dated. PHP programmers tend to be of poor stock, because there are so many of them out there, but there are plenty of excellent PHP programmers and PHP is a powerful language equal to Python or Ruby and with better support and far wider adoption. –  Jonathan Rich Mar 8 '13 at 17:04
    
Claiming "bias" is a content-free way to dismiss opinions you do not like. Let me expand. I have professionally written non-trivial code in a variety of languages including VB, Perl, TCL, JavaScript, PL/SQL, C++, Java, Python, and several proprietary languages that you have not heard of. I have experimented with many more. I would, under the right circumstances, work with any of those again. But I would not work in PHP because life is too short to get that irritated with a badly designed language. –  btilly Mar 8 '13 at 17:54
2  
Technically PHP is equal to Python and Ruby - it is Turing complete. But if you think that it offers equivalently strong abstractions, then you're suffering from the blub paradox. See paulgraham.com/avg.html for an explanation. –  btilly Mar 8 '13 at 17:55
show 1 more comment

According to Joel Spolsky - the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.

You say:

poorly written due to a large number of patches and possible hundreds of programmers

That is not the reason. Joel explains all in the following article http://www.joelonsoftware.com/articles/fog0000000069.html

Read it and then think about how you can make what you have better.

share|improve this answer
add comment

Yep, you have a problem - but the solution is not to rewrite!

Now, solutions for actually fixing your problem in a constructive way.. you need to start shearing off layers of the old system and replacing them, that's clear, and that means that you need to maintain compatibility with what you already have. So that sounds like web services (which you can write in any language you like, C++ even).

So, identify which parts of the system can be replaced with a totally independent web service, and start to reduce the complexity of the main system. Then, once its been cut down to a more manageable size you can start to refactor (sorry for using that clichéd word) the codebase to get rid of any irrelevant cruft and replace it with something a little more well-designed. Hopefully you'll be able to see how more modification, maybe replacing larger parts of the main system with better-written code would then help more.

And once you've done that, chances are you'll have a maintainable, extensible system that is a solution.

The trick is: 1. independant components, well designed to a specification and documented as to how to use them and what they do. 2. rework some of the existing code so it still works exactly the same way, but better. This means you'll have to document what its supposed to do. 3. Document it some more - I don't say this because of liking documentation, but because it sounds like there was a general lack of rigour in how the system has been worked on in the past. Hack some code in, hack in some more and you end up with a mess. Force documentation and specifications and you'll have a much better chance of keeping things in line.

share|improve this answer
add comment

First of all, any use of C++ for web development is so incredibly niche as to not even be worth considering. If you're asking "what language should we use?", then I can guarantee you 100% that the answer is not "C++". That out of the way, as others have said, there are options:

I would say that far and away the two most common choices for enterprise-y web applications are Java (and one of its frameworks) and C#/.NET (probably ASP.NET MVC for a greenfield development, ASP.NET Web Forms for anything that's been in production a while). I find the decision between those two is often largely driven by preferred server OS. Java for Unix, .NET for Windows. You can do Java on Windows but it often makes you sad. You can allegedly run .NET on Unix using Mono but I would recommend against betting your business on it.

Others have mentioned Python and Ruby. My personal experience with these two is little and none. My understanding is that there are quality frameworks for both. My understanding is further that they are not particularly commonly seen at the enterprise end of the spectrum.

Those who have dismissed PHP out of hand have already been accused of bias. I'm biased as well - I dismiss PHP out of hand, and I think you should too. You've already built one absolutely typical PHP trainwreck, don't go out and build another.

Having said all of that, you describe "a very large web application". You mention "possibly hundreds" of programmers having dipped their oars into it over 10 years. I'm going to assume that you have quite a few programmers working there. And I'm further going to assume (possibly inaccurately) that this large PHP application is the main or only thing they are working on, and that therefore, many or most of these programmers do not have any significant large-scale experience with anything other than PHP.

They are not going to built a good "second system" in any other platform.

If you're going to do this thing, you need it to be started off by experienced developers who live and breathe the platform you choose to use. I said above that my personal experience with Python and Ruby is little and none. I could easily learn them and I'm confident I could write good code with them. But if I tried to use a large-scale system as a learning experience, I'm positive I would produce a trainwreck which didn't take 10 years to look as bad as the system you're hoping to replace.

Ultimately, if your company can afford to spend the time, effort and money on a second system (and rewriting a 10-year-old system will be a lot of time, effort and money), you're going to need to spend a fair chunk of that hiring people who have extensive current experience in the platform you select.

share|improve this answer
    
Any explanation for the downvote? Was it because I'm biased against PHP? If so, I'm cool with that. If it was for any other reason, though, I'd be curious to know what it was. –  Carson63000 Mar 9 '13 at 21:45
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.