
Choose design over architecture - dhotson
https://18f.gsa.gov/2015/11/17/choose-design-over-architecture/
======
alexandercrohde
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.

~~~
e12e
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_...](http://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm)

~~~
zachrose
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](http://c2.com/cgi/wiki?ModelViewControllerHistory)

~~~
e12e
[https://heim.ifi.uio.no/~trygver/themes/mvc/mvc-
index.html](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](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).]

------
daigoba66
"Architecture" is a funny word in software development. Funny because what
they call "software design" is still considered "architecture" to some. And
what they call "architecture" I prefer to call "topology".

But regardless of what you call it, I generally agree with the article that
application topology should be loose and adapt to changing requirements. Use
well known software patterns and principals when writing modules, etc.
Refactor cruft swiftly as needed.

Maybe it's just me, but after a decade of building software systems it's all
fairly obvious. Yet still important to teach and mentor to juniors.

~~~
m-i-l
In a large organisation you'll typically have a number of different
architecture roles, i.e. its always _something_ Architect. For example, there
are Enterprise Architect, Line-of-Business Architect and Solution Architect
roles for differing levels of vertical alignment within the business, and
there are Information Architect, Data Architect, Infrastructure Architect,
etc. roles for differing levels of horizontal alignment. Similarly within
design you'll find a number of design roles, e.g. UX Design, UI Design, etc.

~~~
arethuza
I've found that different organisations seem to have _completely_ different
definitions of "Enterprise Architect" \- some use to to cover infrastructure
and applications and others applications and business processes.

------
learc83
I think part of the problem is that Software Architect is a bad term. An
Architect makes a blueprint. That blueprint can be given to many different
builders who can then all construct basically the same building.

If you tried to build equivalently detailed software blueprints, you end up
just coding the whole thing. The problem is, the software is the blueprint.

Casey Muratori summed it up best in a handmade hero episode. He thinks that a
better analogy for software architect is an urban planner. I think that if you
approach your design phase more like urban planning, you'll accomplish most of
what the article author is going for.

~~~
kyllo
The title of Architect only makes sense in enterprise Java or .NET OOP
software projects where the architect's work product is UML diagrams and
dataflow diagrams, and the implementation of the classes is delegated to a
large number of developers.

I think that whole paradigm is a bad idea, but I also think that if you've
already decided you're going to use one of those languages and run your
project that way, it does make sense to have a person responsible for the
high-level system design.

~~~
arethuza
"architect's work product is UML diagrams and dataflow diagrams"

IMHO this is one of the worst ever ideas in software development - largely as
if you never actually get your hands dirty with real code and the whole messy
business of getting it developed, deployed and actually _used_ you never
actually see what _actually_ works and what doesn't.

------
rubyfan
I understand what the author's point is but a good architect will use a light
touch to help guide an effort toward solution. The sentiment is basically to
avoid the temptation to over architect toward perfection in favor of building
something based on an expression of business need. I generally agree with this
sentiment, however in large organizations where outsourcing prevails, a
deliberate architecture is a guard rail against bad practice and bad outcomes.
In my experience, architecture is a needed practice that can help communicate
the big picture and connect business goals to technology solutions.

------
iatanasov
I don't get it .The "ugly " picture at the beginning is what you get in the
end . No matter how many design steps you have.

~~~
CyberDildonics
Not if you have the right architecture.

------
kensign
Software Architecture is the complete system, including the hardware and
protocols. The complete system of an airplane is a software architecture.

It is very scary how naive and misinformed this article is coming from a .gov
site. Given the misuse of terms and purely ridiculous suggestions, I wouldn't
even show this to grade schooler.

[http://disi.unal.edu.co/dacursci/sistemasycomputacion/docs/S...](http://disi.unal.edu.co/dacursci/sistemasycomputacion/docs/SWEBOK/Addison%20Wesley%20-%20Software%20Architecture%20In%20Practice%202nd%20Edition.pdf)

------
alcima
The most disconcerting thing about this nonsense is that it is on a government
funded website.

------
analog31
Granted I'm an old timer, and not a commercial software developer right now,
but to me, the article brings to mind what I learned about "top down" versus
"bottom up" design.

------
paulojreis
My concern with this (and my general pet peeve with the "user stories" in
software engineering) is: how do we make sure the "user stories" are faithful
to real-world usage of the software being built? tl;dr: how do we know the
user stories are relevant?

The article defines user stories as "simple scenarios told from the point of
view of a person using the software. There can be many types of users for an
application". This is very, very problematic. How can I be sure that software
developers are able to walk on the shoes of the user? That they even know who
are the real users? Their needs, their context?

I have little to no faith in user stories, on software development. It takes a
lot of UX knowledge and experience to be able to faithfully depict scenarios
and personas, and even more so to have the maturity to do such things grounded
on data and not on our preconceptions. I just can't assume software developers
will have this kind of knowledge and experience and, as such, user stories
will end up being a reflex of their preconceptions, not of the real-world
usage of the software.

~~~
petard
I've been in many projects where people would iterate numerous times over
architecture while completely forgetting what real-world problem they are
actually trying to solve. Architecture becoming art pour l'art.

I don't see the point of the article being that every software developer
becomes a fully-fledged UX guy, but understands the context in which the
system is going to be used and not get lost in the technical rabbit hole.

~~~
paulojreis
> I've been in many projects where people would iterate numerous times over
> architecture while completely forgetting what real-world problem they are
> actually trying to solve. Architecture becoming art pour l'art.

I completely agree. Unless constrained, software developers will entertain
themselves with architecture stuff ad libitum. But this is one problem; the
other - a full-blown, bigger one - is truly knowing the real-world problem.

> I don't see the point of the article being that every software developer
> becomes a fully-fledged UX guy, but understands the context in which the
> system is going to be used and not get lost in the technical rabbit hole.

The premise is a noble one, and correct IMO. But, as above, truly knowing the
real-world problem is hell. We can't really hope to solve the technical rabbit
hole _just_ by focusing in the real-world, or _simply_ assume that we know it.

Software developers won't understand the real-world context, most of the
times. They aren't trained to do so. Most of the times, companies won't help:
organization keeps software developers very far from customers. Hell, I'll say
it: many software developers even lack the basic empathy skills to understand
the user. Their model of the software is the implementation model, not the
usage model. And many times they're too stubborn, and talk very cheap
regarding users and usage: software developers say "this is what the user
wants" as cheaply I say "the sky is blue". But the thing is that "what the
user wants" is not that obvious; the only obvious thing is the
mis/preconceptions we have.

------
mpweiher
I think the author confused "Architecture" with "Big Desing Up Front" (BDUF),
meaning the architecture is defined ahead of time in static (design...)
documents that do not interact with the actual code.

This is somewhat excusable because that is pretty much how architecture works
today. However, it shouldn't be, and Objective-Smalltalk[1] is an attempt to
bring architecture into the fray of actual code, allowing it to participate in
the feedback cycles of building real systems.

[1] [http://objective.st/About/](http://objective.st/About/)

------
cargocultpants
While this article is sadly vague, I will at least commend the GSA for
commissioning some great architecture in the more traditional sense.

And ironically, their website kept crapping the bed as I try to find their
page on it, so I'll just have to post a few examples from outside sources:

[https://en.wikipedia.org/wiki/San_Francisco_Federal_Building](https://en.wikipedia.org/wiki/San_Francisco_Federal_Building)
[http://www.archdaily.com/416001/som-breaks-ground-on-los-
ang...](http://www.archdaily.com/416001/som-breaks-ground-on-los-angeles-
courthouse) [http://www.gsa.gov/portal/mediaId/190803/fileName/2014DA--
Aw...](http://www.gsa.gov/portal/mediaId/190803/fileName/2014DA--Awards_Book--
508_compliant.action) (PDF)

------
valine
I have mixed feelings about this. An experienced programmer might know the
best way to structure a application simply from past experience. In this
situation, a blueprint ensures that everyone is on the same page and saves an
enormous amount of time that would have been spent refactoring code.

------
hoodoof
Choose semantics over wordplay.

------
wai1234
a pile of bricks is not a house.

