No sooner had I written about a presentation that’s been making the rounds and how it might affect our teams at Red Hat, I find this piece on DZone. Super relevant, especially since we often occasionally use the scrum-of-scrums practice.
From the slides:
Make communication across context boundaries explicit. Use integrating teams to agree how to handle the interface and integration between systems. Integrating teams should also agree on and write acceptance tests that confirm integration across boundaries. (Emphasis mine)
Kris Gale from Yammer posted a great narrative about how he believes the traditional engineering organization is dead. In particular he calls out the failed strategy of having managers orchestrate multiple teams who are aligned along technical ownership:
If you imagine a typical medium to large engineering organization chart, you might have a front-end team, a back-end team, and potentially a “middleware” team. Those teams own their code bases; each one has a proprietary manager and those managers report up to some boss. The point is that the organization usually matches the code’s architecture. When it comes time to do work, the managers at the top have to make decisions about what’s being built before they can break up and delegate work. You then have questions like “What is the backend team going to do?” and “How does that interface with the front-end team?”
I agree with this notion but I think his definition of “managers at the top” may differ from mine – nowhere in my history has a “top level manager” orchestrated what the technical teams work on. They might set project priority but nothing more granular than that. It’s possible that I’m just quibbling about definitions. So be it.
I didn’t always think this way. My peers and I have been talking for some time about re-organizing the engineering teams we manage in just the way Gale describes. My objection to it has always been that when you strew responsibility for a single application tier or technology across teams, you wind up with lousy code — inconsistent, unreadable and with potential duplication. I’ve advocated for keeping code that lives within a certain technical domain owned by experts in that domain.
As it has played out, we have struggled a lot with driving features into our products when they concern two, three or more work streams. So I believe we’ll be taking a similar tack to that which Gale proposes. The cost of adding features due to this overhead is not trivial.
I’ll try to take some time and post my thoughts as we adapt.
Presentation outline and notes/references for my Traiangle Java User’s Group presentation given on April 18, 2011. The slides used during the presentation are merely an instrument for me as the presenter; they aren’t available for download. Below is the rough outline I (kinda) followed and at the bottom are references and helpful links. Feel free to leave any and all candid feedback in the comments. Thanks for attending! Continue reading
Some time back, I whined about not having a good agile project tool. Times have changed: four years and two jobs later I’m happily doing Scrum development using Rally.
I came across something disturbing recently and I want to get my two cents on the table because this isn’t the first time it’s come up. Several components in the project I’m assigned to store various configuration attributes in text files. Whether they’re name-value (properties) files or XML data, this is a good choice because it allows the customization of application behavior without code changes or redeployment … if you do it properly.
I’m typing this post from the Gnome blog post client installed on my laptop which is now running Ubuntu Linux. I took the plunge a few days ago after getting the itch to try an alternative OS. I knew that if I did a dual-boot, I’d bail out and revert to Windows in a few days. So, I blew away the entire disk and let Ubuntu 6.10 have its way.
So far I’m pretty pleased. The out-of-the box suite of applications is more than adequite for the average user, and it’s Linux, so the power user will never be left wanting. The only stumbling I’ve done is on multimedia codecs. So far I have yet to get anything resembling Internet-type audio/video to play, but I’m not sure I’ve done everything right. Flash 9 beta is installed so all my favorite rich-clienty sites work well (Google Finance, YouTube, etc). No MP3 or AVI joy yet though.
I’ll wrap this up and hope it posts, with the thought that I’ll do a more in-depth review soon.
Not much else to say about this sweet plugin.Â It lets you view any webpage using IE without leaving Firefox.Â Kickass.
Thinking about beginning a new JEE project is as unsettling as it is exciting. On the one hand, you’re going to get your hands dirty with some new and challenging business problem to solve, you can use the latest and greatest JVM and of course let’s not forget the choice of many excellent application/persistence/web frameworks. On the other hand, you have … the choice of many excellent application/persistence/web frameworks!
I think we can all agree that choice is good, but is the sheer number of non-trivial frameworks really unifying the java community, or are we breeding segments of the population who know only a subset of what’s out there?
When you’re an ASP guy, you pretty much have you work cut out for you. Same goes for the new kid on the block Ruby [on Rails]. But Java, in its maturity, has brought so many innovations to market that one could make an entire project out of evaluating frameworks for use in any given project!
The days of Struts & JDBC are pretty much over, kids. Do you use Spring at the web tier? How ’bout JSF or Tapestry or WebWork? Do you decorate with SiteMesh, or assemble with Tiles? Maybe you are into JSP includes or writing a lot of custom tags. Do you manage your middle tier with Spring, or opt for the latest appserver’s EJB3 implementation? It might seem like everyone is using Hibernate for persistence, but it aint the only kid on the block. TopLink Essentials is bundled with GlassFish and other EE5 offerings will be supporting JPA as well. This is just the tip of the iceberg.
How do you decide?