Software Engineering

TL;DR

• “Software engineering” differs from “programming” in dimensionality: programming is about producing code.

• Software engineering extends that to include themaintenance of that code for its useful life span.

• There is a factor of at least 100,000 times between the life spans of short-livedcode and long-lived code.

• It is silly to assume that the same best practices applyuniversally on both ends of that spectrum.

• Software is sustainable when, for the expected life span of the code, we are capable of responding to changes in dependencies, technology, or product require‐ments. We may choose to not change things, but we need to be capable.

• Hyrum’s Law: with a sufficient number of users of an API, it does not matterwhat you promise in the contract: all observable behaviors of your system will bedepended on by somebody

• Every task your organization has to do repeatedly should be scalable (linear orbetter) in terms of human input. Policies are a wonderful tool for making processscalable.

• Process inefficiencies and other software-development tasks tend to scale upslowly. Be careful about boiled-frog problems.

• Expertise pays off particularly well when combined with economies of scale.

• “Because I said so” is a terrible reason to do things.

• Being data driven is a good start, but in reality, most decisions are based on a mixof data, assumption, precedent, and argument. It’s best when objective datamakes up the majority of those inputs, but it can rarely be all of them.

• Being data driven over time implies the need to change directions when the datachanges (or when assumptions are dispelled). Mistakes or revised plans are inevitable.