In a post to his site Matthias Noback looks at an interesting idea when it comes to the structure of your code: the idea of negative architecture and making assumptions.

In "Negative Architecture", Michael Feathers speaks about certain aspects of software architecture leading to some kind of negative architecture. Feathers mentions the IO Monad from Haskell (functional programming) as an example, but there are parallel examples in object-oriented programming. For example, by using layers and the dependency inversion principle you can "guarantee" that a certain class, in a certain layer (e.g. domain, application) won't do any IO - no talking to a database, no HTTP requests to some remote service, etc.

[...] A negative architecture is what's "between the lines". You can look at all the code and describe a positive architecture for it, but given certain architecture or design rules, there's also the background; things we can be sure will never happen.

He goes on to give a few examples of "negative architecture":

• "An object does nothing meaningful in its constructor"
• "An object doesn't also fetch dependencies statically if it also gets any number of dependencies injected"
• "If a class is not marked final, it has at least one subclass"
• "If a property is not marked "private", it's used by at least one subclass"
• "An abstract class won't use methods that aren't part of its published interface"
• "If an object has one public method, it won't have any public static methods"

For each item in the list there's a summary (and sometimes code) included to help clarify the point.

On the Paragon Initiative blog there's a post that suggests changing your thinking about security trade-offs, those concessions we make every day in the development choices we make around the security of our applications versus other concerns.

The theory goes: You cannot have perfect security against all possible threats all the time for free. Usually, we expect our applications to incur a cost (usually in terms of CPU, memory, or electricity usage) in order to be secure. It seems logically correct that, if you need more security, your cost must therefore be higher.

Fortunately, this is not always true! Sometimes, given a choice between two solutions, the more secure option costs less than the insecure one.

The article points out that what we think might be a "fair tradeoff" between two choices may only look as much on the surface. They give the example of random number generation and the speed involved in using the random functions versus the true CSPRNG in PHP 7 (or the compatibility library). The article also points out that even those in the security industry make these same kinds of decisions. Essentially they lesson they're trying to suggest is that trade offs in security are usually based on the wrong assumptions or a limited knowledge of the technologies offered.

And if you reach the point where you have to make a choice between a secure option and an insecure option that might be better by some other metric, make sure you actually document and measure this trade-off. You might find that the benefit of the insecure choice is negligible, and that you therefore should opt for security.

Brandon Savage has posted his latest part of his "Peer Review" series. He takesa step back and looks at abstraction again, this time incorporating some of the suggestions other members of the PHP community gave based on the previous version.

This entry will focus on our use of the database, and specifically on the already_tweeted() method. This method has a number of problems, and while we’re focusing on the implementation of the database, it's important to note that we will also need to address some of the logic (which will be the next part of the series).

He looks at assumptions (how they can be bad), the use of an ORM layer to help negate some of the problems surrounding them and adding in some exceptions to properly handle issues that might come up.

No one's code is perfect, and if you think yours is - you're wrong. There'll always be something - might be logic errors or unhandled exceptions - that could cause issues later on. One of the worst problems, at least according to Keith Casey's recent post, is making too many assumptions.

In my opinion, the most annoying and worst for cleaning up the system are the functions/methods that make too many assumptions for you. It could be a variety of things - assuming a database connection, assuming what the output destination is, or assuming what the input is - but I most often see it in scrubbing/cleaning functions.

His example is a function that not only assumes that the type of input is correct but also returns the value via an echo rather than a return (despite the name of the function implying the second). As a follow-up, he also suggests that libraries/external tools don't make assumptions when it comes to stopping execution of the script either.