In her latest post Anna Filina proposes that full test coverage is an impractical way to measure the quality of your software. It can provide a false sense of security, even if the tests are poorly written.

Many developers claim that to achieve high quality software, developers must create automated tests that ensure that all possible execution routes have been covered. This is also known as full path coverage. I will argue that different types of software require different testing approaches and that full path coverage is impractical in almost every case. Too many tests simply create clutter.

She looks at how it's impractical to expect that all tests will be written efficiently or even correctly. Even simple tests are enough to show up on code coverage reports but may only be painting part of the picture. She also notes that not all software can be tested the same way - things like APIs require different testing skills/methods than something like consumer software.

In the end, there are no exact rules on how much to test. The most important thing to keep in mind is that writing tests for the sake writing tests is futile and costly. [...] Focus on building great software. Tests are a tool to make it better. Just don't overdo it.

On the iBuildings blog today there's a post from Boy Baukema about the use of the OWASP ASVS to help provide a framework of questions to ask about your application to help find any application security "pain points."

When a customer commissions Ibuildings for a new application, he usually has plenty of functional demands. [...] And maybe some thoughts have been given to performance metrics, but security? Well… it "needs to be secure". [...] It is said, conveniently enough mostly by software engineers, that building software is perhaps the most complex activity humans have ever undertaken.

He notes that "security is not a checkbox, it's a dropdown" and should be continuously considered continuously through out development. The OWASP ASVS provides a structure that a development group can follow to test the security of their application. It defines 4 types of testing/validation and fourteen other topics to consider.

While ASVS is a wonderful addition, it has it's issues: verification and reporting can take a significant amount of time and validation rules are not specific enough to use the tools and techniques.

If you've ever played the card game "Fluxx" (or are familiar with the ever changing rules behind software development) you can release to this new article from Sebastian Bergmann. He makes a link between the "Star Fluxx" card game and how OOP and encapsulation help make changing things easier.

Star Fluxx is a science-fiction-themed version of Fluxx, "a card game [that] is different from most other card games, in that the rules and the conditions for winning are altered throughout the game, via cards played by the players." (Wikipedia) When I heard the description of the game on the aforementioned episode of TableTop it reminded me of software development projects. Changing business rules and requirements (rules and the conditions for winning), probably sounds familiar to you, too.

He talks about how the game could be implemented effectively in OOP classes and interfaces - and how this structure would make it easier to make changes. A largely procedural codebase, however, would make the task much more challenging. The analogy breaks down a bit when it gets to the competitive nature of the game and how software development should be collaborative instead, but it's still effective.

On Reddit.com a user has asked a question about frameworks versus writing things from scratch - which would provide them with more advantages in the future?

When applying for PHP jobs would it be more advantageous to have made your own software without the use of a framework? I'm starting a portfolio of projects and I'm unsure whether to stick to one framework and learn it well, use a variety of them, or also try building software from scratch. Which would look better to a prospective employer? or does it not matter too much? (considering I'm talking junior roles)

Recommendations from the comments including things like:

• "Making your own software is always a better qualification. Because doing your own frameworks means that you understood the general concept of frameworks. But it doesn't hurt to be familiar with the big ones"
• "It doesn't matter. Show that you know how to write good quality code."
• "Frameworks change, the language doesn't. With a good understanding of the language itself, you should be able to pick up any framework fairly quickly."
• "I think you need to know enough of the underlying language to understand what the framework is doing for you. Typically that comes from folks rolling their own framework for awhile"

Read the rest of the comments (or make your own contribution) on the full post.

Eran Galperin has a new post to his site today talking about the real cost of software development, how it's more than just time spent hands-to-keyboard.

If you are a first-time entrepreneur and likely someone with little experience with software development, the chances of you successfully directing the development of a product on your own, are slim. [...] In software development, too often vision holders hand off a "vision document", i.e. "The Specifications", to a developer and expect him to translate it to the finished product they have in their mind. Most software developers or graphic designers are simply not fit for that role - they do not have the experience, skills or vested interest in transforming your vision to an actual product.

His examples revolve around the idea of outsourcing the development to another group, but a lot of the concepts still apply to in-house development too. He talks some about the idea of "you get what you pay for" when it comes to quality and how much you're willing to pay. He then gets into one of the hardest questions when dealing with development - how to find good developers. He mentions several things that need to be a part of that relationship like trust and good communication.

In a follow-up to his previous article about why languages don't matter, Brandon Savage has a new post (part two) carrying on the theme but getting more into the thought patterns behind language selection and use.

Developers like to think that companies hire developers to write code. But companies do not hire developers to write code; they hire developers to solve problems. They hire developers with the expectation that the developer knows about, or can learn about, the problems of the company, and find a creative solution to those problems at minimal cost.

It is therefore up to the developer to choose what tools they will use to achieve the outcome. The customer doesn't much care what tools the developer uses; they only care that the outcome they desired is achieved.

He goes on to talk about preferences in the tools "used by craftsmen" and why they're less important than the result of the work they create. He notes that languages matter, but only in a certain context - as a piece of a puzzle, a part of a whole to reach an objective of functioning software.

if you're still not using any kind of version control in your development projects, you're really doing yourself (and your fellow developers) a disservice. Lorna Mitchell wants to help nudge you down that road. To do this, she's provided a whitepaper about version control systems - what they are, how they're helpful and some cool stuff you can do with them.

Last week I wrote an email to a client who hasn't yet implemented source control, but who is thinking about it. It turned into rather a long email as I attempted to convey WAY too much information in one long email. After some twitter banter, I repackaged my thoughts into a whitepaper on Source Control entitled You're not using source control? Read This! (PDF, no registration needed).

The whitepaper looks at three different tools - Subversion, git and Mercurial (Hg) - and includes a "sales pitch" you can give to the people involved in your project about how it can help them. There's also a few helpful links included at the end for more information about each piece of software.

Matthew Weier O'Phinny has a new post to his site today sharing the video and slides from his "Beautiful Code" talk from this year's ZendCon conference.

Unusually for me, I did not speak on a Zend Framework topic, and had only one regular slot (I also co-presented a Design Patterns tutorial with my team). That slot, however, became one of my favorite talks I've delivered: "Designing Beautiful Software". I've given this talk a couple times before, but I completely rewrote it for this conference in order to better convey my core message: beautiful software is maintainable and extensible; writing software is a craft.

You can find the slides for his presentation on his site as well.

Matthias Noback has a new post today sharing some of his experiences working with Open Source software, specifically as it relates to this dealings with a "Symfony-friendly environment".

These days, good PHP object-oriented libraries are all around and easily available. To me, it is actually thrilling to be part of this flourishing community, while working with Symfony2 and blogging about the Framework, the Components and their neighbors (like Silex). [...] Still, to me, contributing felt like too big a step to take right now. Until a few weeks ago, when I was looking for something I needed (a PHP client for the Microsoft Translator API) and could not find a decent solution. I decided to make it myself, and share it online.

He shares his "checklist" of steps he followed to get the library up and working (less about the library and more about the process):

• Write the code
• Initialize a Git repository
• Add a composer.json file
• Add unit tests
• Make it open source and developer friendly
• Push your code to GitHub
• Register your project at packagist.org
• Register the Packagist Service Hook
• Versioning
• Continuous integration using Travis CI

He also suggests that, at least at the outset, you skip some of your tests that might rely on external data sources/resources (so the build can start as green on Travis) then coming back and refactoring to mock things out correctly. It might look like an intimidating list for a beginner, but it's a great process to follow to have a robust, effective development/deployment process.

PHPBuilder.com has posted a comparison of three PHP forums (the software to run them) - vBulletin, phpBB and Kunena.

In the past few years, there has been a great increase in the number of websites with user-generated content (UGC). One of the most common Web applications with UGC is a Web forum -- a place where people can share their impressions and opinions on different topics. As forum software is becoming more and more popular, I will compare the three best forum software products written in PHP: vBulletin, phpBB and Kunena.

They go through each of them and talk about what features they offer and some of the pros and cons of each. At the end of the post there's a table laying out each of these in a bit more easy to reference form.