Paul M. Jones

From Cal Evans:

As developers, most of us are optimists. We look at a problem and say “yeah, I can solve that”. Most of the time, we are right, we can solve that, but not usually in the timeframe we originally estimate.

…

So when we tell a customer/client/family member “Yeah, I can build that this weekend”. In our mind, we mean it. We honestly think the project is simple enough to be built in a weekend. It rarely is though.

…

Remember Clock time !=Calendar time It’s not enough to say “This project will take 2 weeks” if you have other projects you are working on in those two weeks. Make sure you tell your customer/client/family member/boss/neighbor how many hours it will take to accomplish the task, and how long it will take you to slot those hours into your schedule.

To this I would add: Do not estimate in hours. Estimate in days or weeks. If you quote 120 hours and it goes to 144 hours, the client will freak out. If you quote 15 work days and it goes to 18 work days, they’ll be a lot less bothered by it. If you quote 3 work weeks and it goes over by 3 work days, it won’t even register. It’s all the same amount of time, but the framing is different.

And regarding developers being optimists, this is so true. I regularly point out to junior developers that they are insufficiently pessimistic. A highly-intelligent developer finds it easy to rationalize after-the-fact why things didn’t go as planned. Quoting from Modernizing Legacy Applications in PHP in reference to starting a project over from scratch:

Overconfidence, insufficient pessimism, ignorance of history, and the desire to be one’s own customer all lead developers easily into rationalizations that “this time will be different” when they attempt a rewrite.

These are all totally natural behaviors for developers, especially the very talented ones. The mark of an professional is to realize before-the-fact that unforeseeable circumstances are going to ruin your perfect plan, and then to make very broad allowances for the unforeseen. Those are the kinds of practices that embed themselves only with painful experience. I have used a rule of one day per controller method per 2 developers for a long time now, and it has served me well.

Afterword

Are you overwhelmed by a legacy application full of spaghetti includes and global variables? Do you want to improve the quality of the code, but don’t know where to begin or how to proceeed? My new book, Modernizing Legacy Applications in PHP, gives step-by-step instructions on how to get your code under control and keep your application running the whole time. Buy the early access version now and get free updates as it is completed, or sign up on the mailing list below for more information and a free sample chapter.

Read the Reddit discussion about this post here.

I have had several requests for early access to my new book, “Modernizing Legacy Applications in PHP,” as it is being written. I’m happy to say that as of today, that wish is granted. You can purchase the book in its ongoing state at leanpub.com/mlaphp for the low-low price of $39 ($49 recommended).

Once purchased, each new update to the book is free. The book has not yet had the benefit of formal editing, and is only about 35% complete at this point. But at 60+ pages, it already has a ton of valuable material. You can see what I mean by reading the free sample chapter.

After you purchase the book, please feel free to provide feedback! You can reach me on Twitter @pmjones. I’ll do what I can to include suggested improvements in future releases.

You can read more about the book and sign up for the mailing list at mlaphp.com. Also, if you are professional reviewer and want to write a review of the early-access version, be sure to contact me for a coupon to get a review copy.

Read the Reddit discussion about this post here.

Phil Sturgeon at his blog, writing about product creators who neither know nor care much about programming as a discipline:

One of my close friends … is also a businessman, with a startup that is about to launch. …

He does however have literally no interest in becoming a world-class programmer. He barely even wants to code, but he can thanks to frameworks like Laravel.

… He’s written an awful lot of extremely good applications - that work - and that has made him some money. Ship ship ship.

… Does he know what separation of concerns means? Ha.

Is his code SOLID? Nope.

Is the Laravel application he made unit-testable? … no.

Is it going to function well enough to get him to his next round of funding? Absolutely. Is he going to have to throw the whole thing away? Not at all.

Frameworks are great for beginners, who literally could not possibly smash together a series of random components if they wanted to.

Phil’s post focuses on the joyful, proud moments of creation that lead to business success, whether in terms of venture funding or continued sales. In this essay, I want to focus on what happens after that, when that initial creation passes into other hands to be maintained.

The Great And Awful Thing About PHP

The great thing about PHP is that almost anyone can use it. The language and some of the frameworks based on it, such as CodeIgniter and its most-recent ideological descendant Laravel, make amateur and early-career(*) programmers productive in ways they could not be otherwise.

But the great thing about PHP is also the awful thing about PHP, and that is that anyone can use it. The beginner programmer who has been made productive by his framework-of-choice feels great pride and elation at coding an application that “works.” Soon, though, the poor practices embdedded in his work due to his inexperience will find their way through to the product presentation and affect the business. The code “works,” but not so well as first thought. The codebase now has to be maintained in order to remedy the flaws and shortcomings displayed by the product.

If the beginner programmer is the one who has to do this maintenance, and is the one to feel the pain of maintaining his own applications, then he will learn to improve his development practices. If he instead goes on to other responsibilities, he will leave behind what is most likely a mess for others to inherit. Going on to other responsibilities is almost always what happens when the business gets its “next round of funding.”

What Happens After Funding

Phil asks if the business is “going to have to throw the whole thing away” at that point and responds in the negative. Well, of course the business owners won’t discard the codebase. It doesn’t matter how bad the code happens to be, because the entire business is now dependent on it as developed by that original inexperienced programmer. Throwing it out and starting again would likely kill the business. No, what will happen is that the funding will be used to hire a team of more experienced developers to fix, add features to, and scale the code developed by the beginner programmer.

Because they enable amateurs to operate beyond their existing capabilities, frameworks like CodeIgniter and its cousins tend to make product creation easier at the expense of making program maintenance harder. (Note the difference between the concerns of the product and those of the program.) Some folks will argue this does not matter. Once the product owner gets funding, he can pay professionals to deal with the problems he created on the way to his successful round of funding.

If You’re So Smart …

From a financial standpoint, and perhaps even from an economic standpoint, it’s easy to see enabling-via-framework as a positive. Indeed, the product creator may justify his failures of good programming practice by substituting the product popularity and continued rounds of funding as a marker of success. Complaints from the development team about the codebase quality are met with variations of “If you’re so smart, how come you’re working for me?”. But from a programming practices standpoint, enabling-by-framework too often leads to pain and frustration on the part of the maintenance programmers, who are now saddled with the baggage of an amateur.

“Well, that’s their job!” comes the reply. True enough, but that does not change the fact that the codebase is terrible and tough to work with. Think what a team of developers could do with a codebase built with better practices at the time of its creation.

Footnote

(*) If one considers a professional programming career to span 20 years or more, I think it’s fair to say a developer can be considered “early-career” even with as many as 6-7 full-time years of experience in the field.

Afterword

In my 30-odd years of programming (half of that in PHP), I have been the developer in charge of improving a maintenance mess so often that I am now writing a book about how to modernize legacy applications in PHP. In it, I give step-by-step instructions on what to do and in what order. I hope it can reduce the pain that others have to suffer with their own similar codebases. Sign up below for a free chapter, updates related to publication, and more.

Read the Reddit discussion about this post here.

The Aura.Cli package provides the command-line equivalents of web request and response objects. The Context (request-equivalent) object allows insight into the $_ENV, $_SERVER, and $argv values, along with a Getopt object that lets you build and then parse flags and options passed at the command line. The Stdio (response-equivalent) object provides access to to the standard input/output/error streams.

Via .

The Aura.Cli package provides the command-line equivalents of web request and response objects. The Context (request-equivalent) object allows insight into the $_ENV, $_SERVER, and $argv values, along with a Getopt object that lets you build and then parse flags and options passed at the command line. The Stdio (response-equivalent) object provides access to to the standard input/output/error streams.

Via http://auraphp.com/blog/2014/01/11/aura-cli-2beta1/.

Wrapping up this week’s “one release a day” series is the 2.0.0-beta1 release of Aura.Sql_Schema. You can download it directly or install via Composer and Packagist.

The Aura.Sql_Schema package contains PDO-based tools to read table and column information from a database. If you already use PDO, or if your database abstraction layer of choice uses PDO under the hood, you can feed that PDO object to the Schema object and start reading your table and column information. (Because it is typehinted to PDO, this means the Schema can use an Aura.Sql v2 ExtendedPdo object as well.) The package supports MySQL, PostgreSQL, SQLite, and Microsoft SQL Server.

Via Aura.Sql_Schema 2.0.0-beta1 Released.

Our “one release a day” series continues with the 2.0.0-beta1 release of Aura.Web. You can download it directly or install via Composer and Packagist.

Whereas the v1 package included controllers, renderers, and other functionality, the v2 package provides only Request and Response objects... You can read more about the distillation of these concerns into separate packages here.

As a side note, you can see from the timing of these recent releases that Aura libraries are completely independent from each other. There’s no subtree-split or extract-and-build-for-release processing; each library is completely contained in its own repository, making individual releases through our admin script a trivial matter.

via Aura.Web 2.0.0-beta1 Released.

One of the recent problem we can notice is every php framework tries to advertise they are developed from components.

...

The require-dev dependency is when you want to bind other components. The best way is to get rid of the require-dev. The glue package should be another independent package.

...

... learn PHP, and not the magic of a framework. Depending upon the dependencies it will be easy to replace the component. That is the ultimate aim of components, not to trap you.

Emphasis mine. Also this idea from Hari KT: Packagist needs a way to sort dependent packages, independent packages, and framework packages. Via Frameworks Are Good, Components Are Awesome! - Random thoughts | Hari KT.

Continuing our string of library package releases, today we have the 2.0.0-beta1 release of Aura.Router. Given a URL path and a copy of $_SERVER, it will extract path-info and $_SERVER values for a specific route. You can download it directly or install via Composer and Packagist.

The Aura.Router package does not provide a dispatching mechanism. Your application is expected to take the information provided by the matching route and dispatch to a controller on its own. You might do this with Aura.Dispatcher or with some other system of your own devising.

In addition to all the standard stuff like adding routes and generating links, Aura.Router has some added conveniences ...

Via Aura.Router 2.0.0-beta1 Released.

We’re happy to announce the 2.0.0-beta1 release of Aura.Sql_Query. You can download it directly or install via Composer and Packagist.

This is one of the packages that was extracted from the prior Aura.Sql v1 package. There was some demand for keeping the database connection portions separate from the query builder (and other) portions, thus the splitting-up of the original v1 package.

Via Aura.Sql_Query 2.0.0-beta1 Released.