Comments on: Evolutionary Architecture

By: Software Development Word of the Day « A-Cuppa-Code

Software Development Word of the Day « A-Cuppa-Code — Mon, 21 May 2012 11:24:51 +0000

[...] [Refs: http://lostechies.com/jimmybogard/2010/01/29/evolutionary-architecture/] Like this:LikeBe the first to like this post. Explore posts in the same categories: Uncategorized [...]

By: RichB

RichB — Wed, 26 Oct 2011 14:55:00 +0000

An average developer can take a lot of pain, and consequently stick with an ugly system for a long long time.

By: Tim

Tim — Wed, 03 Feb 2010 03:19:01 +0000

On point 3: Iterative Design

What about also recording your decisions for making design/architecture changes somewhere for later reference?

By: Arnis L.

Arnis L. — Sat, 30 Jan 2010 13:26:02 +0000

Jimmy, change the world and come up with detailed instructions about this. I’ve thought about exactly the same thing quite a lot. Main problem is – there aren’t well defined methodology that helps to go through (movement itself) from simple architecture to complex one and would let to identify and unite this idea as a unit. What are exact problems when identifying things that should be more complex, how and when to identify them and what are exact problems when switching to more complex solution and how to avoid them.

Despite that this would get highly abstract, i think there’s a great potential. At least my intuition says so.

By: Mehdi Khalili

Mehdi Khalili — Sat, 30 Jan 2010 01:49:48 +0000

Jimmy, Thanks for the post.

It kinda addresses my question in your previous post; however, what I was and am concerned about is not reversible decisions. I am concerned about things like:
- client-server vs distributed system
- data access patterns
- messaging/communication patterns

These are kind of questions that you almost always have to answer in the first few months (if not weeks) of project initiation, and unfortunately these are rather the most irreversible of decisions you have to make.

Of course everything could change to a better design in an iterative approach, but the cost associated with a wrong (or I should say not very well-informed) decision could be high. I wish stakeholders could make up their minds first that is not alway possible though.

Mehdi

By: jdn

jdn — Fri, 29 Jan 2010 15:38:28 +0000

The trick is finding the right balance between the seeming contradiction of #2 and #3:

“if it doesn’t hurt, it doesn’t need fixing. If it hurts, fix it! The bottom line is that not all areas of your application will have the same sophistication and attention to detail in its design”

and

“Improving the architecture of a system is good, but leaving a trail of decaying, older designs still in the codebase can cripple further innovation”

By: Daniel Fernandes

Daniel Fernandes — Fri, 29 Jan 2010 09:24:01 +0000

We all understand the risks of BDUF, although I’m still interested by what D means to people.
Is it:
- High level only architecture (like, we’ve got those subsystems with specific roles)
- Architecture detailed to the nth degree
- Documents with reams of class diagrams
- Simply the fact that it’s something produced by an architect or an analyst

I’ve only seen only twice true BDUF in a shop doing waterfall. Yes it was indeed painful because it was far too detailed. In the first case it didn’t work because it was produced by analysts who stopped coding years ago, whilst on the other case it worked because it was produced by developers who were forced in producing such document but were not held by it.

Regarding YAGNI, I’m glad you’re warning against it. I’ve seen too often compromised designs because “you don’t need that abstraction”. YAGNI should indeed first be applied to features, and then maybe design. Design quality should be directed by design principles the team is aiming at.

@Daneel3001