Brandon Savage shares some of his thoughts on software development and how creating the spec for the project affects it by basic it on a rule - the 15 Minute Rule.

Since most developers (myself included) are also generally bad at developing good specs, it becomes even more difficult to create such a rule. However, I heard a great adage from someone recently that I thought summed up how developers can see specs nearly perfectly. "If it takes more than 15 minutes to determine what it is that you're building, the spec wasn't done properly".

He suggests that not a single line of code should be developed before the spec is completed and, since developers usually aren't the ones creating the spec, they need to have a clear, concise definition of what's expected before hand.

On his blog today Alan Sorkin has a humorous take on what the difference is between computer scientists, programmers and developers according to where they place their focus.

I have often used those three terms almost interchangeably, yes, even computer scientist. After all, most of us have a degree in computer science, so what does that make us? However, recently I find that those three things have come to take on more and more distinct personalities in my mind. [...] It is difficult to define what each one should be, (it is more of a gut feel rather than a strict delineation) they are very similar (and rightly so), but I am going to attempt to do it anyway.

He splits them up according to a few criteria - how their code looks, how it works and what level their math skills are at. The photos he uses to further define each are pretty dead on too.

In response to one of the constant claims about the Zend Framwork - that it's large and bloated - Juozas Kaziukenas tries to dispel three things that people use to reinforce this belief.

Zend Framework is always considered as being the slow/bloated one. I don't think this is right, so I decided to prove that it's not correct and in fact ZF is as good as other frameworks are. This post doesn't cover any benchmarks though; this is more like a architecture review and some misconceptions disproof.

He counters the following with a bit of logic that makes the points a bit more shaky than they first seem:

• Large installation footprint
• Unnecessary features
• Use more system resources

If you're still not convinced, he offers two other tips to help streamline your Zend Framework install - profiling to find the bottlenecks and using Zend_Application sparingly as it can be a bit of a resource problem.

Jani Hartikainen poses an interesting question on his blog today - is it more correct for a function, having failed at its job, to return a value of throw an exception.

You have created a nice, well written function, but you realize you forgot something: The failure case. What should a function do when it fails? There are two schools for this - the "throw an exception" school and the "return an error value" school. But which of these is the correct approach?

He suggests that this debate has stuck around from the time when there weren't exceptions in several popular programming languages and that returning the value was the only valid way. He touches on what an exception condition is (with a few code examples) and situations where each choice might be the right way to go.

In an opinion piece posted to the php|architect site Marco Tabini suggests that we (as developers) are doing it wrong as we move further and further away from the pragmatic side of programming into the abstract.

No matter how advanced the techniques that we use, there is always something that we could be doing better. [...] Which one is right? The real problem is that the answer to that question is, "yes." That's because it lacks a specific context in which it can be inserted.

He suggests that, in our quest to figure out what the perfect case for any situation, we stop focusing on the practicality of writing applications to accomplish goals. Sometimes it's not about getting the right theory behind the code - sometimes it's just doing it.

In a recent (quick) post to the php|architect site Koen Van Urk reminds us that it's not all about the code, there's planning to consider too.

Sure, it is important to have your code as bug free as possible, well documented and as optimized as possible. It is, however, impossible to achieve this all without prior planning. Good project coordination.

He suggests one of the most useful and reliable forms of planning and defining the requirements for an application - writing them down on a normal piece of paper. Then from there let the ideas flow with things like look and feel, mapping out page structure, etc. Website planning tools are good, but when it comes down to basic prototyping, sometimes there's just nothing better than a pencil and a few sheets of plain white paper.

Brandon Savage has posted his own response to the "don't be afraid of the upgrade" thread that's been going around concerning updating to PHP 5.3. He takes a different approach to the matter, though - one of a bit more caution.

When it comes to open source projects endorsing PHP 5.3 as their one and only PHP platform, I encourage caution. When it comes to open source projects that use PHP, there are three main issues that I believe should be considered before making the leap to PHP 5.3 (or any new release of any new software).

He sees three considerations projects and companies should consider before making the upgrade on their servers - the amount of control you have over the environment, deciding if the upgrade is worth possible backwards compatibility breaks and how much support you want to still provide for the pre-5.3 version(s).

On the php|architect site there's a recent post that splits apart the singletons versus static methods debate that seems to com up every once and a while with a better suggestion - dependency injection.

Much more important than performance is the fact that both static methods and singletons suffer from major drawbacks. When it comes to deciding between the two, you might forgo the benchmark comparison and choose the third-party candidate: dependency injection.

He mentions the "dark side" of both static methods and singletons and how dependency injection can help rid your code of both. Instead of focusing just on the benchmark numbers, DI helps you keep your code more well-structured and "smarter" by scoping things to where they need to be and making them easier to test.

Juozas Kaziukenas has a suggestion for all of those developers (and web applications) out there that are still resting back on their comfort zone of PHP 5.2 - don't be afraid of PHP 5.3, the earlier the adoption the better!

While attending PHPUK conference in London, I noticed how much talk there is about PHP 5.3 and "when to upgrade?", there was even a presentation about that. Because I have been using PHP 5.3 for more than half a year, I decided to share my views on this topic. This topic is very important as the earlier PHP 5.3 is adopted, the sooner second iteration of frameworks can be released (story for Symfony).

He goes through a few of the concerns he's heard about making the move and tries to show things in a PHP 5.3 light and how it can help. He mentions the new features that come with the upgrade, the difficulties of porting over legacy code, package support by some of the major linux distributions and gives a few reasons why you should switch right now.

There's a new post on Lukas Smith's blog where he talks about frameworks, phpBB's decision and building "gold on top of crap".

See the various symfony CMS solutions are an example of how wrong things can go. We now have several solutions whose architectural differences are either cosmetic or simply bad design decisions probably a result of trying to invent things in the small ecosystem of a company project team. So I was very happy to hear then that phpBB will adopt Symfony 2 for their next version. Hopefully this will become a role model for others.

He talks about how several of the popular CMS systems these days have worked harder on their external functionality than on the base (where they need the most work). He also looks towards a future where there are good, solid CMS solutions and leaders will emerge from the pack and provide quality content management for the PHP masses.

There's also some great discussion in the comments of the post with people who both share and disagree with some of Lukas' thoughts.