Pro php refactoring

Introduction

Once upon a time, a young CEO, who had just begun his own start-up company, met a young developer
In order to start developing a brand new PHP-based general purpose booking system, a core product of
The company itself. The CEO was coming from an exciting development experience with his own open-
Source PHP booking system. This, based on a procedural (though well-organized) framework and with a
Very low to no use of a good object-oriented architecture, had served its purpose for years with very few
Issues and excellent stability, even attracting unexpected money donations from the users community.
The young CEO and the young developer were about to meet harsh obstacles, considering the
Application was based on the old but resilient PHP41 language, which explains why the object-oriented
Style was not already maturely used across the application’s code. On their way to adding a whole bunch
Of new features to the release, upon which to base the new start-up, the inexperienced CEO and his
Partners decided to develop the new system completely from scratch, thinking that the old code base
Was too rigid and ossified to cope with the pace of the new aggressive features development. The young
Developer was keen (even eager) to start working on a new object-oriented PHP project, and nothing was
On the horizon for a few months. Good process, bad results.
The development team started developing the application building features one by one, with lots of
Discipline and commitment. The main architecture was meant to be the best collection of design
Patterns ever seen and the development process was inspired by the best-known methodologies. The
Old application, in the meantime, was proudly on duty, paying back lots more than it was initially
Thought worth: no signs of instability, no bugs, and no performance issues. It continued converting
Users’

usage into money.
After the first year of development, the company, still stuck in a feature creep that was preventing
The application from being released publicly, decided to collect some real-world feedback. So they
Deployed the application featuring a subset of the final features on a very small subset of customers’ web
Sites, replacing the old web service application. This one, though, was keeping to serve its users and the
Website owner though. The reason to replace it came as much from its defects as from the need for the
New application to meet real-world requirements and get useful feedback from real users. The old
Application was showing no signs of breakdown, though: the company’s ROI had always been in its
Hands until that day.
Another year came and went, and the same development team was on the same project with
Continuing problems with features deployment, development, and requirements, and there was no mass
Deployment yet. Fear of regressions, even just user-perceived ones, was too strong, and the unnecessary
And uncontrolled addition of features had completely distracted them from the real target: stability and
Return of investment. The dismissed application was still in use on most of the customers’ web sites, but
Time had passed, making it very hard for the company to keep itself alive.

Lesson Learned

At the end of the story, the CEO left the company, having never gotten a stable massive deployment,
Young developer having been let free to found his own consulting company months before. The start-up
Project failed, and the new booking system was even removed from the few web sites it had started to be