wood burning stoves 2.0*
The moose likes Agile and Other Processes and the fly likes Release It!: Based on Java and J2EE? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Release It!: Based on Java and J2EE?" Watch "Release It!: Based on Java and J2EE?" New topic
Author

Release It!: Based on Java and J2EE?

Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Michael,

It seems that you put heavy weight on design and architecture. It does not necessarily be Java but here at JavaRanch the risk is high that people go for Java (in case of code samples).

And since we have people here involved in Enterprise Software Development, J2EE is also not far away.

What role do Java and J2EE play in your book?

Regards,
Darya


SCJP, SCJD, SCWCD, SCBCD
Michael Nygard
author
Ranch Hand

Joined: Jan 03, 2007
Posts: 40
Darya,

While the principles I discuss are broadly applicable, almost all of my examples are Java and J2EE based. This is mainly because that's where my experience lies. I could try to present Ruby or .Net examples, but they wouldn't be as credible.

There are several sections that are very Java-specific, for two reasons. First, the majority of enterprise-class distributed systems---and especially web systems---today are written in Java. Second, I've dealt with many more Java-based systems, so I've seen (nearly) all the ways Java can break.

For example, I have an extended discussion about sessions, objects in sessions, and SoftReference objects that is very specific to Java. I also have a discussion JMX, JConsole, and JMX-based scripting consoles.

So, overall, I would say that the broader architectural principles are quite generic and portable, while some of the specific implementations are biased toward Java.

Cheers,
-Mike


Michael T. Nygard<br /><a href="http://www.michaelnygard.com/" target="_blank" rel="nofollow">http://www.michaelnygard.com/</a><br /> <br />Release It! Design and Deploy Production Ready Software<br /><a href="http://pragmaticprogrammer.com/titles/mnee/index.html" target="_blank" rel="nofollow">http://pragmaticprogrammer.com/titles/mnee/index.html</a>
Hanumanth Kanthi
Ranch Hand

Joined: May 27, 2004
Posts: 74
Mike - Wondering if you have any discussion in your book on how an Architect team should work in an IT shop where agile processes/practices are followed rigorously.

Thanks in advance,

H. Kanthi
Michael Nygard
author
Ranch Hand

Joined: Jan 03, 2007
Posts: 40
Hanumanth,

I'm not 100% sure how to interpret your question. The advice in my book will certainly work well in an agile shop (though it's not necessary that you be agile to benefit from it).

Somehow, though, I don't think that's quite the question you're asking.

When you refer to "architect team", do you mean a separate team of architects designated as the architects (or even "enterprise architects") who are expected to provide architecture for all projects across the company?

Regards,
-Mike
Hanumanth Kanthi
Ranch Hand

Joined: May 27, 2004
Posts: 74
Yup.... I mean to say "Enterprise Architects" in a company practicing Agile Practicess......
Michael Nygard
author
Ranch Hand

Joined: Jan 03, 2007
Posts: 40
Hanumanth,

I would have to say that my past experience makes me rather skeptical about such a structure.

This is outside of the content of my book, so I'm speaking (typing) extemporaneously here.

I've worked in environments that had an enterprise architecture group that was factored out of the individual project teams. I've also worked in agile projects.

On the agile projects, I really have found huge benefits to being all in one room. Even as an architect, you never know when a crucial question will come up. Just being in the room increases your odds of being there for those dozens of vital little decisions need to be made. That doesn't mean the architect necessarily makes all of those decisions: in fact that would be very harmful. But, even if you're only listening with one ear, you can intercede when some larger forces are not being addressed correctly. Continued presence in the room also means that you have the correct context when larger-scale, wide-impact decisions need to be made. Lacking that context, you risk being the "fly-by architect". (Sometimes also called the "seagull architect". It's not a compliment.)

The problem is that dedicating an architect to each project team is exactly the opposite of the reason companies create an architecture group to begin with. Companies usually do that in order to matrix out the architects across multiple projects, precisely so they won't be dedicated (consumed by) a single project.

In general, I'm not at all a fan of matrixing people onto projects. Everything I've read about the Theory of Constraints, Lean Software Development, Agile Methods, and anything written by Tom DeMarco tells me that matrixing people is the opposite of what you should do. That the "all in one room" aspect of agile methods eliminates matrixing is one of its largest benefits.

Then, too, there's the issue of designating one group of people as architects as if "ordinary developers" don't or can't do architecture. This disempowers and demotivates the developers and communicates to them that they should not think about architectural concerns. I'd prefer to see more people thinking in terms of large-scale structures and effects, not fewer.

Again, this is just my personal viewpoint. The material in my book applies equally well to agile and traditional shops, to matrixed and non-matrixed organizations.

Cheers,
-Mike
Jesus Angeles
Ranch Hand

Joined: Feb 26, 2005
Posts: 2057
Mike, which roles (developer, project manager, etc.) in the j2ee-based system workplace can benefit from your book? And also which role would benefit most?

(Just to have a high level perspective, so I can prioritize when to read your book)
[ February 15, 2007: Message edited by: Jesus Angeles ]
Hanumanth Kanthi
Ranch Hand

Joined: May 27, 2004
Posts: 74
Mike - thanks for write-up appreciate it....I was exactly in line with what you penned down.

Jesus - it seems Mike's book is good for both Developers and Project managers as well ..... I am sure Mike can surely comment more on it.

Cheers,
H. Kanthi
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Everything I've read about the Theory of Constraints, Lean Software Development, Agile Methods, and anything written by Tom DeMarco tells me that matrixing people is the opposite of what you should do.


Ha! I'm laughing because I agree with you and yet "matrixed architect" is exactly what I'm going to be, starting Tuesday. My freshman year in college band I played baritone sax and sat next to the bassoon player. On one serious orchestral piece, he elbowed me and said "Let's see how fast we can make this go" by subtly rushing the downbeats. It was pretty effective. I think that's how I'm going to approach this new team; I'll let you all know if I'm still employed in a while.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Michael Nygard
author
Ranch Hand

Joined: Jan 03, 2007
Posts: 40
Originally posted by Jesus Angeles:
Mike, which roles (developer, project manager, etc.) in the j2ee-based system workplace can benefit from your book? And also which role would benefit most?


Jesus,

I'd say: Architect, Programmer, Project Manager, and QA, roughly in that order.

The architect role is obvious. Many of the issues deal with interfaces between systems, capacity planning, building to meet SLAs, achieving reliability and availability... these are clearly the responsibility of the architect (but not solely the architect!)

Programmer involvement is also fairly obvious. Great architecture can be destroyed by poor programming. I have examples of solid designs brought down by bad exception handling. Better architecture would have helped contain the damage. Better coding would have prevented the damage.

[As an aside: I do consider it a fundamental principle that you can never prevent 100% of errors. Just as bugs will always happen, some of those bugs will kill systems or subsystems. It's important to keep this in mind! If problems cannot be fully prevented, then you'd better find ways to contain and recover from them!]

Project managers are often faced with a dilemna. They know they'll be held accountable for the overall success of the project. Not just its schedule and budget outcomes, but the quality of the product as well. On the flip side, they also know they're not the ones who can evaluate the work product to really see if it's being done well or not. I think this book would be good armament for a project manager who wants to make sure that important considerations are not being missed.

For the quality assurance professional, this also provides a set of considerations --- many of which will not be found during testing --- that bear investigation. If QA is more than just testing (as I believe it should be), then this provides a set of issues that QA should bring to bear early in the examination of a project.

I also happen to think that business managers (the "gold owners", as XP calls them) should read the case studies. They'll probably get nightmares from them.

Cheers,
-Mike
[ February 16, 2007: Message edited by: Michael Nygard ]
Michael Nygard
author
Ranch Hand

Joined: Jan 03, 2007
Posts: 40
Originally posted by Stan James:

My freshman year in college band I played baritone sax and sat next to the bassoon player. On one serious orchestral piece, he elbowed me and said "Let's see how fast we can make this go" by subtly rushing the downbeats.


I love it! That's a great analogy.

I've often used the charged plasma / magnetic field analogy to describe how some people can change the culture around them while others are changed by the culture they're immersed in. I think it's a perfect analogy.

Mainly, I get blank looks, though.

Cheers,
-Mike
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Release It!: Based on Java and J2EE?