Freek.dev

Dan Hollick created a beautifully illustrated reference manual that explains how the technology behind software actually works.

Read more [www.makingsoftware.com]

The open question, then, is not whether industrial software will dominate, but what that dominance does to the surrounding ecosystem.

Read more [chrisloy.dev]

Here’s an exhaustive list of all the tools Jeffrey Way uses in his daily workflow at Laracasts.

Read more [laracasts.com]

Technical debt is not simply a measure of the specific work needed to repay the debt; it is the additional time and effort added to all past, present, and future work that comes from having the debt in the first place.

Read more [www.oreilly.com]

A nice insight by Basecamp engineer Jonas Downey.

Whatever ownership you have over an individual contribution is immediately forfeited the moment you commit the code. At that moment, the work becomes part of the ever-evolving organism that comprises a software system.

Read more [m.signalvnoise.com]

Bram Van Damme explains the origin of the word "patch" in context of software.

A common misconception is that a software bug is called a bug because of an actual bug – a moth – that got stuck in Harvard University’s Mark II calculator in 1947, and Grace Hopper finding it + taping it inside a logbook. ... What seems to be legit however is the history of the term software patch.

https://www.bram.us/2017/01/24/why-a-software-patch-is-called-a-patch/

Read more

Fred Hébert on his blog:

... sooner or later, people start misinterpreting the original intent and thinking of technical debt the same way you could think about financial debt: a lever to use in order to get something now and then pay the accrued cost progressively over time. This is however not how things feel from the technical person's point of view. ... Rather than focusing on why that is wrong, I want to propose an alternative analogy to describe the reality behind technical debt.

http://ferd.ca/on-technical-debt-shoveling-forward.html

Read more

Estimates are typically a necessary evil in software development. Unfortunately, people tend to assume that writing new software is like building a house or fixing a car, and that as such the contractor or mechanic involved should be perfectly capable of providing a reliable estimate for the work to be done in advance of the customer approving the work. This is pretty attainable by building contractors and auto mechanics, who generally are working with known materials building known things in known ways. ... With custom software, however, a great deal of the system is being built from scratch, and usually how it’s put together, how it ultimately works, and what exactly it’s supposed to do when it’s done are all moving targets.

https://medium.com/@ardalis/the-5-laws-of-software-estimates-fd13af46000b#.94s2f42fz

Read more