Luke Hohmann: Both the XP crowd and the Pragmatic Programmer crowd are making a bet. Either bet is a future option: the option to not spend the money now, or the option to spend the money now so that the cost of future change presumably is less. If the Pragmatic guys make the bet to spend some money now, and they're right, we're all happy. If they're wrong, we may have some crud to take out or clean up. If the XP guys make the bet to not spend the money now, and they're right, then we haven't incurred the cost, and we're happy. If they're wrong, if it turns out you need to make the change, then you've got to go back and refactor and retrofit.

So does that translate to these possibilities?

[b][u]XP:[/u][/b]
  Boo!  [u]Didn't add[/u] the flexility and it [u]was[/u] needed.
  Yay!  [u]Didn't add[/u] the flexility and it [u]wasn't[/u] needed.

[b][u]Pragmatic:[/u][/b]
  Yay!  Thought about it and decided [u]to add[/u] the flexility and it [u]was[/u] needed.
  Boo!  Thought about it and decided [u]to add[/u] the flexility and it [u]wasn't[/u] needed.
  Boo!  Thought about it and decided [u]not to add[/u] the flexility and it [u]was[/u] needed.
  Yay!  Thought about it and decided [u]not to add[/u] the flexility and it [u]wasn't[/u] needed.

So the advantage of XP was that no thinking was involved? Or am I oversimplifying? (Or just being silly, more likely)

Luke Hohmann: The idea came just from the ability to put two things together... I even got a patent for it.

We are long overdue for serious patent reform!

Bill Venners: I see. The tarchitect is doing the technical architecture. The marketect is doing the business architecture. If they're going in two different directions, when the time comes that the marketect says, "Hey, we've got this great opportunity that I saw coming," it doesn't work.

Luke Hohmann: Right. It flat out doesn't work. A great example of when that divergence occurs is whenever a team says, "You can't have that for a full release," because usually these big architecture changes take at least one release to get through.

Bill Venners: "You can't have that for a full release," means, we weren't ready for it.

Luke Hohmann: And we've got to pay the price of a full release to get there. It's a sign that those people, the marketects and tarchitects, were not working in concert.


I think this grossly oversimplifies the problem, unless you come from a marketing background and have to explain to a VP or worse, a customer, why something won't be in the product until a future date.

My personal experience has been that the 'tarchitects' generally aren't very interested in which direction the product is going. As long as the 'marketects' have a reasonably thought out plan as to the direction of the market and the feature set the product needs, then most 'tarchitects' are happy to do what's needed to get there.

Again, from experience, most 'tarchitects' care about the quality of the product. Performance, scalability, maintainability, etc. The release date is a secondary consideration to most of these people. 'marketects' tend to reverse these priorities. They both likely agree on the direction the product should take. What they don't agree on is the route to take to get there.

I'm not going to sit here and pass judgement on which is more important (I'm sure we've all sat through many of these 'discussions'), because we all know the bills need to be paid and that doesn't happen if you don't deliver. Alas, your bills won't be getting paid for very long if you deliver a substandard product. So you have to work through that constant tension of 'do I get it done quick' or 'do I get it done right?'. Sometimes that's hard. Personally I've always been better served by paying the cost up front. It's an investment that generally that results in a better architecture and a more robust product. 'YAGNI' has bitten me so many times (both on stuff I've done and stuff I've inherited) that I've found it a fundamentally bad practice.

And sometimes, not being ready for it sometimes means you simply weren't ready for it. Maybe 'm' and 't' were working in concert and they were both way off the mark. Or maybe the feature needed actually is a lot of work. Sometimes a new feature is a lot of work, regardless of how good or bad the architecture is. For some reason, that basic fact is overlooked a lot. Perhaps that's because we're in a profession where you can buy hundreds of 'Learn X in range(7 hours, 21 days)' books.

As you describe a technical vs. marketing architect, I think the marketing version is an even rarer breed than the technical version. I have yet to meet a good marketect. I've met, I think, 3 good tarchitects. Has anybody had an experience with a good marketect? As of this point in my career I liken them to Bigfoot or Nessie.

And I think Matt Gerrans Yay/Boo supports my hypothesis that thinking, like driving, is dangerous. Everybody that doesn't do it in a manner similar to you is dangerous :-)

Tarchitect, Markitect... sheesh
Do we really need to create these wierdly abbreviated words to talk about essential distinctions in achitectural focus?

These pseudo-words were cute the first time I heard them, but how is this new set of references better than "technical architect" or "product architect"?

Why not let's CAPITALIZE THEM and DRP_TH_VWLS TOO because we techies deal with complex and difficult concepts not describable by ordinary words!
So special.

Sorry. But seriously, why smush up two words into one unless it's worth more than cuteness?

Straightforward english words are fine, and using two words to name a complex concept or qualify a subtype is standard practice and is also fine.

All the while I read this I had to pause and translate these two terms, which are at the HEART of the discussion after all.

Shouldn't the language draw out more about that distinction, and more clearly, rather than abbreviate each of these significant domains to a single prefixed letter of difference - a T or an M?

Do you think you would have to explain to someone unfamiliar with your lingo what a "technical architect" is? How bout if you started talking about a "marchitect"?

IMO labels ought to more clearly articulate what they name, not create confusion and the need for inner mental translation. To meet this requirement, simple words are almost always better than abbreviations.

Clarity trumps cuteness in my opinion.

ok. i'm done ranting about that. thanks for listening.