Frederick Vanbrabant has posted an interesting article to his site covering the "broken windows" theory, what it is and how it shows that some projects are just destined to suck.

Why is it that most legacy software projects are not really fun to work on? How can we stop that greenfield project to turn into one of those dull big projects? I would argue that it’s all in the foundation.

He starts with a brief description of the "broken windows" theory based on the 1982 definition proposed by James Q. Wilson and George L. Kellin. Basically it states that all it takes is one "broken window" to change the perceived value of something, even if it's a small thing. He then gets down to the code level and relates it back to some examples from the Slim framework project. In his examples he shows how it might look after a refactor and how removing best practices makes it harder to understand (breaking windows). To help prevent it, he recommends following the Boy Scout rule of leaving the code better than you found it and using automation to help find and fix the issues.

On Medium.com Dylan Bridgman has posted a tutorial with a few tips helping you improve the perceived load time of your application, the time between when the page starts loading and the user can first do something with its contents.

In this article I will concentrate on perceived load time. That is the time from when a page starts loading until the user is able to proceed. There have been other articles on this topic, some of which go into far more detail in some areas. My intention is to give a summary on the latest information and what you should be doing in PHP. I will link to additional information where applicable.

He breaks the advice up into three main categories: output buffering, multiple connections and using correctly structured pages. Under each section there's a few sub-points with more information, details on implementation and links to other additional information. He also includes an example that combines all of the advice into one PHP/HTML script outputting some basic content.

In his latest post, Padraic Brady takes a look at PEAR in a verb form - both in how you can use it and what sorts of things it has in store.

over the last few months after finally getting over my ignorance of PEAR beyond it being a hodge podge of packages of dubious quality I've been questioning whether pearifying my future and past code is worthwhile. The answer is a resounding YES.

Unfortunately, there are some barriers for most people to get into the PEAR world (including the lack of the "coolest packages") with some of the perceived barriers including:

• PEAR will require large scale changes to my shiny new cool code
• PEAR only allows proposals for complete functional code
• PEAR is elitist
• PEAR is fossilised

He also talks about PEAR packages and dispels one of the most popular myths about the package repository - "you can't use PEAR on a shared host".

In his latest post, Padraic Brady takes a look at PEAR in a verb form - both in how you can use it and what sorts of things it has in store.

over the last few months after finally getting over my ignorance of PEAR beyond it being a hodge podge of packages of dubious quality I've been questioning whether pearifying my future and past code is worthwhile. The answer is a resounding YES.

Unfortunately, there are some barriers for most people to get into the PEAR world (including the lack of the "coolest packages") with some of the perceived barriers including:

• PEAR will require large scale changes to my shiny new cool code
• PEAR only allows proposals for complete functional code
• PEAR is elitist
• PEAR is fossilised

He also talks about PEAR packages and dispels one of the most popular myths about the package repository - "you can't use PEAR on a shared host".