[NFJS Atlanta] Transitioning to Agile

Mike Cohn’s 12 things you MUST do in transitioning to agile:

  1. Pick the right project – find the project with the proper intersection of duration (2-4 months), size (1-5 teams), with a business sponsor, and importance (high – keeps you on task).
  2. Pick the right iteration length – XP now says 1 week, Scrum says 30 days – just pick what works and be consistent.
    • Will you allow change during an iteration? (Refinement of requirements is not change)
    • He recommends no – pick an iteration length equal to how long the organization can go without changing its mind.
  3. Get everyone on board – make sure all key players surrounding the project buy into Agile
    • Objection – it only works with talented people. No, but you need at least one developer who can fluidly move between different development techniques. (But you pretty much need someone like this for any project to succeed)
    • Objection – it only works on trivial projects. This is disproven by the number and breadth of complex projects that use agile (Yahoo, Joint Strike Fighter).
    • Objection – it’s not appropriate for all projects. This may or may not be true, but just use common sense, use it when it makes sense
  4. Have a “customer” – an actual customer or product owner, and keep them consistently involved.
  5. Start with a beachhead team – for larger organizations, start with a smaller, focused group and help them fight through the infrastructure and process issues until they’re succeeding. Ensure that this team is fully cross-functional.
  6. Deliver – makes sense. Don’t allow the team to miss any deadline, large or small. Missing a small deadline trains the team to miss parge ones.
    • Stress quality, not speed. You want code you’re PROUD of, that you would hang on your mom’s refrigerator.
  7. Automate – automate unit tests, acceptance tests, regression tests, builds, deployment
    • Test automation tools – JUnit, FIT, FitNesse, HttpUnit, HTMLUnit, Canoo WebTest
    • Continuous integration – Automated nightly build at least, if not continuous – Cruise Control, AntHill
  8. Follow a guide – you need someone who’s been there before, either an employee or an outside mentor or coach.
  9. Track and communicate progress – many approaches, from a task board to formal reports
  10. Meet Daily – use a daily standup meeting to coordinate, communicate, and make committments to one another
  11. Reflect – at the end of an iteration, reflect and discuss what we’d like to start doing, stop doing, and continue doing
  12. Don’t try it all at once – start with the practices that seem most valuable, prioritize the ones you want to adopt later in a backlog.

His preferred order of implementing things – Requirements as user stories (light requirements), estimate and create a release plan, nightly or continuous build with tests.

I enjoyed the talk, though much of it seemed focused on how to sway the momentum of a large organization toward agile. He called a company a “small shop” when it had 100 developers. Our entire company is around 50 people, including operations, support, sales, etc. So our challenge is more about the proces to adopt rather than the politics of adopting it. Some later sessions may help shed some light on this decision.

Where am I blogging from? No Fluff Just Stuff’s Greater Atlanta Java Software Symposium. I was using the [GAJSS] heading before, but thought NFJS Atlanta might be more clear, and better signal the relevance of the entires to the Atlanta community better.


[GAJSS] Keynote – Language Oriented Programming

Neal Ford is keynoting on using dynamic languages to build domain-specific languages. It’s a stark contrast to Dave Thomas’ keynote from 2 years ago. Dave was very philosophical on the ways we think about doing development. Neal is right down there in the code – source is getting more screen time than powerpoint at this point. He contends that Java is already commonly using domain specific languages in the form of XML configuration files for our frameworks. [As an aside, the wireless access here in the main session room/dining room is actually reliable. JRoller still continues its attempts to eat my drafts as I save them.] Thus far, I honestly think he (along with half the developer community) has gone a bit far off the deep end in terms of the pain of developing in Java. Perhaps I’m numb from being knee deep in Java for more than 5 years, but the repeated dismissive references to “curly brace languages” are a bit overstated, I think.

He’s mentioning Language Workbenches, but at this point it looks like the current set of language workbenches are all proprietary, vendor-based offerings. In my opinion, until there are multiple, freely available language workbenches, perhaps an Eclipse variant or plugin to handle it, this technology will face serious challenges to wide adoption.

So the general idea is that you use this language workbench thing to create a meta-language, that defines a language that is very similar to the problem domain. The problem I see with this is that each individual problem at each individual company is defined with its own domain specific language. One of the reasons community acceptance is such an important selection criteria in choosing which Java framework to use for a particular problem type is the knowledge that the more known the framework, the easier it will be to hire someone who immediately understands at least that framework, even if they don’t understand the company’s software yet. For lower level concerns, I can almost understand a use for this – in replacing the Java frameworks. At a higher level, in terms of a business’ actual problems, such as CRM, manufacturing, etc, I see a potential problem where you now end up hiring developers who understand neither your language nor your problem domain.

This is my gut-shot reaction. I’m going to have to chew on it a bit more and reach more long-term conclusions. Time to head home, starting back at 9 AM tomorrow.

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


[GAJSS] JAAS & Java Platform Security

More Stuart Halloway, now talking about Java Security (slides here. [Incidentally, Roller definitely needs a draft autosave feature. On a spotty network, this is KILLING me that any given draft save can kill my entry. Resorting to a copy of my entry before saving a draft is a cheap workaround.]

We start off with a look at the typical java platform security stuff, the java.policy file and such. I’ve never had much use for this in my work, so the move along to JAAS is a welcome one.
A good explanation is that a Subject in JAAS is a container, and a Principal is a set of roles, identities, and whatever else associated with that Subject. This is helpful for me, since I’ve always found those words unintuitive and confusing. The Principal class is nothing short of useless. The fact that Java continues to pump out specifications that are so dependent on vendor extensions to do anything useful is insulting and counter-productive to everyone but the vendors who depend on it as an obstruction to portability. [Just survived ANOTHER JRoller choke thanks to cut and paste.]

He also points out a nice permissions sniffer for making the trial-and-error process of figuring out which permissions your authenticated user (Subject) is requesting that it doesn’t have, and adding them to java.policy.

It’s been interesting, but perhaps hits java at a lower level of abstraction than I’m used to. I do mostly web apps, so my perspective is largely on the level of users and roles that are exposed in a webapp, and the permissions that are exposed in that relationship. The closest I get to worrying about JAAS implementation details is selecting which login module I want the app server to use. I don’t deal in permissions very often. This beef is probably more about my selection of this session than Stuart’s presentation of it.


[GAJSS] Crytpography for Programmers

I had a good bit on this talk, but JRoller’s habit of eating a post when you “Save as Draft” but the session has expired killed it. Stuart Halloway gave a fairly good overview of key cryptography concepts. Not enough to write your own algorithm, just enough to be dangerous, and probably enough to effectively use existing alogrithms in your application, which is really all most of us need anyhow. He alleges, based on the advice of several colleagues, that the JKS Java keystore implementation is NOT secure, and should not be used. Another nugget is that when generating random numbers for security-sensitive purposes, use SecureRandom, not the basic math package Random implementation. Past that, it’s mostly been an overview of key crypto concepts, keys, symmetric and asymmetric encryption, hashes, stuff like that.

Probably the most compelling point is that when evaluating the security of a crypto algorithm, the standard metrics that are spewed – key length, block size, etc. aren’t really relevant. What IS relevant is that number of steps required to break the crypto. And let me reiterate what should be obvious – unless you are an encryption expert, you are best off using the known, time-tested algorithms without known exploits, rather than attempting to write your own.


[GAJSS] J2EE Performance Monitoring

Ramnivas Laddad has obviously tinkered with a broad variety of performance monitoring techniques for J2EE. While he’s mentioning commercial projects, he also has plenty of practical free or built-in approaches for monitoring performance.

He’s pointed out Sun’s JVMPI, which is the built-in Sun approach to instrumenting an app for pre-1.4 JVMs, but the app has to be started in a special way, and runs dirt slow. I’ve used plenty of commercial products that use this API, and it’s brutal. If you do go down this path, the Eclipsecolorer plugin looks like a nice complementary tool to analyze the output. Using a modified 1.4 JVM or Java 5.0+, JVMTI becomes available as a part of the JVM, and it appears to be quite useful – one more feature to add to the list of useful reasons to upgrade our product to Java 5.0. JFluid in NetBeans gets a mention.

For database analysis, he recommends P6Spy (free) or JDBInsight (not free), and showed a nice example of decorating the JDBC connection to log timing information on all queries without intruding on the persistence code. A similar timing approach can be applied to servlets using a servlet filter.

We get a look at AOP monitoring approaches, not surprising given Ramnivas’ expertise in AOP (he’s presenting 3 other sessions, all on AOP). Some nice example code of an abstract service monitor aspect, along with an implementation. A decent idea, but the question remains of whether to add AspectJ to the massive framework stack already in place in most of my apps.

Finally, we get a look at load generation tools. The usual suspects are here – JMeter (normal web apps), TestMaker (for web services), Grinder (mentioned from the peanut gallery), and LoadRunner (if you’re rich).

The wireless network connectivity in this room is miserable. Unfortunately, a majority of the Agile sessions are in here. There’s a wall jack for ethernet, but who knows if it works – I don’t know when the last time was I used a hard line with my laptop.

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


Greater Atlanta Software Symposium Tomorrow

Tomorrow, the No Fluff Just Stuff road show comes to town for the Greater Atlanta Software Symposium. I’ll be heading there along with a couple of other developers from our team here. Wifi and power outlets permitting, I’ll endeavor to blog the sessions as I go.

I look forward to this event each year – it is one of the most pragmatically useful and economical Java conferences out there. If you have the weekend and cash available, I think they still have some spots open. It’s as good a collection of Java and software development experts as you’re likely to get at a non-vendor-sponsored conference.

With my job responsibilities drifting more and more into development management, I’ll be spending a good bit of time in the Agile development sessions, but also get some good time spent in more concrete, learning, development sessions. I hope to see you there!