Software engineering can be described as the orchestration of a quasi-denumerable set of moving parts.
With so many moving parts, breakages occur. One main goal as a “software craftsperson” is to never expose customers to the affects of these breakages. Test-driven development rose from this desire. Accepting that systems break, even in production, motivated loosely coupled and shared-nothing system architectures.
The topic for this “Software Development Mantras” post is “defensibility.”
First, let me introduce the concept of “TIMTOWDI” (pronounced “tim-toady”). It’s an acronym for “there is more than one way to do it,” and software development may be unique in that for any given task, this holds true.
This is the first in (what may be a series) of posts where I’ll share some concepts, or mantras, that I’ve found helpful in my experiences with software development.
The following are some of the lowest hanging fruit. These should be (but aren’t necessarily) common sense for all software developers: