4 ms·
I always wanted to write a "Philosophy of Software Design", except I wouldn't dictate HOW to write software. Instead I'd focus on what questions to ask and what
by tabtab 8y ago
I always wanted to write a "Philosophy of Software Design", except I wouldn't dictate HOW to write software. Instead I'd focus on what questions to ask and what trade-offs to expect. It would be Yoda-ish: Yoda teaches you how to ask questions and how to find answers, not the answers themselves.
In the end: there is NO right way, only trade-offs. At least know what the tradeoffs are. My book would be a trade-off recognition training guide.
I would state my experience, though. Such as "In my experience, typical shops are more comfortable with pattern X over pattern Y. I have no idea why: it's a psychology question I don't have the funds to answer."
And there'd be a chapter on how to recognize and scrutinize fads.
- asianthrowaway 8y agoAre you familiar with "the art of unix programming" by ESR? It's in the same vein as what you describe. It even has an appendix with buddhist-like dialogues!
- tabtab 8y agoWhile there are some nice tidbits, end-user software tends to have a different profile of needs than infrastructure software or middle-ware. I guess what I'm saying is that I'd focus more on end-user software in such a book. That's not necessarily the same as UI design, but for example, less about generic API design to be used by a million other developers, and more about in-shop API or stack design for say 20 developers.
- chrisweekly 8y agoWrite it! Start with a blog post series if "a book" is too great a hill to climb!
- justaguyhere 8y agoSeconded. Start with a series of blog posts to gauge interest, level of effort etc.
- brainzap 8y agoMost of the time the answer is: "Because a human has to read and understand it".
- tabtab 8y agoIndeed, software design is a lot like writing technical instructions. One should think in terms of writing for humans, not so much machines. But another key dimension is dealing with changes in requirements over time. One cannot over-value their forecasting/guessing ability, and have to hedge the design to some degree. Some of the GOF design pattern writing assumed too much regularity in future changes, for example. I'd like to describe counter examples that show how assumptions of future regularity can byte one in the proverbial output port.
- smokeonline 8y agoThis is a nice idea, I've been looking for things like this to read. But my interest is more about generic systems, not that much about end-user software. You are talking about "trade-offs" and I had a similar idea about "Values". With this values you would be able to derive the "Rules" (the HOW you mentioned) depending on the context and chosen trade-offs. About it I think the 17 unix philosophy rules are very interesting. https://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond%E2%80%99s_17_Unix_Rules https://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond%E... and I also started to write a blog about it https://github.com/JpOnline/Blog/blob/master/language.md https://github.com/JpOnline/Blog/blob/master/language.md