Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Medium.com:
10 Modern Software Over-Engineering Mistakes
Oct 19, 2016 @ 12:45:19

In this recent post to his Medium.com site Subhas Dandapani shares what he sees as the top ten modern software over-engineering mistakes developers make in modern application development.

Few things are guaranteed to increase all the time: Distance between stars, Entropy in the visible universe, and Fucking business requirements. Many articles say Don't over-engineer but don’t say why or how. Here are 10 clear examples.

Important Note: Some points below like “Don’t abuse generics” are being misunderstood as “Don’t use generics at all”, “Don’t create unnecessary wrappers” as “Don’t create wrappers at all”, etc. I’m only discussing over-engineering and not advocating cowboy coding.

Points in his "top ten problems" list include:

  • Engineering is more clever than Business
  • Everything is Generic
  • Shallow Wrappers
  • Overzealous Adopter Syndrome
  • In House “Inventions”

Each item in the list comes with a bit of explanation and an image or two where appropriate. There's definitely some things in here that are a bit debatable, but development has and will always have a file line between over-engineering and "just the right amount" of work. The trick is figuring out where that line is for your development work.

tagged: top10 list modern software overengineering engineering mistake opinion

Link: https://medium.com/@rdsubhas/10-modern-software-engineering-mistakes-bc67fbef4fc8#.byuwr484j

BitExpert Blog:
Enforce software layer dependencies with deptrac
Aug 19, 2016 @ 10:54:24

On the BitExpert.de blog there's a new post from Stephan Hochdörfer covering the enforcement of software layer dependencies with the help of the deptrac tool from Sensiolabs.

Deptrac is a tool recently announced by Sensionlabs. It helps you keep dependencies between the different layers in your architecture under better control by providing insight into the current state of the dependencies and warns you when unwanted dependencies get introduced.

He gives the commands to get the tool installed and how to initialize the repository with a default configuration file. He then provides an example using the Adrenaline framework and how the request/response relate to the HTTP handling. He includes the configuration changes to make for these relationships and, finally, how to run the analysis on your code to ensure the dependencies are correct.

tagged: software layer dependencies deptrac sensiolabs

Link: https://blog.bitexpert.de/blog/enforce-software-layer-dependencies-with-deptrac/

SitePoint PHP Blog:
Do PHP and IoT Have a Future Together?
Jul 05, 2016 @ 09:54:23

On the SitePoint PHP blog there's a post from editor Bruno Skvorc wondering if PHP and IoT have a future together. The "Internet of Things" (IoT) is a technology sector that has been growing by leaps and bounds over the past few years as more and more devices become internet-aware and connected.

It’s IoT Week at SitePoint! [...] A whole week of mostly IoT resources on every channel and, yes, that includes PHP. What? “PHP and IoT!? Surely you’re mistaken!”, you must be thinking. No, dear reader. PHP and IoT go well together – better than one might expect.

In this post, we’ll list some getting started resources. Throughout the remainder of the week, we’ll have some amazing hands on posts for you – everything from creating a drinks machine with PHP, to a real life alarm when a door in Minecraft opens (yes, really!) – and that’s just on our channel. Be sure to check out the others, too!

The remainder of the post is then broken down into two sections: hardware and software/tutorials. In each there's plenty of links to articles, libraries, pieces of IoT hardware (low level, not consumer) and various PHP libraries that can help you get integrated quickly.

tagged: future internetofthings iot hardware software libraries listing

Link: https://www.sitepoint.com/do-php-and-iot-have-a-future-together/

Mathias Verraes:
The Repair/Replace Heuristic for Legacy Software
Apr 28, 2016 @ 11:48:06

Mathias Verraes has shared some thoughts about legacy applications and how development should be handled as new features are added and bugs are fixed. He proposes a "heuristic" to keep in mind as you work in your legacy code: the Repair/Replace Heuristic.

Technical Debt is a great metaphor. It shares many analogous properties with financial debt: loans, accrued interest, token payments, bankruptcy… There is a key difference however. We take financial debt with another party. [...] Technical Debt has no measure like money, and no ruleset like Property law, and, more importantly, with Technical Debt there is no other party. The organisation is both the creditor and debtor. [...] In “Managed Technical Debt”, I propose a cheap, imprecise, but surprisingly effective method for mapping and measuring debt. In short, it involves posting stickies whenever progress is impeded by debt, and keep marking the stickies for every incident.

By following this method, you gather together a better overall picture that makes determining the worst debt in your application easier. He proposes using this to follow the Repair/Replace methods: repairing something if it's well architected or replacing it if it's not.

Even when you’re not trying to decide on Repair/Replace — perhaps the decision was already made by others — the process of mapping its history will teach you more about the system and and its design. And one deep insight you learn from temporal modelling.
tagged: legacy code replace repair heuristic software opinion

Link: http://verraes.net/2016/04/repair-replace-heuristic-for-legacy-software/

Christian Mackeprang:
Project delays: why good software estimates are impossible
Apr 15, 2016 @ 12:06:47

Christian Mackeprang has a new post to his site with some of his thoughts on why software estimates are impossible in any realistic project development process.

When you, as a programmer, start a new project, you will often not know full well how to do it, for many reasons. But you are a professional, and you’ve completed similar tasks in the past, so you either try to figure it out, or find someone who can, and ask them how, or just google it.

[...] The problem comes down to the difference between tasks which require a lot of thinking, and routine tasks which you already have some practice with.

He gives an example of solving a Rubik’s cube, how most people take a very long time to figure it out but there are some that can do it in a matter of seconds. He talks about unexpected complexity and how that can blow previous estimates out of the water. He points out that complexity can be cumulative (related to the number of tasks) and the difference between creative and mechanical tasks.

tagged: software estimate project delay impossible opinion

Link: http://chrismm.com/blog/software-estimations-are-impossible/

Christian Mackeprang:
Newton's 3 Laws of Software Craftsmanship
Apr 13, 2016 @ 11:51:11

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.

tagged: threelaws newton software craftsmanship solution decision tradeoff

Link: http://chrismm.com/blog/newtons-3-laws-software-craftsmanship/

Ted Blackman:
Lug-Nut Driven Development (LuDDite)
Mar 21, 2016 @ 11:53:27

In his post on his Medium.com site Ted Blackman looks at something he calls "Lug-nut driven development" (or, shortened LuDDite). He breaks it down into a few different suggestions including "build the whole thing badly" out to "automate stop and start".

These are practices that I’ve applauded myself for doing at the beginning of some projects, and kicked myself for not doing early enough in other projects.

The full list suggests things like:

  • Building a system that goes through the whole flow first (not perfect) then come back and refine
  • Testing as you go instead of coming back at the end and retrofitting them
  • Log everything you can then cut back and refine
  • Plan out the error handling before hand to help make it consistent
  • Be able to "stop" and "start" the system easily

While not all of these are specific to web applications there's some definite helpful advice in here, especially to those starting out on new projects.

tagged: lignut development luddite software suggestion practices

Link: https://medium.com/@belisarius222/how-to-start-a-software-project-ad51373c1510#.nfx206q5v

Toptal.com:
The Art of War Applied To Software Development
Feb 19, 2016 @ 11:17:35

On the Toptal blog there's an interesting post where author Jose F. Maldonado takes the infamous book "The Art of War" and applies several principles to programming and development. He obviously doesn't go through the entire Art of War and relates each section, but he does pick out some good bits and makes some interesting parallels.

If you work in the software industry, it’s likely that you have heard about the divide and conquer design paradigm, which basically consists of recursively splitting a problem into two or more sub-problems (divide), until these become simple enough to be solved directly (conquer).

[...] However, the divide and conquer rule is not the only political strategy that can be applied to software development. Although politics and warfare have little to do with software development, just like politicians and generals, developers must lead subordinates, coordinate efforts between teams, find the best strategies to resolve problems, and administer resources. [...] Detailed below, you will a find a brief list of basic tactics and tips explained in the Art of War. They can probably be applied to your job in the software industry, or any of a number of other industries.

Included in his list of Art of War excerpts are topics like:

  • Time Is Crucial In Any Campaign
  • No Leadership, No Results
  • Teamwork And Motivation
  • Thinking Outside The Box

For each topic there's a reference to a chapter/paragraph location in the book, quotes from that section and his own thoughts on how this relates back to software development.

tagged: artofwar software development parallels opinion programming

Link: http://www.toptal.com/agile/art-of-war-software-development

Ethode.com:
Fixing Spaghetti: How to Work With Legacy Code
Jan 27, 2016 @ 12:09:38

On the Ethode.com blog they've shared some hints for working with legacy code to help you more effectively refactor your way out of the "spaghetti code" you might have right now. These are more general tips and aren't really PHP (or even really web application) specific but they're a good starting place for any refactoring effort.

Legacy code is software that generates value for a business but is difficult for developers to change. [...] The longer this goes on, the more frustrated customers get with the software due to quirky defects, bad user experiences and long lead times for changes. Developers are afraid to make changes due to the "Jenga effect" -- as one piece of code is changed or removed, it often leads to new defects being introduced in the system in sometimes seemingly unrelated places. This compounds into what is known as "technical debt".

They continue on talking about what "spaghetti code" is, how it can happen and some of the warning signs you can use to determine just how far down the rabbit hole you and your code are. They talk about "The Big Rewrite" everyone dreams of but points out that this is almost never a practical path. Instead they offer some good things you can do to help fix the problem: quarantining the problem, refactoring relentlessly, keeping it simple and "doing the dishes" as you go rather than letting the changes pile up.

tagged: legacy code refactor opinion advice fix software development

Link: http://www.ethode.com/blog/fixing-spaghetti-how-to-work-with-legacy-code

Procore Blog:
Evolution of Software Applications
Jan 12, 2016 @ 11:55:19

On the Procore blog there's an excellent article covering their thoughts on the evolution of software applications and the different stages they go through during their development.

If you develop software long enough, you notice patterns. One pattern that isn’t talked about enough is how systems evolve over time.

The software industry is so focused on the flavor of the week that we lose perspective. Most of what is “invented” today was created decades ago. Most problems we face today were solved by someone else.

Software developers don’t have a good understanding of our own history. In the spirit of that, I present to you my take on how software tends to evolve and why.

He starts by defining a term that is used through the rest of the article, software gravity, and illustrates how it relates to development time and complexity. He then gets into describing the seven stages of software evolution as he sees them (starting with zero, naturally):

  • Stage 0: Humans, Paper, and Spreadsheets
  • Stage 1: Simple Script
  • Stage 2: Pile Of Files
  • Stage 3: The Framework
  • Stage 4: Beyond The Framework
  • Stage 5: Modularization
  • Stage 6: Network System

For each of the points he provides an overview of what the application might be like at this stage and what levels the complexity/gravity are at. The post ends by asking about a "Stage 7" and if it even exists, suggesting that it might be an even further abstraction from previous steps.

tagged: evolution software application gravity complexity development time stages

Link: http://devblog.procore.com/dev/evolution-of-software-applications.html