Hi William,

I glad you're back. You are one of the few people on the web worth debating with, and congratulations on the new addition to the family.

Read your article, and at first I thought I understood, and then I didn't..., then I felt you was struggling yourself... In the end I concluded too many words.

As I've expressed before, we (technical people) seem to struggle with a lack of definition, and with the unknown.

At the start of a project we have no architecture, all we have is a product vision, and a toolbox of design principles and development practices. What the final product will be is unknown, what the right architecture is for the final product to be is also unknown... Even the idea of a "final" product is dubious, since a well architected product will evolve over its entire lifespan, as the users request changes, with no "steady state".

All we have is now. If we let go of the future and live in the moment then we stand half a chance of coming up with the simplest and cleanest architecture for right now. The moment we write concrete code we have architecture... That architecture can be judge by its fitness for purpose for the problem as we understand it today and how clearly it expresses that purpose. No other judgement can be made, anything else is pure speculation.

I could spend a lot of time talking through the design principles that underly good architecture, like the liskov substitution principle, the open-closed principle, but that would take too many words. Good design is triggered by sound intuition and reinforced by concrete feedback.

Developing that intuition takes years of practice, and a deep understanding of the underlying principles until they become second nature, and you find yourself making good design decisions almost unknowingly...

This is why words are futile. What is needed is practice, more practice and mentorship under the guiding hand of someone who as mastered these fundamental principles and practices themselves.

Bob Martin, as been speaking about this under the title of craftsmanship. There is now also a manifesto too:

http://manifesto.softwarecraftsmanship.org/

Emerge versus Evolve ...Hmm? To me it sounds like hair splitting. Either you know how to do it or you don't. Those that do are masters and should be getting on and doing it and teaching others how to do it, those that don't should apprentice themselves to some one that does and have the humility to learn by example, then practice, practice, and practice some more until they are competent.

I think the time for words is over. Its time enough our industry grew up and became a true profession.

Paul.

Hello Paul.
Sorry to delay so much my response to you. Too much work, too little sleep (you may guess why).

Did you see Amadeus? The emperor told him the opera was almost perfect, but had too many notes!.
"Just cut a few and it will be perfect".
Mozart came back to ask:
"And which few do you have in mind, majesty?"

Which few do you have in mind, Paul?
Not sure if you are talking about me using too many words, or that there are too many words describing things that are useless. In any case, the idea of the post is to mention what you say in the comment: There is no architecture without code.
So, there is no evolution of something that is not being.

But also, people like architects tend to describe the architecture a priori, and in construction, that definition suffers lots of changes. That may not be evolution of the architecture, but of the design.

That is, the topic is not how to do it, if it is emerging or evolving, but to clarify the confusion of you having an architecture with no lines of code. That is not real.

Cheers!

William Martinez.

Hi Williams,

OK. I think I understand. I also agree. This explanation has less words then the first and is better for it IMHO :)

But more seriously. I've been coaching a US team recently, that have developed their own ideas about design, architecture etc, in lieu of having someone to show them the right way.

Thinking through how I learned this stuff, and I realised that my understanding was hard earned through years of practice. To expect them to get it straight away without sharing a similar prior context:

http://incredulous-developer.blogspot.com/2009/03/prior-context.html

is just too big an ask. Perhaps I was having a bad day when I read your article, and I do apologise. But we do need to find away to reach out to the vast majority that haven't grasped the basics.

I guess it was this that prompted my response more than anything you said. Sorry.

Paul.

Hi Paul.
No worries! You have bad days, I have bad nights :-D (although I love those bad nights).

I have also contact with lots of students and junior developers, and all they have a mix on how to do things, a mix from their teachers at the university, the clients at work, other developers and even bloggers like us! So, we are all to blame (specially the ones like me that are part of all four types).

So, as I said, cheers!

William.

Just re-read the article with a clear head, and I agree 100%. Only one nit-pick:

>>Finally, you can have, as Neal mentions, an architecture designed to evolve (with flexibility included), which is different of what we are talking here. That would be an evolving system that has an architecture that allows it. Tricky!

I would say that an architecture designed for now, that complies with good design principles is an architecture designed for evolution by default. A clean design/architecture that is open to extension and avoids premature design choices is "an evolvable system". I think that is what you are saying too.

I guess what Neal is talking about is "guessing" the extension points ahead of time. Now I agree that is tricky :)

I would be interested in hearing more about your teaching experiences. As a coach I come across many people with a number of misconceptions. The fact that most of our terminology isn't well-defined doesn't help. Also from one book to the next, different terms are used to refer to the same idea. How does anyone learn anything?

It must be a struggle as a teacher. In my experience intensive one-on-one mentoring works best. What works with your students? Or perhaps that could be the subject of a future blog.

Thanks for accepting my apology,

Bye for now.

Paul.