31–40 of 68 posts
This guy must be on another astral plane :-) Who is the customer ? Ahhhhh the one who pays ! For a second I thought he meant "users" ! :-)
There is nothing actionable about this list. A lot of it is meant to sound wise, without any specifics.
Definition of heuristics:
> A heuristic, or a heuristic technique, is any approach to problem-solving that uses a practical method or various shortcuts in order to produce solutions that may not be optimal but are sufficient given a limited timeframe or deadline.
A small sample of the heuristics from the "evolving list":
> Our only measure of progress is delivering into our customers hands things they find valuable.
> Outcomes matter more than output. A focus on output yields sub-par outcomes.
None of this is practical or a shortcut of any kind. It just "sounds" nice as an abstract idea.
Reading the comments first I suspected this was an HN over-reaction to the list. However upon reading it myself I must totally agree. There is nothing actionable about this list. A lot of it is meant to sound wise, without any specifics. Definition of heuristics: > A heuristic, or a heuristic technique, is any approach to problem-solving that uses a practical method or various shortcuts in order to produce solutions…
This unfortunately applies to most of the popular advice in our industry. You could argue that "meant to be wise, without any specifics" is a requirement for a meme to get picked up and recognized by a large enough mass of people in order for it to become viral.
Consider if you can apply anything in SOLID in an actionable way. None of it is actionable, except LSP. It's meant to sound wise, without any specifics.
> 6. Knowledge work has unique concerns, unrelated to those of a factory or construction site. > 7. … You cannot improve a system by tinkering with the parts. This last statement seems to apply more to factories or construction sites, not software engineering. Obviously systems can be improved by tinkering with parts that are shared and actively used by multiple systems.
> You cannot change anything without changing everything. You cannot improve a system by tinkering with the parts.
Those sentences seem to outright contradict each other...
Very woolly. I was expecting more concrete things like * Use static types * Use CI and version control * Use schema-based data storage * Prefer function calls to events * Use formal verification if possible etc.
Very woolly. I was expecting more concrete things like * Use static types * Use CI and version control * Use schema-based data storage * Prefer function calls to events * Use formal verification if possible etc.
> * Use schema-based data storage Great idea until it isn't. The article is full of bullshit but one thing is very true. We can't predict the future, especially so when we deal with humans and society where stuff changes fast. Strict schemas are more pain than gain here. > * Use formal verification if possible Wonder when F* and the like get mainstream so that "if possible" becomes "almost always".
A healthy practice combines both depending on the nature of the task.
This comes out in #13, #19, and #20 (well depending on exactly what they mean by "managing".) I find it really helps to have someone dedicated to the product side, so they can help with prioritization, generating ideas for what to try next, keeping track of the research, and tracking the launch process and metrics.
We could, I suppose, distribute all of that to the engineers, but there's value in that specialization.
(I generalize to "agile-folks" here because I feel like I've seen this before, but I can't think of exactly where.)
Reading the comments first I suspected this was an HN over-reaction to the list. However upon reading it myself I must totally agree. There is nothing actionable about this list. A lot of it is meant to sound wise, without any specifics. Definition of heuristics: > A heuristic, or a heuristic technique, is any approach to problem-solving that uses a practical method or various shortcuts in order to produce solutions…
But isn't this just stating the obvious, e.g. don't measure success by lines of code written, number of commits, number of bugs fixed...? And there is nothing wrong in stating the obvious, especially as when it is not obvious to some people.