Fork me on GitHub
jeff tang12:04:22

Hi, does anyone know how RH/Cognitect/Datomic do product development/management? Reading The Mythical Man-Month right now has me thinking about it 🙂


Sorry, this isn't an answer to your question, but on this topic I highly recommend Marty Cagan. See especially those listed under "Most Popular". Several videos of him are also available online, such as

jeff tang13:04:36

Incredible resource. Wish I had this years ago, thanks @U0P7ZBZCK

👍 4

Repl driven company... get the feedback loop to include the customer and the engineer...

Alex Miller (Clojure team)13:04:06

it's not really different than anything else we do. write down your problem as clearly as you can, use tables to investigate alternatives, use pictures to explain designs, etc

🔥 8
👍 4
Chris McCormick02:04:01

i wish this and your comments below was a blog post so i could link people to it. some great insights!

jeff tang13:04:58

That makes sense for the design/architecture piece. I’m wondering more about execution specifics: do you make time estimations? how big is a project/task and how many people collaborate on it? perhaps my initial question was too vague. I’m looking for something more in the realm of Agile, XP, and something more concrete than hammock-driven development 😆

hammock 16
Alex Miller (Clojure team)14:04:35

I'm probably not the best to comment on the details of this, but I'd say as a general thing, it's rare for anything to be driven by time estimations. determining what to work on is a meta version of the process above - what is the most important problem to solve (b/c user needs, market strategy or whatever). come up with a bunch of alternatives for that and examine their tradeoffs, choose a plan, do the work. sometimes that work takes a day, sometimes 3 months.

squirrel 4
Alex Miller (Clojure team)14:04:56

there are only 4 people doing all of the dev on Datomic, Clojure, etc combined so we are a tiny team of very experienced people using high leverage tools. I'm not sure this is directly relevant to most software teams in general (but Clojure projects do probably tend to be more that, and less big teams)

👍 4
Alex Miller (Clojure team)14:04:13

Mythical man month is really from the perspective of someone working on teams of like 50-100 people, which is a totally different world

👍 8
Alex Miller (Clojure team)14:04:13

no matter how big your team is, the important thing is to connect what people are doing with business value. as team size gets bigger, you inevitably are going to spend a lot more time communicating what to do and what has been done, which is inherently less efficient. So bigger teams need to put in more active effort to optimize that communication flow.

Alex Miller (Clojure team)14:04:51

Tools like Clojure and Datomic are designed to let a small team get higher leverage and do more with less, both in initial development AND over time as requirements and software changes (caring about this latter bit is imo something Rich pays way more attention to than most), which lets you stay small and avoid taking the efficiency hit in scaling longer than other tools.

Alex Miller (Clojure team)14:04:28

when you're at the point of talking in person-months, you've already lost agility :)


Regarding time: I was once on a maintenance team where we had to estimate how long it would take to solve a bug before it could be prioritized and worked on. This was practise was instituted in an attempt to stop us from waisting time fixing bugs that would take too long to fix measured against the value the fix would provide. The flaw in this approach is that with a lot of bugs, the majority of the work is figuring out how to reproduce and figuring out what's wrong. This has to be done in order to provide an estimate of how much time a fix would take So a lot of the time, we ended up with Time to deliver estimate: a week Time to implement fix: one hour


We use time estimates, even on bugs, at my work. Sometimes it seems arbitrary and unnecessary, but I try to use it to communicate to Product my mind model on the difficulty of various tasks, and then they'll be able to eliminate unnecessary communication in the future. Especially in a remote work situation, communication is a commodity you don't want to waste. So it's a bit of pro-active / preventative communication. The communication / implementation cadence seems to be working well enough IMO.


Processes are always going to slow things down though


And yeah sometimes you just have to be like, "Yeah, I don't know how long this one will take"


Reading this discussion, just came to my mind to use time ranges instead of approximation. Sometimes could be like “Between an hour and a week” for things not known in advance, e.g including the investigation of a bug. Does it make sense? Anybody tried?

Alex Miller (Clojure team)16:04:01

many people use some variant of this if you look at agile estimating

Alex Miller (Clojure team)16:04:15

using "fibonacci" days is another common difficulty estimate - is this a 1, 2, 3, 5, or 8 level difficulty (be careful about mgmt tying that to days though)

Alex Miller (Clojure team)16:04:49

it's also often important to convey not just difficulty but certainty - "4 days with a high degree of confidence" is a lot different than "4 days, but maybe 10 due to unknowns"

Lennart Buit16:04:50

Some people also like to make those Fibonacci sequences not have a time value, and instead use them as a grade to judge other issues. — a nevermind you went over this


We used fibonacci in the past for difficulty, it wasn’t tied to days and we rarely used it as a way to prioritize things, so in the end we stopped estimating and just have a kanban with backlog without any estimations


Imagine estimation turned around. The people who ask for time estimates would be required to come up with value estimates.


Because somewhere someone is doing this calculation, but maybe not overtly.


the big mistake I've experienced with estimation is divorcing it from team makeup and task decomposition


☝️ Yeah, a 5 to a new person might be a 3 for somebody that's been there for a year. Or a 2 for someone who had that code open yesterday.


In any case, I think it’s prudent to ask what the estimate is to be used for, before giving it.


And it should probably also be accompanied by a probability.


I've had terrible experiences on teams where the business side of things wanted estimates for entire feature delivery, so they asked a joint team (frontend, backend, testing, etc) to estimate things at a feature level, but asking a backend dev to estimate how much testing and frontend work would go into a feature was just dumb

☝️ 8
hiredman17:04:36 discusses the importance of force multipliers (connects with @U064X3EF3's comments about tools and team sizes) and has a a dismissive attitude towards scrum and agile (which tickles my confirmation bias)


☝️ Yeah, a 5 to a new person might be a 3 for somebody that's been there for a year. Or a 2 for someone who had that code open yesterday.

Timur Latypoff18:04:02

We started point-based estimation a few weeks ago, and it has been fantastic for us so far (for a small team of 6 developers with different level of experience). Though, I see it mostly as a communication tool, NOT a planning tool. For each task, after we give our estimation via Slack poker bot, if the estimations aren't the same: 1. First, we ask the people who gave the most points, what difficulties they expect that would justify such difficulty — some people have more experience with some matters, so they foresee some important pitfalls which others could have overlooked. 2. Second, we ask the people who gave the fewest points, what shortcuts they see in implementing the features, or how to simplify the task while providing similar business value — more experienced members might also provide some insights. Also, if people give different estimates, that might also mean they understand the task differently, so it's a good opportunity to improve wording of the task.

👍 4

> Though, I see it mostly as a communication tool, NOT a planning tool. The biggest difficulty I come across is that even very rough time estimates are taken by management as a promise to complete the work by this estimate. Time estimates are terrible at communicating complexity. We abandoned waterfall for a reason

Timur Latypoff14:05:08

@U0P7ZBZCK yeah, incompetent management will always try to convert everything to man-hours :)


does anyone know if a github organization can sponsor someone? It seems clear that an individual can sponsor an org, but wondering if an organization can sponsor individuals


@dpsutton That's a good question. The only reason I'm on OpenCollective is because a company that wanted to sponsor me couldn't do so via Github


yeah i'm wanting to present to boss that our company can sponsor cljs dev and not just 3 random people from our company


i've pinged github support. maybe should reach out to github community as well. we'll see

Bobbi Towers21:04:14

Idea: a Clojure Code-to-Speech tool that analyzes code and outputs English words that describe it


a cobol decompiler