C H A P T E R  1

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 PHP4¹ 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 used on and, as of today, the old application is still working undefeated: a few highly-valued features, stability, and a popular users community. It is probably not the best booking system in the world, but it is definitely good enough to provide value to the users' businesses.

Here is the lesson learned: never easily throw away working code. Would you ever throw away money? Well, if you would, call us asap, but it is more likely you wouldn't. Working code deployed in a production environment means money. If it means money it is money. So you're not willing to lose it.

Besides the value directly injected into the code by developers with their own work, the value of a working software hides around a few other corners.

Hidden Gems

The first reason more value lies in an existing working code base than the raw code itself, is about opportunity cost. Opportunity cost, as defined on Wikipedia, is the value of the next best alternative forgone as the result of making a decision.

Opportunity cost is a key concept in economics, first developed by John Stuart Mill in the 18th century, concerning the well-known situation of the choice between many desirable yet mutually exclusive results or goods. “Thus opportunity cost plays a crucial part in ensuring that scarce resources are used efficiently.”

Time is always a scarce resource and so are good developers, good interaction designers, good graphic designers, and technological resources. It's fair to say that everything needed to build a good application is scarce. We can then recognize an opportunity cost saver in everything. A working application saves all of them if we don't need any additional featuress, while it can still save lots of them if we add some new, fancy feature on top of it. Opportunity cost then is the first thing to keep our focus on while valuing a working application.

The second reason a working application could be worth more than we think comes again from the world of economics². Return of Investment (aka ROI) is defined on Wikipedia as “the ratio of money gained or lost on an investment relative to the amount of money invested.” In other words, it is a measure of investment profitability. A less specific definition is this good old adage: a dollar earned yesterday is worth more than a dollar earned today and a dollar earned today is worth more than a dollar earned tomorrow. This means that a working application, providing dollars today, is worth more than an application under initial development expected to provide the same (or slightly higher) amount of money some day in the future.

You Don't Know What You've Got 'til It's Gone

To say it the other way around: we all know the motto “Release early, release often.” Well, having a working application in a production environment to start from is like having a free release at the very beginning of the new project life. This is a strong argument against working code dismissal, which no IT CEO or CTO can ignore.

The CEO and the partners in the brief story at the beginning of this chapter lacked this awareness or, at least, they didn't give it the right weight in making decisions about their new booking web platform. First, after many months, the development team was still struggling to have a clear set of features on the new system, paying the opportunity cost of not improving the old one with the new fancy features the start-up business was meant to be based on. On the other hand, no meaningful ROI was generated for a very long time by the new code base, consuming company back-up resources to the bone until the de facto final death.

We are not saying you should never consider building new software from scratch. Many valid reasons concerning technology, enterprise strategy, or even copyright, can lead to the decision of writing a whole system beginning from the very start. Some situations could then even require flushing the old code base away, and we should be ready to do that.

Our point, though, is to make you consider the option of giving the old working software another chance, given the value you already have within your existing custom applications. We think you should at least consider the waste it would be if you threw it away, since it is free. Besides all this, we want you not to miss the whole point of this book: you can reduce the negative impact of an old architecture while adding new features now and in the future, if you know how to do it. Using the right methodology, the right tools, and the right steps, you can safely bring your old legacy code from a condition of hard maintainability to the right supple architecture, combining the best of two worlds: new cutting edge features on top of a reliable and already operating software.

Call of Duty

For too long the PHP community avoided good software development methodologies, partly due to the easy learning curve, letting many raw coders survive spreading raw code around, partly due to the weak support in older PHP versions for the well-known and mature, though not unique, object-oriented paradigm. It's been years since the release of PHP5, so the time has come to leap ahead and embrace change, adopting techniques and methodologies to ease our everyday work and empower our teams to cope with big and complex enterprise class software.

Does this mean we have to leave our old-fashioned PHP applications behind? Does it mean we have to waste all of our previous effort? Does it mean we have to significantly hurt our income while upgrading our systems? No, not at all. It just means we have to learn how to refactor our code towards a simpler design and a better architecture. The consultant and the CEO in the brief story at the beginning of this chapter were Francesco Trucchia and Jacopo Romei, ourselves. In that experience, we learned that existing software has a great value no one should neglect. After years of managing and developing PHP projects, we want to share a few key concepts about your goal and ours: saving the value of your software. Refactoring is at the center of this methodology. But before we learn how to refactor, let's see how the code can smell bad.