> implement following conservative assumptions, revisit and refactor aggressively
> The latter being vastly more effective at honing good design because more decisions are made in retrospect.
Only if people actually do that.
I've joined a project where a design doc should've been written before the first line of code (as per the agreed upon dev process). Developers disregarded that and yolo'd their way to a first prototype. No documentation whatsoever. Then someone else was tasked with writing a design doc for that big ball of mud. You can imagine how that went.
I've joined the project only much later. At every corner I'm dumbfounded by the "design decisions". Refactoring now is a herculean task and kept to the minimum required.
I'm certainly not advocating for waterfall-like "make a plan and stick to it no matter the cost". But looking at the requirements and drafting a coarse design from those goes a long way. At least you can get idea if whatever you have though up is in agreement with the requirements.
Treat the design document as a living document. Do a coarse draft first. Implement. Refine the doc with stuff you've found out, ditch the stuff that didn't work. As a bonus you get a relatively neat on-boarding doc for people joining later.
yoloing your way to a first prototype and aggressively refactoring along the way does make a lot of people very uncomfortable but it still produces better architectures than BDUF or even a scaled down BDUF (LDUF?).
it's really not generally appreciated just how much better architectural decisions made in the context of refactoring are. if you have a time budget for architecture it will always be better spent on refactoring than writing documents in advance, no matter how minimal they are.
Input is just HDMI, so works on Linux without issue. There might be an app or something that lets you control the settings, but I've never used that once. All relevant stuff can be configured from the front panel buttons. I think the Mac issue is that macos slightly dithers/moves the image with a high rate which would kill the EInk pixels quickly. There appears to be an app to deactivate this behavior though.
> Input is just HDMI, so works on Linux without issue
HDMI is not always plug and play. I unfortunately encountered a situation where a Phillips HDMI display only worked with Windows, but not Linux due to EDID/Nvidia driver issues
I have both, a Boox Mira pro (monochrome only) as well as a Dasung Color EInk Monitor.
You actually get used to the monochrome thing. I've adjusted my syntax highlighting to use more italic, underline, bold etc so you get by without the semantic coloring.
The color eink is way better though. Only downside is that it has less contrast than the purely monochrome one. Color makes up for it nicely, though. Plus the refresh rate on the Dasung is way higher, so you can actually use a mouse without going insane trying to predict cursor movement.
Where the monochrome monitor was more of a secondary display primarily used for coding, I'm now using the Color EInk one as my main display.
Heh, I would not ever have expected to see my company mentioned on HN. I'm the software tech lead at Menlo Systems, we're building those frequency combs that Thorlabs sells.
Re the commoditization: Part of the problem is that customers, especially the scientific ones, don't want "commodity" frequency combs. Nearly every comb we sell is tailored to the specific customer in one way or another.
Industrial customers start to be interested in frequency combs more and more. I guess this will be the clientele that values off-the-shelf products more, eventually paving the way for commoditization.
The presence of individuals such as yourself is what makes the HN comments such a frequently meaningful place to find insightful discussions. Thanks for the context!!
Only if people actually do that.
I've joined a project where a design doc should've been written before the first line of code (as per the agreed upon dev process). Developers disregarded that and yolo'd their way to a first prototype. No documentation whatsoever. Then someone else was tasked with writing a design doc for that big ball of mud. You can imagine how that went.
I've joined the project only much later. At every corner I'm dumbfounded by the "design decisions". Refactoring now is a herculean task and kept to the minimum required.
I'm certainly not advocating for waterfall-like "make a plan and stick to it no matter the cost". But looking at the requirements and drafting a coarse design from those goes a long way. At least you can get idea if whatever you have though up is in agreement with the requirements.
Treat the design document as a living document. Do a coarse draft first. Implement. Refine the doc with stuff you've found out, ditch the stuff that didn't work. As a bonus you get a relatively neat on-boarding doc for people joining later.