Comments on: How Much Architecture Is Too Much Architecture? http://www.maximporges.com/2005/07/20/how-much-architecture-is-too-much-architecture/ Winning At Yelling Wed, 09 Nov 2011 16:13:16 -0800 http://wordpress.org/?v=2.8.4 hourly 1 By: Maxim Porges http://www.maximporges.com/2005/07/20/how-much-architecture-is-too-much-architecture/comment-page-1/#comment-31 Maxim Porges Fri, 22 Jul 2005 03:09:00 +0000 http://www.maximporges.com/?p=14#comment-31 Hey Sean,<br/><br/>Great alternative view point; maybe I am focusing too much on process improvement.<br/><br/>That being said, I went down this path in response to feedback from my team, not my own decision to "tune the engine", so to speak. When my developers talk, I listen; that's how most of the other cool ideas used in our team today came in to being. It's my job as a manager to filter the grumbling/laziness from the legitimate concerns, but in this case I felt it was worth stepping outside of the box and taking another look at what we do from the outside looking in.<br/><br/>Having churned the ideas in my noggin again, I'm beginning to think that we could save development time with some additional tools. Adalon is great for Fusebox, but we really have nothing for OO and associating business/technical requirements with the objects that supoprt them. Although, we had a <a HREF="http://www-306.ibm.com/software/rational/" REL="nofollow">Rational</a> on-site demo today, and what we saw got the cogs in my head turning; it was excellent timing. I'm going to focus on this item for today's blog post, so I won't repeat my thoughts here.<br/><br/>I'd say that my team does a pretty good job sussing out our clients and getting in their heads, mostly due to Michael's attention to detail and excellence in understanding the business and gathering requirements (Michael's our Project Coordinator/Manager). I agree with your point that at the end of the day, an ounce of additional client focus is worth a pound of architecture - especially if it has a direct impact on the quality and usability of the end product (and the client's resultant satisfaction).<br/><br/>as for Flex - the more I see of it, the more I like it. More on this back on the blog... :)<br/><br/>- max Hey Sean,

Great alternative view point; maybe I am focusing too much on process improvement.

That being said, I went down this path in response to feedback from my team, not my own decision to “tune the engine”, so to speak. When my developers talk, I listen; that’s how most of the other cool ideas used in our team today came in to being. It’s my job as a manager to filter the grumbling/laziness from the legitimate concerns, but in this case I felt it was worth stepping outside of the box and taking another look at what we do from the outside looking in.

Having churned the ideas in my noggin again, I’m beginning to think that we could save development time with some additional tools. Adalon is great for Fusebox, but we really have nothing for OO and associating business/technical requirements with the objects that supoprt them. Although, we had a Rational on-site demo today, and what we saw got the cogs in my head turning; it was excellent timing. I’m going to focus on this item for today’s blog post, so I won’t repeat my thoughts here.

I’d say that my team does a pretty good job sussing out our clients and getting in their heads, mostly due to Michael’s attention to detail and excellence in understanding the business and gathering requirements (Michael’s our Project Coordinator/Manager). I agree with your point that at the end of the day, an ounce of additional client focus is worth a pound of architecture – especially if it has a direct impact on the quality and usability of the end product (and the client’s resultant satisfaction).

as for Flex – the more I see of it, the more I like it. More on this back on the blog… :)

- max

]]> By: Sean Tierney http://www.maximporges.com/2005/07/20/how-much-architecture-is-too-much-architecture/comment-page-1/#comment-29 Sean Tierney Thu, 21 Jul 2005 16:50:00 +0000 http://www.maximporges.com/?p=14#comment-29 Max,<br/>it sounds to me like you guys have already achieved total zen in your development process (java/spring/fusebox4/adalon/FLiP). I know there is always room for streamlining and decoupling in any project, but I almost think that sometimes you can get spun out perpetually seeking to add more efficiency to a process which is already 95% optimized instead of allocating those thought-cycles to questions like "what might this client need 2mos from now that he/she is not asking for presently?" You are right that time is money, but I think there's also this elusive emotional component that sometimes gets neglected in the design process. Spending time to learn extra about the client, what makes him/her tick, the nuances of the business domain and what he/she likes/hates/envisions (beyond what is captured in the spec) is always a good use of time. Ask the question "forget computers for a sec, in an ideal world how would this transaction go down?" You can sometimes discover erroneous assumptions on their part that are caused by their own limited understanding about what the technology itself can do.<br/><br/>The other area I think gets gypped most of the time is empirical analysis of the effectiveness of different visual interfaces. In marketing they call it A/B testing and it means "run two different ads, gauge which works better, then survival of the fittest- run the winning ad fulltime." I've seen territorial designers have holy wars over which design was better, but the truth is that it's all speculation until you put some statistical teeth behind these assertions. I've always thought it would be neat to build this "evolutionary mechanism" as a feature of the CMS- basically an automated mechanism for testing out various designs and measuring the effectivness on the fly (through analysis of the clickstream to see what percentage of visitors reach the desired target) and then intelligently serving the interface that works best.<br/><br/>Lastly, exploring rich interfaces provided by flex / laszlo / ajax (as i know you are already doing) would seem to be a good investment of resources. A small improvement like simplifying a checkout process by removing an unnecessary screen-refresh or making it slightly more intuitive may seem trivial but can have enormous impact in the face of a large volume of transactions. Also, fixing annoying quirks in the current internal systems like your buddy Michael mentioned in his blog (the refresh-time issue from clearing and regenerating an entire array of products in memory when realistically only one has changed) - eliminating daily annoyances like this is always time well-spent.<br/><br/>Anyways, that's my take, unfortunately not really related to what the right architecture balance is, as you guys seem to have already hit the sweetspot on this. kudos.<br/>Sean Max,
it sounds to me like you guys have already achieved total zen in your development process (java/spring/fusebox4/adalon/FLiP). I know there is always room for streamlining and decoupling in any project, but I almost think that sometimes you can get spun out perpetually seeking to add more efficiency to a process which is already 95% optimized instead of allocating those thought-cycles to questions like “what might this client need 2mos from now that he/she is not asking for presently?” You are right that time is money, but I think there’s also this elusive emotional component that sometimes gets neglected in the design process. Spending time to learn extra about the client, what makes him/her tick, the nuances of the business domain and what he/she likes/hates/envisions (beyond what is captured in the spec) is always a good use of time. Ask the question “forget computers for a sec, in an ideal world how would this transaction go down?” You can sometimes discover erroneous assumptions on their part that are caused by their own limited understanding about what the technology itself can do.

The other area I think gets gypped most of the time is empirical analysis of the effectiveness of different visual interfaces. In marketing they call it A/B testing and it means “run two different ads, gauge which works better, then survival of the fittest- run the winning ad fulltime.” I’ve seen territorial designers have holy wars over which design was better, but the truth is that it’s all speculation until you put some statistical teeth behind these assertions. I’ve always thought it would be neat to build this “evolutionary mechanism” as a feature of the CMS- basically an automated mechanism for testing out various designs and measuring the effectivness on the fly (through analysis of the clickstream to see what percentage of visitors reach the desired target) and then intelligently serving the interface that works best.

Lastly, exploring rich interfaces provided by flex / laszlo / ajax (as i know you are already doing) would seem to be a good investment of resources. A small improvement like simplifying a checkout process by removing an unnecessary screen-refresh or making it slightly more intuitive may seem trivial but can have enormous impact in the face of a large volume of transactions. Also, fixing annoying quirks in the current internal systems like your buddy Michael mentioned in his blog (the refresh-time issue from clearing and regenerating an entire array of products in memory when realistically only one has changed) – eliminating daily annoyances like this is always time well-spent.

Anyways, that’s my take, unfortunately not really related to what the right architecture balance is, as you guys seem to have already hit the sweetspot on this. kudos.
Sean

]]>