If I had more time, I would create a cleaner and simpler design.
[1] https://quoteinvestigator.com/2012/04/28/shorter-letter/
211–218 of 218 posts
If I had more time, I would create a cleaner and simpler design.
[1] https://quoteinvestigator.com/2012/04/28/shorter-letter/
Earlier quoted context omitted.
> 3. Functions should have extensibility, put the required parameters as parameters and always include an “options” at the end. Each function can have defaults that you can extend, which means you need a deep-extend method: No! Absolutely not! There is a time and a place for this, but it's nearly impossible to reason about the interface if any data can be passed in.
I think you misunderstand. It’s not that “any” data can be passed in. The options object is documented in every version. It’s just a place that lets future versions add named parameterd
So, what is my role as an architect (I have been doing that role for about 15 years)? For various start-ups, I made sure that designs were compatible with each other (primarily through APIs and protocols). This was especially important at the startups since each team was running full speed to get a project done and often forgot the company's big picture.
For larger companies, I would be the interface between the customer and engineering to ensure both sides understood the requirements, expectations, and deliverables.
In all cases, I would also continue to code as well as document. An architect who doesn't code quickly loses sight of what is real and what is important in the ultimate expression of the design - the code itself.
Despite the provocative title, the author argues for software architecture, just doing it in a manner that suits the organizational culture. He somewhat decries traditional software architecture material, which I find off-putting. IMHO the best approach is to be aware of the techniques/patterns/references architectures, and use just the parts that make sense.
> Despite the provocative title, the author argues for software architecture, just doing it in a manner that suits the organizational culture. The problems demonstrated in the blog post go deeper than (and are not explained by) organizational culture. They convey the idea that the task of designing the architecture of a software system was assigned to inexperience and ignorant developers who, in their turn, decided t…