Choose design over architecture
18f.gsa.gov
18f.gsa.gov
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.
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_...
I would have expected there to be a mention of this on c2.com[1]. Any other places I might find it?
[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).]
"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.
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.
- 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.
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.
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.
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.
Actually trying to live up to the title of architect and including blueprint level detail into those high level diagrams is asking for trouble.
The point is, the larger the project, the more important it is to invest in the right expertise at the beginning. The problem we have in software engineering is that successful projects almost never start from a position of major financial backing. Instead, the usual process is, start lean and cheap, hopefully gain traction, grow the product, get the investment, hire the talent. Honestly, I think it's a miracle if these types of projects are ever recovered.
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...
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.
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.
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.
P.S. As I said above, this is a pet peeve of mine. I'm doing a generalization; of course there are developers which are great at writing user stories and understanding users.
It's just that I believe in being professional and knowledgeable. If user stories matter, you should get someone with the valid skill set to do it. Not only should you get the skill set on your team, you should get the process! User stories without user data are just plain fiction. It's just the movie your team plays in their heads regarding how the software is used.
That is true... I've seen a fair share of user stories that start "As a developer"...
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.
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 http://www.archdaily.com/416001/som-breaks-ground-on-los-ang... http://www.gsa.gov/portal/mediaId/190803/fileName/2014DA--Aw... (PDF)