commit: 3acb02670c529237ee4198aa0e2aacc66e3eb9f8
parent 1a2ae243d243f923c483196bc560a72a14dd2a4d
Author: Drew DeVault <sir@cmpwn.com>
Date: Fri, 9 Oct 2020 12:05:24 -0400
Four principles
Diffstat:
2 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/content/blog/Four-principles-of-software-engineering.gmi b/content/blog/Four-principles-of-software-engineering.gmi
@@ -0,0 +1,17 @@
+Software should be robust.
+
+It should be designed to accommodate all known edge cases. In practice, this means predicting and handling all known error cases, enumerating and addressing all classes of user inputs, reasoning about and planning for the performance characteristics of your program, and so on.
+
+Software should be reliable.
+
+It should be expected to work for an extended length of time under design conditions without failures. Ideally, it should work outside of design conditions up to some threshold.
+
+Software should also be stable.
+
+It should not change in incompatible or unexpected ways; if it works today it should also work tomorrow. If it has to change, a plan shall be written. Stakeholders (including users!) should be given advance notice and should be involved in the planning stage.
+
+Finally, software should be simple.
+
+Only as many moving parts should be included as necessary to meet the other three goals. All software has bugs, but complicated software (1) has more bugs and (2) is more difficult to diagnose and fix. Note that designing a simple solution is usually more difficult than designing a complex solution.
+
+=> https://cmpwn.com/@sir/104931806273081351 This (short) article is based on a Mastodon post I wrote a few weeks ago.
diff --git a/content/blog/Four-principles-of-software-engineering.md b/content/blog/Four-principles-of-software-engineering.md
@@ -0,0 +1,29 @@
+---
+title: Four principles of software engineering
+date: 2020-10-09
+outputs: [html, gemtext]
+---
+
+Software should be **robust**. It should be designed to accommodate all known
+edge cases. In practice, this means predicting and handling all known error
+cases, enumerating and addressing all classes of user inputs, reasoning about
+and planning for the performance characteristics of your program, and so on.
+
+Software should be **reliable**. It should be expected to work for an extended
+length of time under design conditions without failures. Ideally, it should work
+outside of design conditions up to some threshold.
+
+Software should also be **stable**. It should not change in incompatible or
+unexpected ways; if it works today it should also work tomorrow. If it has to
+change, a plan shall be written. Stakeholders (including users!) should be given
+advance notice and should be involved in the planning stage.
+
+Finally, software should be **simple**. Only as many moving parts should be
+included as necessary to meet the other three goals. All software has bugs, but
+complicated software (1) has more bugs and (2) is more difficult to diagnose
+and fix. Note that designing a simple solution is usually more difficult than
+designing a complex solution.
+
+*This (short) article is based on [a Mastodon post][original] I wrote a few weeks ago.*
+
+[original]: https://cmpwn.com/@sir/104931806273081351
