[HN Gopher] How to move fast and not break things as a remote co...
___________________________________________________________________
How to move fast and not break things as a remote company
Author : irtefa
Score : 79 points
Date : 2022-12-02 14:55 UTC (8 hours ago)
(HTM) web link (jam.dev)
(TXT) w3m dump (jam.dev)
| tinglymintyfrsh wrote:
| We move fast and have guardrails such that breaking things
| permanently is unlikely. All diffs require another engineer to
| sign-off. There is no directly pushing to production without A
| Very Very Good Reason(TM). CI/CD and canarying occurs
| automatically.
| revskill wrote:
| OK, i could expect there's tons of hidden tech debts to be
| discovered as the project goes big.
|
| Expect 1 year to migrate to new services.
|
| But that's another story, because "If it works in production,
| don't touch it".
|
| Not breaking things is only half of story.
| mattpallissard wrote:
| > hours of planning can save weeks of engineering.
|
| This is so hard to get teams to do. I am almost always the
| slowest to implement a change simply because I don't conflate
| design and implementation.
|
| At first glance it looks like I get less done, but when you
| account for the fact that nobody has to clean up after me or
| shoehorn a work around for an edge case in I become one of the
| most efficient.
|
| Assigning cost to subsequent follow up tasks is difficult as
| well. Both technically in terms of aggregating/grouping as well
| as interpersonally because people get defensive or discouraged
| when you're consistently pointing out shoddy work.
| thedg wrote:
| > At first glance it looks like I get less done, but when you
| account for the fact that nobody has to clean up after me or
| shoehorn a work around for an edge case in I become one of the
| most efficient.
|
| That's so awesome.
|
| The Jam dev team recently shipped a major refactor of all the
| state handling in the app a few weeks ahead of schedule and
| that's because the team spent so much time upfront documenting
| and planning the changes. Thanks to Tony Stuck for showing us
| how important doing upfront planning is on the Jam engineering
| team!
| hbrn wrote:
| > The Jam dev team recently shipped a major refactor of all
| the state handling in the app a few weeks ahead of schedule
|
| To me that doesn't sound like a thing to be proud of.
|
| 1. You approved a plan to have a refactor that lasts several
| weeks. Even for big companies that's usually an anti-pattern.
| It even contradicts your own advice of "make things better as
| you go".
|
| 2. You tremendously overestimated the required effort (i.e.
| absolutely failed at planning)
|
| 3. You got lucky this time and two wrongs made a right.
|
| Also, your example suffers from survivorship bias. Of course
| everybody has examples where planning paid off. But there are
| also plenty of examples where planning was a waste of time,
| or where people were following outdated plan for the sake of
| following the plan. "More planning" is a bad advice. A good
| advice helps distinguish areas that benefit from "more
| planning" from areas that will suffer from it. But that is
| hard and nuanced.
| wobbly_bush wrote:
| > Having a daily check in on the project status helps us
| recognize when we are drifting off track and need to make
| decisions about whether to change the date or re-prioritize
| what's in scope
|
| Does daily project status seem excessive? Development can be non-
| linear, so I wonder what decisions are needed to made on a daily
| basis.
| shredprez wrote:
| Daily check-ins don't demand linear progress, do they? I like
| having frequent checkpoints for brief discussion and
| visibility, even if they usually pass without a lot of action.
| musk_micropenis wrote:
| 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 wrote:
| _> 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/
| O__________O wrote:
| Any suggestions for engineering observability?
| _jal wrote:
| 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.
| twh270 wrote:
| 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 wrote:
| 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.
| thedg wrote:
| > 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
| hbrn wrote:
| None of these tips are specific to remote. None are insightful
| either. Write comments, plan better, do things better. Seriously?
|
| Just another google spam blog post to drive traffic.
|
| Btw, if your team goal is "ship to production" (as per
| screenshot), you're probably not moving fast enough.
| AntiRemoteWork wrote:
| drewcoo wrote:
| The whole point of "move fast and break things" was making an
| actual choice instead of trying to do everything badly. This puff
| piece misses the point.
|
| It also doesn't tell us what "fast" is at Jam. We only know that
| it's calendar-driven development with quality gates.
| lucgray wrote:
| Just FYI to the author that the embedded link to try out jam.dev
| in the article doesn't take you to the jam homepage
| thedg wrote:
| Thank you! Updated!
| pfarrell wrote:
| Agree with everything in this blog except the premise
| Move fast and break things
|
| was never about breaking production by being cavalier with your
| code. It means to don't let inertia accrue, don't fail to
| challenge assumptions, don't let fear of pushback prevent you
| from exploring the best course of action.
|
| Way easier to achieve in a small organization.
|
| edit: Did a bit of digging and I may be wrong here. In an
| interview in 2014 [0], when Facebook was changing their motto to
| "move fast with stable infrastructure", Zuckerberg said
| "As developers, moving quickly was so important, we would even
| tolerate a few bugs to do it..."
|
| I've always interpreted like I originally wrote, but that's not
| in sync with being ok shipping bugs.
|
| 0: https://www.cnet.com/tech/mobile/zuckerberg-move-fast-and-
| br...
| deltree7 wrote:
| Exactly, the 'break things' part is there to take the fear out
| of the developer to take more risks. It's complimenting the
| culture of move fast.
|
| Too many orgs don't move fast because of the fear of breaking
| things.
| thedg wrote:
| Interesting! Well you are right - those are great things to
| break!
| hbrn wrote:
| 1. You will never be able to fix all bugs. There's plenty of
| bugs in your software right that that you are simply not aware
| of.
|
| 2. Bug fixing has diminishing returns and exponential costs.
|
| If you accept these two axioms, Zuck's quote makes perfect
| sense.
|
| And certain bugs are simply not worth fixing because cost of
| fixing it is higher than cost of having it.
___________________________________________________________________
(page generated 2022-12-02 23:00 UTC)