[musk_micropenis]

All great tips. I would add another bullet point along the lines of,

* Make your software observable. Your feature is not finished until you've verified it is being used as expected. Ideally you should have all of the data you need to know if things are going well without having to wait for customers to email you with complaints. Be careful not to develop a culture of developers throwing code "over the fence", either to QA staff or a release team - developers own their code from IDE to production.

If you don't develop this culture of ownership you end up with longer feedback loops between customer support, QA and dev.

[ChrisMarshallNY]

> developers own their code from IDE to production.

That was an important implied Principle of Steve McConnell's famous Software Quality At Top Speed article[0]. In fact, if you read that article, a number of these things resonate.

Not everything good is new. I just think that we forgot them, along the way.

For myself, I generally operate as a one-man shop, so I have the following tips, that work for me:

* Modular Design

I write my stuff in discrete modules, if possible. Sometimes, the modules are source code files, organized by functional realms, other times, they are complete, soup-to-nuts, published and supported SPM modules. The iOS app that I'm writing now, has this current dependency manifest:

    * KeychainSwift: 20.0.0
    * LGV_Cleantime: 1.3.6
    * LGV_MeetingSDK: 2.3.0
    * LGV_UICleantime: 1.1.4
    * RVS_AutofillTextField: 1.3.1
    * RVS_BasicGCDTimer: 1.5.2
    * RVS_Checkbox: 1.2.2
    * RVS_GeneralObserver 1.1.1
    * RVS_Generic_Swift_Toolbox: 1.11.0
    * RVS_MaskButton: 1.2.3
    * RVS_Persistent_Prefs: 1.3.2"
    * RVS_UIKit_Toolbox: 1.3.2
    * White Dragon SDK: 3.4.2

All of them, with the exception of the first one (KeychainSwift), were written by me, and are released, supported open-source Swift Packages.

I also wrote a couple of backend servers, that the app leverages.

* Layered Design

I write stuff in layers; especially server code. Each layer has a loose coupling with the other layers, and also maintains a fairly strict functional domain. This makes it very easy (and less bug prone) to pivot and fix.

* Document As I Go

I write my documentation into the code. I've learned to keep it mostly to headerdoc-style documentation. I write about my process here[1].

I also practice "Forensic Design Documentation"[2], and "Evolutionary Design Specifications"[3]. These help me to move quite quickly, yet maintain a well-structured, well-tested project.

* Test Harnesses over Unit Tests

I find that test harnesses[4] allow me the greatest flexibility, and fastest path to integration testing, which is where I want to be.

* Reduce "Concrete Galoshes"[5]

This is pretty important, and many of the above practices go a long way towards this goal.

I know that the way I do things won't work for many folks; especially teams of less-experienced developers. My experience, coupled with an OCD nature, make it work for me.

WFM. YMMV.

[0] https://stevemcconnell.com/articles/software-quality-at-top-... (It would be great, if he fixed the images in that article, one day).

[1] https://littlegreenviper.com/miscellany/leaving-a-legacy/

[2] https://littlegreenviper.com/miscellany/forensic-design-docu...

[3] https://littlegreenviper.com/miscellany/evolutionary-design-...

[4] https://littlegreenviper.com/miscellany/testing-harness-vs-u...

[5] https://littlegreenviper.com/miscellany/concrete-galoshes/

[niels_bom]

Your comment is more interesting and deep than the article under discussion. Thanks!

[O__________O]

Any suggestions for engineering observability?

[twh270]

The most important thing to do IMO is to make it part of your acceptance criteria or definition of done for any story/feature. My observation is that observability gets ignored if it isn't baked into the culture.

In terms of implementation, if it isn't on a dashboard or doesn't fire off an alert, it doesn't exist. So put your telemetry and logs on a dashboard, and set up alerts based on your SLA's/SLO's.

Also, make it easy for developers to understand, create and edit dashboards/alerts. If it's hard to understand or hard to do, it won't get done.

[fatnoah]

I'll add that incentives can really help as well. Observable software is much more easily operated in production environments, and lets tech ops teams diagnose and fix things with much less involvement from Engineers, which will very much appreciate a much lower escalation rate.

[_jal]

Part of our checklist for new features/services is enumerating what needs to be monitored and how, what instrumentation we should care about, etc.

That may well change during development, but new work doesn't get approved without at least a first stab at how we're going to monitor it.

[tonto]

so your users every click is monitored by you? is that what you mean by observability? rather not do that to my users

[thedg]

> If you don't develop this culture of ownership you end up with longer feedback loops between customer support, QA and dev.

100%, that's great