Readit Newsmeaboutsoftware commented on Show HN: I published a book to save you from my software architecture mistakes leanpub.com/master-softwa... · Posted by u/meaboutsoftware
Thank you for publishing the free chapter, it felt very down-to-earth and relatable. Looking forward to reading the rest of it!
Thanks! That was the idea of the book - no philosophy, just practical stuff
We need more books of this nature. The free chapter didn't really sell me on the book, but for $26 even if there's only one insight I pick up it may be useful. So I picked up a copy, but I do have some concerns.
I've been pretty cautious about technology decisions. When some new tech gets hyped up, it automatically gets flagged in my brain almost like spam or some infomercial product. Everything has tradeoffs and if the whole industry is telling me I must do X without stating any of the downsides of X those red flags go up. I'll use my own judgement to see if X makes sense. And for the last decade or more I feel I've been on the right side of history. I read the free chapter and the immediate concern is the next chapter which dives into CQRS. CQRS is one of those technologies that was massively hyped up and I'm sure caused lots of projects to fail. Search HN on CQRS and it typically falls into "architecture mistakes" more often than not. So I'm hoping the book is very careful in its recommendations or at least dives into some tradeoffs.
One side note: I slightly disagree a bit with the free chapter's "four steps of evolution". The app I'm building has a very complex domain such that we don't have many competitors and the barrier to entry is high. You can't simply build an MVP that does some small subset and hope to add as you grow as the product would not be functional. You need to handle the domain complexity up front just to deliver an MVP that does some bare minimum. So perhaps this app or industry may be an edge case, but perhaps some caveat is needed in that chapter.
Thanks for this comment. It is important to consider everything you said. CQRS is part of this book, but it is more of an explanation and might help you at some point (but does not need to). I think that's the main problem of CQRS - it is not understood well.
Throughout the book, I describe many concepts. Sometimes, I give some recommendations, and sometimes, no.
I accept your note—these four steps of evolution help you find yourself in one of them. Simplicity can be solved in multiple different ways; it is just the direction of keeping the solution as simple as possible (sometimes it will be more complicated, and sometimes less).
Enjoy reading it; if you don't like it, you can always return it within 60 days (Leanpub policy).
One of the first books that seem very interesting to read, coming from a recently graduated student. Will give this a go
Does 10 years count as a recently graduated student? Thanks, I feel very young again! :)
Congrats on releasing the book! It's already a huge accomplishment :) Wishing you to reach as many eager architects as possible and to have fun in exploring SA further.
Thank you Marcin!
Congrats on finishing the book! 400 pages in 5 months is insane levels of productivity. I'm very jealous!
Thank you! This would not have been possible without stopping almost all other work.
This is my tip: if you want to write a book, plan unpaid holidays, or stop all consulting/freelancing work. Then, it is not that hard to keep up the tempo - when you know what you are writing about, of course ;)
Congrats on publishing! :)
Does your book include a section(s) on how to document software architecture? What I’ve encountered is a variety of methods for documenting things, to the point where the documentation becomes outdated, unread, and ultimately a mess.
I'm looking for guidance on properly documenting a system, both during the design phase and for tracking changes and decisions. I'm thinking of something along the lines of design documents, Architecture Decision Records (ADRs), and similar methods.
Thank you! :)
I have similar observations, and over the years, I kept looking for something that would stand the test of time. I still remember horrors related to documenting architecture in Word documents (and requirements in Excel, omg).
The architecture decision log usually works well for the teams I work with. It is kept up to date and ordered thanks to architecture decision records.
I describe it extensively in one of the book's chapters with a practical example. I also show how to document alternatives considered when the record was added, where to keep it in case of mono repo, multiple repos etc.