Hacker News new | ask | show | jobs
by TimButterfield 1383 days ago
You may wish to take a look at the book, Righting Software, by Juval Löwy. It is not specific to any particular application or language, but can be generally applied to different projects and systems.

https://www.amazon.com/dp/0136524036
1 comments
blub 1383 days ago
What insights did you get out of that? I was watching the video version and gave up because it was mostly fluff and self-promotion. Couldn’t even remember what the core idea was that he kept repeating.
link
TimButterfield 1383 days ago
Here are just a couple of things.

Often, decomposition is based on areas of domain or functionality. There are some downsides to doing it this way. The method in the book proposes it be based on areas of volatility instead. As an example, imagine writing a piece of software for FedEx shipping. What would change to use that same software for UPS instead? That may identify some areas of volatility. If you can plan that something might change, you can limit the ripple effect of those changes in future. Just an example of one benefit of doing it this way. The book explains some of how to approach designing this way.

Another point: Architecture is not just about designing the software. It is also designing the project to build that software. This involves things like critical paths, staffing, risk management, etc. Understanding these is important if you want to be able to deliver on time and on budget.

link
blub 1382 days ago
Thanks. Regarding the first point, I remember that he was very adamant that functional decomposition was a catastrophe, but I didn’t reach the part where he presented the solution, which based on your comment seems to be decomposing on volatility.

I suppose it is another tool in the box, however in the video it was about to be introduced as nothing less than a magic bullet.

Regarding the second point, I’m not sure I agree. An architect could get involved in staffing decisions and any project has a list of risks, for example I’ve maintained such lists as part of the architecture description. But I would define these these are side-tasks and not as core tasks.

link