In this post to his site Christian Mackeprang shares what he calls "Newton’s 3 Laws of Software Craftsmanship" - some guidelines to follow in your development to help make things a bit more sane.

Are there unbreakable laws ruling the process of software development? I asked myself this question while reflecting on a recent project, and the answer leads to many conclusions, some already known and some more revealing.

Scientific laws reflect reality and cannot be broken. They have strong implications onto how we build things. For instance, there is no point in building a car with vertical propulsion once you’ve observed that the law of gravity will prevent your car from drifting into space anyway. But software lives in the logical world. Does it really follow any laws?

He shares his three laws and provides a bit of background for each:

• "Under fixed circumstances, every solution will behave the same way, unless it has been modified."
• "The impact of a technical decision is directly proportional to the size of the project and to how much of it is affected."
• "Every technical decision comes with an implied tradeoff."

He also includes a "how to be mindful" section for each of the laws, giving you both practical and mental tips to help you follow it.

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.

In a new post from the QaFoo blog they talk about a developer's life as a trade-off, the amount of work to put into one technology or approach before deciding it's not worth the trouble and moving on.

At Qafoo, we train a lot of people on topics like object oriented software design, automated testing and more. [...] There is no silver bullet and one of the most important skills every developer needs to hone is to assess possibilities and to find the best trade-off for the current challenge.

He uses personal experience to illustrate the point, a struggle they had with choosing a storage system for their application's data. While one technology seemed to be an ideal fit (Cassandra) the trouble it caused made them fall back to something more reliable. He also talks about another instance where he had to make a decision around using a state machine...or not, because of the overhead and time consumed around it.

One of the most important tasks of a developer is to make trade-offs. They occur wherever you look in your every day life. It is a highly important step to realize and accept this. And it is important to hone that skill. You need to open your mind for new technology and techniques, learn and try them wherever you can. But then you need to step back, analyze the current situation and then find the best trade-off between all possible approaches.

Paul Jones has shared some of his thoughts about framework tradeoffs in his latest post. In it he compares two perspectives about framework use for beginners - either the "get something out there" product approach or focusing on the the long term maintenance of the product.

Phil Sturgeon at his blog, writing about product creators who neither know nor care much about programming as a discipline. [...] Phil’s post focuses on the joyful, proud moments of creation that lead to business success, whether in terms of venture funding or continued sales. In this essay, I want to focus on what happens after that, when that initial creation passes into other hands to be maintained.

Paul talks about how frameworks can allow developers to work "beyond their level" and be more productive than they could be otherwise. He points out that this can create a beginner-level codebase that works "just enough" and then is usually passed off to more experienced developers to update, change and flat out fix issues.

From a financial standpoint, and perhaps even from an economic standpoint, it’s easy to see enabling-via-framework as a positive. Indeed, the product creator may justify his failures of good programming practice by substituting the product popularity and continued rounds of funding as a marker of success. [...] But from a programming practices standpoint, enabling-by-framework too often leads to pain and frustration on the part of the maintenance programmers, who are now saddled with the baggage of an amateur.