Technology

Changing your app by changing your team structure?

“Show me your architecture, and I will draw you your org chart” is a phrase I’ve heard before, or at least some paraphrase of that. The implication is that a software system will naturally come into alignment with the structure of the team that is building it. Logically and anecdotally, I find this believable, and think that it extends not just to the org chart, but more specifically to the way the team functions.

 
At the No Fluff Just Stuff event this past weekend, I mentioned this in a session where a team lead or manager was expressing concern over how to best manage an offshore development team, 12 time zones away. I got more than a few odd looks from my statement. My suggestion was to align the tasks of this group within his company’s architecture to fit their role in the company. This group is physically separated from the main development team, and does not frequently communicate with the team via ad-hoc methods such as instant messenger and quick phone calls, rather they use scheduled conference calls and high latency email exchanges to communicate. These communication channels are more formal than most, and the relationship is not often based on getting an immediate response. As such, it seems natural to me to assign them tasks, components of the system that communicate with the rest of the system through a more formal, documented interface (compared to communication between subsystems of the U.S. teams that are in the same office), less synchronous. It suits the structure better.

 
While the initial intent of the phrase is more of an observation than a basis for action, I’m interested in seeing if it can be taken one step further. Can a change in the way an organization functions effect a change in the way its software is structured? While bugs are a fact of any software of any complexity, reducing the number of bugs is still often a worthwhile pursuit. In my perception, a large proportion of our bugs are due to communication lapses between the different systems of our application. Each component, on its own, is generally fairly well written – it’s the nuances of communication between them that’s a challenge. Similarly, our team is a collection of effective individuals, but we rarely work together on a task, and even less frequently meet together as a team. My theory is this – that by adding weekly stand-up meetings to our schedule, we can increase the level of awareness of what each of us is working on, increase the amount of informal communication between us, and consequently improve the quality and correctness of communication between our application’s components. Wacky, or worthwhile? Not sure. But having a 10-15 minute standup meeting each week is probably worthwhile anyhow, so to experiment with this idea in the process will be interesting.

General

$10k Treasure Hunt in 16 Cities!

For what may be one of his biggest customers yet, Hugh McLeod seems to have momentarily shifted away from creating “global microbrands” and appears to have helped a big company, Budget Rent A Car, figure out how to use the web for lower cost, higher impact advertising.

&nbsp
Apparently Hugh’s doing his cartoon thing, the entire promotion is being run and spread through blogs, and pretty much conceived of and implemented by bloggers. The result? Video clues lead you to a $10k prize in 16 different cities. Too bad the closet city to me for week 1 is Orlando.

Java

[NFJS Atlanta] Expert Panel Discussion

Panel members are:
 
Venkat Subramaniam – founder of Agile Developer
Keith Donald – one of the Spring junkies
Neal Ford – ThoughtWorks
Scott Davis – co-author of JBoss at work
Andy Glover – Vanward Technologies
Jared Richardson – author of “Ship It!”

 
Question on the Ruby phenomenon – the panel is a bit more sedate on this topic than I expected. No foaming at the mouth yet. Most of the panel members are fairly balanced, suggesting that Ruby is worth our attention to learn, but hasn’t wrested the crown from J2EE as the “it language”, as some people seem to believe lately.
Question on simplified web development, lowered development cycle time – lots of excitement over productivity on Ruby on Rails. Good mention of the Java alternative to RoR – Trails.
Question on goods and bads on Java 5 and Java 6 – one positive is JConsole with Java 5, and the level of instrumentation that comes with a standard JVM. Neal’s concerned about over-engineering in Java, including generics, the addition of Javascript into Java 6. He mentions Bruce Tate’s recent “Joe the Monkey” entry. Scott Davis jokes he won’t upgrade to the next version of Java until they deprecate something.
A decent discussion of agility in architecture. One interesting observation is that the lack of an analog for the DAO in MVC/web frameworks makes the choice of web framework a much bigger committment than a committment to a persistence solution.
Now we have some light references to test-driven development. It’s all fine and dandy, but I have yet to hear people provide a compelling approach to testing our sort of application. We have a heavily interactive web application that loads all of its pages based on user context, and has handshakes and signals to a back end server, sometimes out of sequence. We have pages and pages of Javascript includes. We have a matching engine that requires numerous active entries, and a non-deterministic outcome.

 
That’s about it. Interesting, but nothing unexpected.

 

Where am I blogging from? No Fluff Just Stuff’s Greater Atlanta Java Software Symposium.

Java

[NFJS Atlanta] Managing Agile Projects

I neglected to write about last night’s Agile Estimating and Planning session by Mike Cohn, who will be presenting most of the sessions I’m attending today. It was a good session – the main takeaway was that in planning projects, and particularly in estimating features for software, relative estimation is more accurate than absolute estimation. We’re better at realizing that one feature (or “user story”) is twice as difficult as something we’ve done previously. The idea is that then, once we’ve defined an abstract measure of work, we can gain a pretty good idea of the “velocity” or our team – the number of units of work we can accomplish during an iteration. Re-examining the plan versus results after each iteration helps us find a good equilibrium for our team.

This morning, my first session is Managing Agile Projects. It has a good bit of overlap with yesterday’s session, but addresses a broader array of topics. The prime concern is dispelling myths about agile project management – that agile projects are impossible to plan, that they don’t need to be managed because they are self-organizing, and that the project manager’s role is to buy pizza and get out of the way.

The first new tool to me is the “burndown chart”, which can be used for both releases and iterations within a release. In essence, the y axis is the amount of work remaining, the x axis represents the amount of time for the release or iteration. Each iteration or day, you update the work remaining, and connecting the line of work remaining over time gives you the ability to extrapolate and see how well you are tracking to the project schedule. It gives you a basis to begin investigating sources of slowdown or unexpected efficiency, adjust the release (either date or content) for the actual progress, and improve your estimation for next time.

On to the necessity of managing agile projects, we’re back to my problem of him talking about this stuff in terms of teams. He’s assessing the readiness of multiple teams for agile development. With just one team, we don’t have the luxury of evaluating team by team. We have the team we’ve built, and they’re very good at what they do.

The idea of a task board to “assign” tasks and track progress is fairly compelling. Some of this comes down to better planning of releases, and getting out from under the weight of bug fixes is key to accomplishing this. Also, a lot of these ideas seem predicated on the assumption that tasks to be accomplished are all new work, and thus features can be dropped and you can still deliver a release/iteration. In reality, many of our tasks are wholesale replacement of existing application components. Cutting features from a replcement for an existing component is not an option – a replacement MUST be feature equivalent. I suppose we could cut COMPLETION of the replacement from a given iteration and advance the completion to the next iteration, and cut the scope of the progress on replacement for that iteration. I’m not sure here, and will need to think about it further.

Many of these sessions are useful not only for the content, but also in getting me thinking about our development process and procedures, and how they can be improved. I don’t necessarily have good time to think about this stuff during the rush of a given week.

Where am I blogging from? No Fluff Just Stuff’s Greater Atlanta Java Software Symposium.

Java

[NFJS Atlanta] Intro to Portlets

Kito Mann is here to talk about Portlets (though I normally relate him to JSF). The nice thing about portlets is that they make portals not just a capital-P Portal that the vendors all try and sell, they help commoditize the idea of a portal into a lower-case-p, somewhat portable aggregation of componentized applications. Back at S.P. Richards, we found single sign-on, minor user personalization, and content aggregation to be the most valuable aspects of a portal to our business, and created a “portal” with a few webapps and Tomcat’s single sign on valve. The other bits – multiple device support, portlets, and complex personalization, weren’t really necessary for the needs of the business. At the time, the open source portals didn’t seem mature, and the Portlet spec had just been approved.

A question to ask shortly… Many Java APIs are fairly useless without the vendor-extensions. How much of the common portlet functionality depends on vendor-specific configuration?

Generally, portals are bite-sized applications that can be embedded in a portal view alongside other portlets. Google has an example of a non-hideous portal.
The “Top Stories”, “Weather”, and “Quote of the Day” would be portlets in Java land.

The rest of the session has been a fairly mundane tour through the Portlet API itself. Mostly stuff you could pick up from a magazine article. The actual demo of the portal using Liferay is fairly interesting. It looks like Liferay has come a long way in the past year or two, in terms of look and usability. Getting it working was also a beast at the time, and it didn’t respect J2EE security, but if I need a portal, I’d have to at least give Liferay a second look, based on what I’m seeing.

Where am I blogging from? No Fluff Just Stuff’s Greater Atlanta Java Software Symposium.

General

The W Hotel's un-mediocre water

Seth questions why restaurants bother to serve bland, mediocre bread/rolls, and more generally, why businesses bother to churn out “good enough” (or worse) products rather than chasing something special. Red Lobster’s cheesy rolls come to mind – they’re special. Sometimes I want to go to Red Lobster just for those biscuits.

 
This weekend, I’m at a conference at the W Hotel. Much like the Red Lobster biscuits, they’ve gone to great lengths to avoid being low-effort boring in any way. Some of the style here is a bit odd to me, I don’t love it, but you can tell they’ve spent time and money to really try. Rather than building a lobby that tries not to offend by looking like the least common denominator, they’ve built a lobby that will displease some people, but make raving fans out of others.
This attitude extends even to their water, pictured to the right. Look closely. Every pitcher of water on the tables here is in this unusual pitcher, with a slice of lemon, a strawberry, a slice of lime, and a sprig of mint. On a per-glass-of-water basis, does a unique pitcher cost that much more than a boring pitcher? Do a couple of pieces of fruit and mint in a pitcher really cost that much? Not at all. Do they risk alienating some folks who don’t want leaves and fruit flavor in their water? Sure. But it’s consistent. The W Hotel is proving they’d rather take risks and win fans by being distinctive than be boring and try not to offend. Good for them.
Java

[NFJS Atlanta] Java 5 Features

Maybe this session sounds like old hat, but I’m looking for more ammo to add to the list of reasons we should jump to Java 5 from either 1.3 or 1.4, and sooner rather than later. Already on the list is that we’d like to get to Tomcat 5, and introduce Hibernate. In introducing Hibernate, I’d prefer to go straight to H3 with annotations rather than do a double effort of implementing Hibernate with typical mappings or XDoclet, and then moving to annotations. Venkat Subramaniam is presenting.

I’m going to go about this session a bit different and actually post the entry now, and update it as the session progresses.

  • Autoboxing – the nice syntax cleanup that turns a bunch of casting from primitives to objects (int to Integer and back). I know that it’s just Java doing all the casting behind the scenes, but I like the way it takes some of the ugly and tedious code out of Java source. The gotcha I wasn’t aware of is that if you write “int myInt = myArray[0];” on an Integer[], and the element in the array has a null value, you get a NullPointerException. Ouch.
  • Happier for loops – for(int i=0; i
  • enums – nice to finally see a sane way of expressing enums in the Java language. Once again, it’s little more than magic hand-waving behind the scenes, but it’s a real improvement to readability, and short-circuits the constants-as-static-final-variables-in-an-interface anti-pattern, with type-safety as a bonus. Some folks have a real beef with Java shoe-horning these features into the language, I give them a ton of credit for accomplishing their magic in the compiler rather than mangling the runtime with all of these features. I also haven’t seen this magic of adding a method to an enum – very interesting. EnumSet and EnumMap are also news to me.
  • varargs – I hadn’t even heard of this until today. More nifty syntax sugar that allows you to supply a variable number of arguments to a method, with type safety. Declare your method public static void doStuff(String…), and you can call it with doStuff(“one”), doStuff(“one”, “2”, “three”) – Java will, behind the scenes, make your method accept a Sttring[], and bundle up your method call parameters into a String[]. Very cool.
  • Annotations – one of my favorite new features in Java 5, based on the headache it relieves in creating Hibernate mappings. Defining an interface is quite wacky, but I think far more people will be using annotations than defining them.
  • Static Import – Venkat isn’t a fan of this feature, and neither am I. Static import lets you import all of another class’ static methods and call them without even naming the class they belong to. The methods are called just as if they were defined inside the class. This looks like it has major confusion potential, with a minimal value-add.