In the April issue of the PHPArch magazine (also published on her blog), Elizabeth Tucker Long wrote a really interesting editorial piece coining a concept she called Security-Driven-Development. She (quite correctly) identified a problem in the current development community where security has become an after-thought (if it's thought of at all). This isn't a new concept, in fact it's a concept that I and many others have been preaching for quite a while now. However I've been coming to realize that I've had it wrong the whole time. And I think the entire industry is getting it wrong today.

He talks some about the current state of web application development and how, even with more powerful technologies than ever, we still fall short in security testing. He suggests that the current way of doing things - treating security testing as a "throw it over the wall" or "someone else's job" problem - needs to stop. Security needs to be integrated with development and he suggests that managers and developers of open source projects should take the lead.

A few days ago, I posted a video about how to become a better developer. There were a few interesting comments made, but one in particular from the Reddit threadpeaked my interest. So I decided to do a reply.

You can watch the video either in his blog or over on Youtube. He's also included the some of the contents of the Reddit post and a funny (relevant) comic about learning "C++ in 21 days".

I ran into hooks rather simultaneously with two very different frameworks: Code Igniter and Lithium. In both cases I was using a rather nifty hook to handle ensuring that users were properly authenticated and authorized before accessing a page. [...] One day, while messing around, I accidentally turned off the hook configuration within Code Igniter (actually I clobbered a file, and restored the wrong one). Then, things came crashing down in a horrible cacophony of... actually they didn't. Everything kept working: that was the problem.

He shows two solutions he came up with to be sure that his hooks were executed - one for Lithium and the other for CodeIgniter. The Lithium one uses a "_remap" method and the CodeIgniter example uses the magic "__invoke" method to check for an "AUTH_CHECKED" constant that's only defined as a part of his hooks.

I'm no longer entirely dependent on one configuration option or file for my security to function. Should it fail, I've got a secondary check in place; this example of defence in depth allows me to be comfortable with the hooks security system once more.

This is a much more common problem than engineers and architects are willing to admit. Far too often I see someone in charge of writing a piece software worry about how a product works without paying so much as a passing thought to whether it actually works the way people expect it to. The truth is that we are, by and large, stuck in a reality where software somehow equates with automation.

He goes on to talk about how easy it is for us, as developers, to forge head with features and software that may not be useful to the masses. We worry more about solving a problem that may or may not actually be there. He illustrates with the example of a to-do list, providing the automation to make list tracking easier, but no guidance of how the user can make use of it effectively.

I just pushed a example on how to create a Slim framework to github. The idea is that whenever you create a webservice with the Slim framework (which is really simple) you rarely test for failure, the ChaosMonkey class will help you to do just that. When initialized with the AbsoluteChaos plugin it will randomly kill the webservice with exceptions, garbage to the output, or just run the service for you without failure at all.

His plugin does a lot of things right now, but it's easy to extend with your own failure types - like his suggested "networkSleep" or something that could kill the connection to MySQL. He includes a code snippet in the post of how to hook Slim and ChaosMonkey together for some testing fun.

Some of these skills aren't likely to be needed again, any more than most of us need to know how to ride a horse or (sigh) drive a manual-transmission vehicle. But other skills and "lessons learned" may still or again prove relevant, whether developers are banging their heads against legacy systems, coding for new mobile and embedded devices... or other devices and applications we haven't yet thought of. [...] Here's what some industry veterans and seasoned coders think the younger generation doesn't know ... but should.

He's broken it up into a few different sections - one dealing with the lack of general hardware knowledge by a good section of the today's developers, another noting that programming is not the same as software engineering (yes, really). He also touches on the lacking idea of "thinking before coding" and how planning for errors has become less and less of an importance.

One of the most annoying behavior of PHP type hinting feature is triggering error instead of throwing exception when instance type is invalid.

By default, a failure generates a "catchable error" that, thanks to the custom error handling methods PHP includes, can be correctly handled. He includes a snippet of code that defines the errorHandler method that checks the error type for E_RECOVERABLE_ERROR and throws the exception (an ErrorException) if found.

I Spent a little while yesterday investigating why memcached causes problems with multigets returning results and ended up comparing debian vs ubuntu. [...] A larger number of keys than 200 causes memcached to fail to return valid responses, additionally the key length greatly varies the number items you can pull back within a single multiget on Ubuntu, Debian implementation of memcached is able to handle all requests regardless of key length size.

He includes the code for his brief test and the output of the test runs on both Ubuntu and Debian systems. They clearly show the failures on the Ubunut side, with it throwing errors about "memcached_oi_read" and a zero length value returned to recv().

Last night I wrote the info@ email address on a website and asked a questions about their product. They politely responded with two links to their website. This morning however, when I went to visit them, I was greeted with the message above. It's now three hours later and the site is still "experiencing difficulties". [...] This problem can be prevented by business owners insisting on - and paying for - "Best Practices" in their software vendors.

He offers a few suggestions to businesses to help prevent this sort of (catastrophic?) failure for their businesses including having a rollout and rollback plan and having a good set of tests to make doubly sure things work before the code even meets the public.

While the obvious implication of the article is that organizations are not properly equipped/trained/prepared to tackle these large software development projects and therefore eventually fail. Especially early in my career, I tried to tackle problems and ideas that simply weren't reasonable or were considered ridiculously complex and far beyond my skills. This is a common problem on software development teams with little real-world experience or hubris in their own skills or both...

He doesn't see the Lines of Code (LOC) metric as particularly useful and backs it up with a few reasons including the overwhelming complexity of large codebases, duplication in functionality from place to place and the amount of "cruft" code that can accumulate in older, less used parts of the code.