HN Explorer

Guidelines for exploratory programming in a team setting

2 points by schmudde ↗ HN
I'd like to encourage more domain exploration on our small team. A dev in the current flow implements a solution and deploys to production with guardrails (feature flags, admin privileges, etc...).

This has worked well, but has come with two costs:

1. Indicating and managing experimental code in both the pull request and production. 2. Bringing other team members along for the ride.

Both of these issues are mitigated with a more traditional flow of writing up a proposal in English, getting it approved by others, and then going into implementation.

Hopefully the tradeoffs are apparent to this crowd. Any thoughts on mitigating these two specific costs while enjoying the benefits of quick feedback loops?

6 comments

[ 4.5 ms ] story [ 25.6 ms ] thread
Jugurtha
It depends on the size of the team, and how well you run meetings (agenda, specific issues to be discussed, how well these issues are written, precise topics), how large the project is, etc.

You can have a very tight feedback loop (sometimes writing experimental code and coming up with a proof-of-concept during the meeting) if you run a tight ship.

schmudde
The issues we experiment with are usually quite broad - improvements to logging, routing - but the implementation is always more narrow. Still, it seems like there is still more room for more refinement and focus now that you mention it.
sargstuff
A few starter concepts to consider:

==============================

Didn't find relevant HN article(s) covering age / creativity and software productivity and why software engineers tend to be under 30.

   *** Does Creativity Deline With Age? : https://ogg.osu.edu/media/documents/courses/700.04A/pdf/does_creativity_decline.PDF
==============================

-- Miscelaneous blurbs from recent HN posts about software design to keep in mind:

   *** Great scientists follow intuition and beauty, not rationality. : http://www.theintrinsicperspective.com/p/great-scientists-follow-intuition

   *** Software Design is Knowledge building:  http://olano.dev/blog/software-design-is-knowledge-building/

   *** Design leader Dilemma :  http://www.smashingmagazine.com/2024/12/the-design-leader-dilemma/

   *** On design prototyping : https://medium.com/design-bootcamp/on-design-prototyping-fb655e715f29
==============================

-- Different approach methods:

   ** Google 20% rule

      http://www.cnbc.com/2021/12/16/google-20-percent-rule-shows-exactly-how-much-time-you-should-spend-learning-new-skills.html


   ** One-on-Ones as way to figure this out

      http://hypercontext.com/one-on-one-meeting-guide

      http://www.dave-bailey.com/blog/one-on-ones

      http://lattice.com/articles/the-ultimate-managers-guide-to-leading-effective-one-on-ones
==============================

Use "google 20% rule" with employee suggested exploratory ideas/topic(s) from one-on-ones.

schmudde
Yeah - we're doing something like one-on-ones that drive these explorations. Maybe we need to make the "20%" more formal.

The real missing part is discussed in the "knowledge building" link. I'm on board with Peter Naur's idea of building software, but it's very difficult to share individual knowledge with a team as it is being formed.

For example, reading someone's implementation as a work in progress is a different than reading an implementation that is a complete idea.

A work in progress is a lot easier to read with a design document in hand, but that design document that is full of assumptions that might be better explored in short feedback loops on production.

brudgers
To me, this is a social "problem" not a technical one and on the face of it it sounds more like more work than less work for individuals. If that's the case, it is probably dead to everyone who would rather spend their free time away from work than at work.

And if this is not strongly backed by upper management, it is almost certainly dead before arrival.

Of course, you might be upper management (I have no way of telling). Good luck.