Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Pascal Martin:
INI directives are evil!
Apr 28, 2016 @ 12:58:40

In a new post to his site Pascal Martin shares some thoughts about why INI directives are evil, mostly in how they could be used to enable/disable major pieces of functionality in the PHP language.

A few times, while evolutions were discussed for PHP 7, someone suggested a new feature could be optional, depending on an INI configuration directive — the idea being each user could then enable it or not.

Still, the idea of directives that could change, sometimes deeply, the behavior of a programming language… It scares me!

He goes back in time a bit to talk about a feature like this that was once a part of the language (happily removed now): "magic quotes". He points out that, while the intent was to provide security to submitted data, the results were disastrous if it was moved to another server without the setting enabled. He also points out some of the steps that have to be taken when a new directive controlling a major feature is introduced - even worse if you're creating a product to run on other peoples' servers.

In any case, before suggesting "but they could allow us to enable or not this feature with a simple INI directive" for ideas as critical as a weak or strict typing mechanism, ask yourself: do you really want two languages with very distinct behaviors, and applications and libraries that work only on some combinations of configuration values?
tagged: ini directive feature language evil opinion

Link: https://blog.pascal-martin.fr/post/ini-directives-are-evil.html#fn:why-optionnal-feature

Mathias Verraes:
The Repair/Replace Heuristic for Legacy Software
Apr 28, 2016 @ 11:48:06

Mathias Verraes has shared some thoughts about legacy applications and how development should be handled as new features are added and bugs are fixed. He proposes a "heuristic" to keep in mind as you work in your legacy code: the Repair/Replace Heuristic.

Technical Debt is a great metaphor. It shares many analogous properties with financial debt: loans, accrued interest, token payments, bankruptcy… There is a key difference however. We take financial debt with another party. [...] Technical Debt has no measure like money, and no ruleset like Property law, and, more importantly, with Technical Debt there is no other party. The organisation is both the creditor and debtor. [...] In “Managed Technical Debt”, I propose a cheap, imprecise, but surprisingly effective method for mapping and measuring debt. In short, it involves posting stickies whenever progress is impeded by debt, and keep marking the stickies for every incident.

By following this method, you gather together a better overall picture that makes determining the worst debt in your application easier. He proposes using this to follow the Repair/Replace methods: repairing something if it's well architected or replacing it if it's not.

Even when you’re not trying to decide on Repair/Replace — perhaps the decision was already made by others — the process of mapping its history will teach you more about the system and and its design. And one deep insight you learn from temporal modelling.
tagged: legacy code replace repair heuristic software opinion

Link: http://verraes.net/2016/04/repair-replace-heuristic-for-legacy-software/

Cal Evans:
What do developers look for when they scan a job ad?
Apr 28, 2016 @ 09:20:15

Recently Cal Evans took an informal survey of fellow Twitter users and asked them what they thought was most important to see in a job ad for a developer position. In this new post he shares some of the results and responses to the question (with a surprising range of answers).

In my book “Culture of Respect” I have a section on writing job ads that will attract developers. I am in the process of revising that chapter, so I thought I would ask the people who actually read the job ads what they look for. The results weren’t that surprising to me. Having read a lot of job ads though, I am guessing that the results will be surprising to some managers out there.

He's embedded the tweets themselves in the post (straight from the horse's mouth, so to speak). Responses touch on subjects like:

  • salary requirements
  • clear definition of duties
  • less "buzz words"
  • well-defined list of technologies they'll be working with

The results are interesting and a definite must read for anyone coming up with job postings for open developer roles in your company.

tagged: developer job ad posting requirement opinion twitter poll

Link: https://blog.calevans.com/2016/04/20/what-do-developers-look-for-when-they-scan-a-job-ad/

Christian Mackeprang:
Project delays: why good software estimates are impossible
Apr 15, 2016 @ 12:06:47

Christian Mackeprang has a new post to his site with some of his thoughts on why software estimates are impossible in any realistic project development process.

When you, as a programmer, start a new project, you will often not know full well how to do it, for many reasons. But you are a professional, and you’ve completed similar tasks in the past, so you either try to figure it out, or find someone who can, and ask them how, or just google it.

[...] The problem comes down to the difference between tasks which require a lot of thinking, and routine tasks which you already have some practice with.

He gives an example of solving a Rubik’s cube, how most people take a very long time to figure it out but there are some that can do it in a matter of seconds. He talks about unexpected complexity and how that can blow previous estimates out of the water. He points out that complexity can be cumulative (related to the number of tasks) and the difference between creative and mechanical tasks.

tagged: software estimate project delay impossible opinion

Link: http://chrismm.com/blog/software-estimations-are-impossible/

Intracto Blog:
Paying Technical Debt - How To Rescue Legacy Code through Refactoring
Mar 17, 2016 @ 09:36:16

On the Intracto blog there's a new article posted from Jeroen Moons with some suggestions you can use to pay down technical debt in your legacy code through a bit of effective refactoring.

I have good news for you! Squirrels plant thousands of new trees every year by simply forgetting where they leave their acorns. Also: your project can be saved.

No matter how awful a muddy legacy code mess your boss has bravely volunteered for you to deal with, there is a way out of the mire. There will be twists and turns along the way, and a monster behind every other tree. But, one step at a time, you will get there.

He gives lost of different suggestions for things that can be done to "save your code" and make it not only easier to maintain but more flexible:

  • Persuading the customer
  • Don't replace [a huge mess] with a new one
  • Make problems visible
  • Fight what hurts most
  • Build a library

There's plenty more great suggestions here too with some thoughts and methods to back them up and help you accomplish them in your own code. If you're suffering through a large legacy codebase from day to day, I highly recommend reading through this article.

tagged: technicaldebt legacy legacycode rescue opinion method refactor

Link: http://marketing.intracto.com/paying-technical-debt-how-to-rescue-legacy-code-through-refactoring

Paul Jones:
Why Do PHP Developers Think MVC Is An Application Architecture?
Mar 16, 2016 @ 11:49:51

In a new post to his site Paul Jones wonders out loud about why developers think MVC is an application architecture versus just a user interface pattern.

I’ve pointed out before that Model-View-Controller is a user interface pattern, not an application architecture. But why would PHP developers get the idea that MVC is an application architecture in the first place?

[...] I used to think that MVC was an application architecture. Even after reading Fowler’s POEAA and seeing that MVC was for the user interface, I figured that meant I was doing “user interface applications.” But that was not quite right; it would have been more accurate to say that I had been mixing the concerns of user interface with the underlying core application.

He suggests that the reason MVC is commonly thought of as an architecture is because of the "flow" most PHP developers follow in their learning and development practices. Starting from "page scripts" where things are all mashed together, a developer then learns about the separation of concerns and how MVC helps splitting up the application easier. Paul includes a reminder, though, that the "user interface" isn't really just the frontend parts (HTML, CSS, JS) but the HTTP request/response to and from the application.

tagged: mvc modelviewcontroller application architecture progression developer opinion

Link: http://paul-m-jones.com/archives/6288

Toptal.com:
The Art of War Applied To Software Development
Feb 19, 2016 @ 11:17:35

On the Toptal blog there's an interesting post where author Jose F. Maldonado takes the infamous book "The Art of War" and applies several principles to programming and development. He obviously doesn't go through the entire Art of War and relates each section, but he does pick out some good bits and makes some interesting parallels.

If you work in the software industry, it’s likely that you have heard about the divide and conquer design paradigm, which basically consists of recursively splitting a problem into two or more sub-problems (divide), until these become simple enough to be solved directly (conquer).

[...] However, the divide and conquer rule is not the only political strategy that can be applied to software development. Although politics and warfare have little to do with software development, just like politicians and generals, developers must lead subordinates, coordinate efforts between teams, find the best strategies to resolve problems, and administer resources. [...] Detailed below, you will a find a brief list of basic tactics and tips explained in the Art of War. They can probably be applied to your job in the software industry, or any of a number of other industries.

Included in his list of Art of War excerpts are topics like:

  • Time Is Crucial In Any Campaign
  • No Leadership, No Results
  • Teamwork And Motivation
  • Thinking Outside The Box

For each topic there's a reference to a chapter/paragraph location in the book, quotes from that section and his own thoughts on how this relates back to software development.

tagged: artofwar software development parallels opinion programming

Link: http://www.toptal.com/agile/art-of-war-software-development

Davey Shafik:
The Visibility Debate
Feb 16, 2016 @ 10:43:04

Davey Shafik has a post to his site with some of his thoughts about the "visibility debate" - essentially when the different method/property visibility types make the most sense.

A lot has been said about when to use public/private/protected. Some say that you should never use private, while others say you should never use protected.

About the only thing that people can seem to agree on is that public should be used with caution. That your versioning should be based around your public API, and you have a responsibility to maintain that API. The issue is mainly around the maintenance responsibility of protected vs private. Given that other developers can depend upon protected, it can effectively be considered to have the same overhead as your public API.

He shares some of his own reasoning behind how he uses the different levels in his own code. He touches on each of the different levels, sharing when and how he thinks it should be used to keep a well-structured, consistent API for your library or application.

tagged: visibility opinion public private protected api structure consistency

Link: https://daveyshafik.com/archives/69929-the-visibility-debate.html

Ethode.com:
Fixing Spaghetti: How to Work With Legacy Code
Jan 27, 2016 @ 12:09:38

On the Ethode.com blog they've shared some hints for working with legacy code to help you more effectively refactor your way out of the "spaghetti code" you might have right now. These are more general tips and aren't really PHP (or even really web application) specific but they're a good starting place for any refactoring effort.

Legacy code is software that generates value for a business but is difficult for developers to change. [...] The longer this goes on, the more frustrated customers get with the software due to quirky defects, bad user experiences and long lead times for changes. Developers are afraid to make changes due to the "Jenga effect" -- as one piece of code is changed or removed, it often leads to new defects being introduced in the system in sometimes seemingly unrelated places. This compounds into what is known as "technical debt".

They continue on talking about what "spaghetti code" is, how it can happen and some of the warning signs you can use to determine just how far down the rabbit hole you and your code are. They talk about "The Big Rewrite" everyone dreams of but points out that this is almost never a practical path. Instead they offer some good things you can do to help fix the problem: quarantining the problem, refactoring relentlessly, keeping it simple and "doing the dishes" as you go rather than letting the changes pile up.

tagged: legacy code refactor opinion advice fix software development

Link: http://www.ethode.com/blog/fixing-spaghetti-how-to-work-with-legacy-code

7PHP.com:
Happy New Year 2016 Message From Phil Sturgeon To The PHP Community
Jan 04, 2016 @ 10:09:33

The 7PHP.com site is back with their first interview with a member of the PHP community in 2016. In this latest article Phil Sturgeon answers some questions from Khayrattee about his background, how is 2015 was and what he sees coming for the PHP community in 2016.

A little more than over 2 years ago (in June 2013), I did my 34th 7PHP interview with a young dynamic (can very much say as explosive as a dynamite as well – explosive in the good sense) named as Phil Sturgeon. I still remember at that time while I hit the “publish” button and tweeted above that interview, I unconsciously wrote Phil Surgeon instead of Sturgeon. We had a good twitter moment. Time flies and in Feb 2015, I was even able to meet Phil in person at SunshinePHP Conference in Miami.

Phil answers questions about his previous year (2015) and how the PHP community helped him through some issues he had between 2014 and early 2015. He also shares his thoughts on the current state of the PHP community and language. He mentions the difficulties happening around the PHP-FIG group and some of his predictions and advice for the PHP community in the coming year.

tagged: philsturgeon 7php community language interview opinion

Link: http://7php.com/newyear2016-philsturgeon/