7 ms·

Choose design over architecture

108 points by dhotson 11y ago

daigoba66 11y ago
"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.
- rubiquity 11y ago
  I've never been comfortable with: - working with people in software who hold a title of architect - being referred to as an architect personally - having the work that I do referred to as architecture Design looks much less cool on a resume but is far more accurate and portrays a certain nimbleness. Anecdotally, the people I've ever worked with who did consider themselves "Software Architects" were generally quite poor at their jobs.
- rubyfan 11y ago
  I happen to work with both folks who hold the title "Architect" and others "Designer". In practice there's often overlap in skills in those roles. In my experience there are different types of architect, some focused on infrastructure, perhaps the "topology" you're referring to and some focusing on the solution. The solution architect tends to focus on delivering business solution and capability while the designer is focused on software implementation.
- m-i-l 11y ago
  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 11y ago
    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.
iatanasov 11y ago
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 11y ago
  Not if you have the right architecture.
analog31 11y ago
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.
rubyfan 11y ago
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.
learc83 11y ago
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.
- protomyth 11y ago
  Wasn't Microsoft's M supposed to act much like a blueprint?
  - learc83 11y ago
    From what I've heard of it, that was their plan, but these types of projects always run into the same issue. If you build a high level system powerful enough to generate code that can solve general problems, the high level system eventually becomes a general purpose programming language itself.
- kyllo 11y ago
  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.
  - learc83 11y ago
    I agree, but my point is that I think those UML diagrams are much more analogous to the work products of urban planners than architects. Actually trying to live up to the title of architect and including blueprint level detail into those high level diagrams is asking for trouble.
wai1234 11y ago
a pile of bricks is not a house.
hoodoof 11y ago
Choose semantics over wordplay.
alcima 11y ago
The most disconcerting thing about this nonsense is that it is on a government funded website.
valine 11y ago
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.
alexandercrohde 11y ago
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.
- modarts 11y ago
  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.
- e12e 11y ago
  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_styles.htm http://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_...
  - zachrose 11y ago
mpweiher 11y ago
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/
paulojreis 11y ago
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 11y ago
  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 11y ago
    > 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.
kensign 11y ago
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/SWEBOK/Addison%20Wesley%20-%20Software%20Architecture%20In%20Practice%202nd%20Edition.pdf http://disi.unal.edu.co/dacursci/sistemasycomputacion/docs/S...
cargocultpants 11y ago
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-angeles-courthouse http://www.archdaily.com/416001/som-breaks-ground-on-los-ang... http://www.gsa.gov/portal/mediaId/190803/fileName/2014DA--Awards_Book--508_compliant.action http://www.gsa.gov/portal/mediaId/190803/fileName/2014DA--Aw... (PDF)

108 points by dhotson 11y ago

"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.

rubiquity 11y ago
I've never been comfortable with: - working with people in software who hold a title of architect - being referred to as an architect personally - having the work that I do referred to as architecture Design looks much less cool on a resume but is far more accurate and portrays a certain nimbleness. Anecdotally, the people I've ever worked with who did consider themselves "Software Architects" were generally quite poor at their jobs.
rubyfan 11y ago
I happen to work with both folks who hold the title "Architect" and others "Designer". In practice there's often overlap in skills in those roles. In my experience there are different types of architect, some focused on infrastructure, perhaps the "topology" you're referring to and some focusing on the solution. The solution architect tends to focus on delivering business solution and capability while the designer is focused on software implementation.
m-i-l 11y ago
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 11y ago
  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.

iatanasov 11y ago

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 11y ago
Not if you have the right architecture.

analog31 11y ago

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.

rubyfan 11y ago

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.

learc83 11y ago

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.

protomyth 11y ago
Wasn't Microsoft's M supposed to act much like a blueprint?
- learc83 11y ago
  From what I've heard of it, that was their plan, but these types of projects always run into the same issue. If you build a high level system powerful enough to generate code that can solve general problems, the high level system eventually becomes a general purpose programming language itself.
kyllo 11y ago
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.
- learc83 11y ago
  I agree, but my point is that I think those UML diagrams are much more analogous to the work products of urban planners than architects. Actually trying to live up to the title of architect and including blueprint level detail into those high level diagrams is asking for trouble.

wai1234 11y ago

a pile of bricks is not a house.

hoodoof 11y ago

Choose semantics over wordplay.

alcima 11y ago

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

valine 11y ago

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.

alexandercrohde 11y ago

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.

modarts 11y ago
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.
e12e 11y ago
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_styles.htm http://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_...
- zachrose 11y ago

mpweiher 11y ago

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/

paulojreis 11y ago

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 11y ago
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 11y ago
  > 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.

kensign 11y ago

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/SWEBOK/Addison%20Wesley%20-%20Software%20Architecture%20In%20Practice%202nd%20Edition.pdf http://disi.unal.edu.co/dacursci/sistemasycomputacion/docs/S...

cargocultpants 11y ago

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-angeles-courthouse http://www.archdaily.com/416001/som-breaks-ground-on-los-ang... http://www.gsa.gov/portal/mediaId/190803/fileName/2014DA--Awards_Book--508_compliant.action http://www.gsa.gov/portal/mediaId/190803/fileName/2014DA--Aw... (PDF)