Item — HN Reader

I'm not sure what to make of this piece. It draws you in with the curious challenge to "choose design over architecture" but uses terms loosely and merely gives broad claims like "Unfortunately, this kind of a grand plan usually leads to technical-debt that collapses towards complete immobility."

It then wanders to the topics of "SOLID," "Optimize for change, but don't optimize in advance," "Commit to refactoring," and finally concedes "There is still a place for architectural planning"

I think I made a mistake reading this piece; the complexity of the relationship between architecture and customer asks is much too complex to be answered with a few quotable phrases. Maybe I should have known this going in.

3 comments

The article is indeed an odd mix. As for Architecture vs Design -- I think "Software Architect(ure)" is a bit of a misnomer -- in as much as architecture makes sense as a term, it is a property of a System. And like the original MVC was MVCU: Model-View-Controller-User -- a system consists of more than just code.

I keep going back to the original REST thesis[1] -- and it's wonderful use of architectural constraints as a lens in which to say something general and useful about the nature of hypertext applications. And other architectures, which people seem to ignore all the time -- REST is just one sub-set of constraints that emerges for a rather particular application type. I really think the chapter that details all the other architectures is at least as interesting as the REST-part.

Notice how this article talks about "web servers" and "APIs" -- as if they were general, universal, system level properties -- rather than some very specific instances of RPC -- shaped by the architecture of hypertext applications and REST.

[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_...

Model-View-Controller-User? Really? That's awesome!

I would have expected there to be a mention of this on c2.com[1]. Any other places I might find it?

[1] http://c2.com/cgi/wiki?ModelViewControllerHistory

https://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

[Ed: note the illustration. On a cellphone, so a little painful to read through - I just remember Trygve mentioning it in a presentation I had the good fortune to attend a few years back]

[Ed2: Here's at least one reference to MVC-U, from one of the presentations on DCI (a successor to MVC of sorts):

http://www.artima.com/articles/dci_vision.html

"Most programmers think of MVC as a fancy composition of several instances of the Observer pattern. Most programming environments provide MVC base classes that can be extended to synchronize the state of the Model, the View, and the Controller. (Model, View and Controller are actually roles that can be played by the objects that the user provides—we'll talk more about roles later.) So it's just a housekeeping technique, right? To think of it that way is to take a nerd's perspective. We'll call that perspective "Model-View-Controller." More deeply, the framework exists to separate the representation of information from user interaction. In that capacity we'll call it "Model-View-Controller-User," capturing all four of the important actors at work—MVC-U for short."

As I recall, in the presentation, it was indicated that this was the an emphasis on what MVC originally was about, and that the User-bit originally was such a central part of the whole thing, that it was also part of the name -- but that the "U" got dropped at some point (ie: in the late 70s when they were writing up this stuff initially).]

Same impression here. This piece had a surprising lack of depth given the vastness each topic the author decided to drop in the middle of it without any honest attempt to tie them together to the broader narrative.

the way it was written sounds like it was a business analyst or a agile-transformation consultant but not a person who understands engineering. Also it does not offer any proof/sources to the claims being made. e.g.:

"Unfortunately, this kind of a grand plan usually leads to technical-debt that collapses towards complete immobility. Complexities in even one of these services can take down the entire project. Unknown problems at the beginning can't be rolled into the new plan easily because all services are dependent on this architectural contract."

why?? it totally depends on the design/architecture on how flexible it will be.

or:

"In short, architectural plans push the team towards waterfall development, a system that has fallen out of favor as more and more projects have failed."

This article was probably written by a UE/UX designer. IMO you always need a "big picture"/vision/plan (whatever you call it) before you think about UI aspects. How flexible that plan is in regard to user-experience depends on how well it was designed. Also the type of design doesn't dictate if whether you have to chose lean/agile/waterfall as your development process.