Maven dependency updates for the team

While refactoring a legacy build at work recently, I ran into an issue with the maven xdoclet plugin. It appeared to be confusing the modules I was trying to use when I would use it more than once. It would work fine and then crash and burn throwing an ambiguous subtask error. Oh well.

Anyways, I fixed the problem by downloading the version 1.2.3 src code, applying a patch, and then rebuilding the xdoclet dependencies. I then applied those changed jars to my local repo cache located in the %user_home_dir%/.m2 directory and test it.

Here’s the reason why I wrote this post. To quickly test your change you can simply apply those fixed jars as described above. If the changes appear to work you can then apply them to the company repository, like Nexus or something. Notify others to clear the dependency cache (it can just be for that specific dependency). This will allow the updated version to be pulled down from the company repository. This is the important part.

Another approach is to create a new version number to force download but you are then updating pom files and trying to override what the plugin uses by default. Whichever approach suites your taste.

I’m sure there’s other ways… If you have any please feel free to share a comment!

Agile 2009 – Refactoring Legacy Code

I will be leading a hands-on refactoring session at Agile 2009 in August! Here’s the session information:

Room: New Orleans
Date/Time: Thursday 2:00-3:30PM
http://agile2009.agilealliance.org/node/630

I look forward to seeing all of you there!

GROOVYMAG May Edition!

I wrote part 2 of “Get Rich Quick with Flex and Grails” for Groovymag. Check it out!

Stumbling towards agility

I’ve been developing software now for several years. Most of those years have been as a consultant among various clients, cultures, architectures, methodologies, and technologies. Now I’m an author, speaker, and currently working for a product company that builds medical management software for the insurance industry.

Through it all I’ve seen one common element among folks that I’ve had the privilege of working with. Nearly every team I’ve worked with desired more agility in what they were doing. Most would agree that the affects of agility for the perceived value or inherent benefit is a good thing. For those that take that challenge on good for you. Some strive to arrive at some form of agility and get there while others well….don’t.

As for me, I’m always stumbling towards agility. It’s never perfect, sometimes ugly, not always easy, but always worth it.

Flex On Java – Note for the readers

We would like to take a minute to personally update you on the progress of our book. Although we are running behind the originally estimated release date, the end product will be a much better learning experience. From the beginning we have been continually refining the book and have taken the great feedback we’ve received to align the book more closely to your thoughts and insights. If you are receiving this letter and were part of the reviews, THANK YOU! Much of the feedback received, all helpful, really matched with how we (the authors) were feeling and helped us to really home in on what we felt would be important to include. Here are just some of the things that can be expected out of the new and improved Flex on Java.

Developer accessibility
When we started the Flex on Java journey we wanted to write a book that would assist Java developers in refactoring Java applications with the richness of Flex. Unfortunately, the sample application wasn’t a good fit for everything we wanted to teach and was absorbing too much of our time trying to make it work properly for the readers. The sample application was an open source product that was not easy to download, build and go. This issue caused us to rethink our approach and we turned to Matt Raible’s AppFuse framework that is aimed at helping developers build applications quickly and efficiently. AppFuse makes deployment and creation of the sample application a breeze and also opens the door to developers who are new to Java. It allowed us to focus more on the topic of integrating Flex with Java while broadening its audience to those who are not Java or Flex gurus.

Hit the ground running (faster pace)
The free chapter available will become an introduction to the book and chapter 1 will now get readers rolling with development on the first page. Chapter 1 will begin with developing the server-side application with the AppFuse framework and then quickly begin integrating Flex in chapter 2.

Deepening focus on Flex integration with Java
The faster tempo and more narrow focus on the topic of Flex and Java integration allows us to quickly go deeper in that topic. We will discuss how to use BlazeDS to connect to the Java server-side including POJO services, Spring services and Spring security in more detail. We will also include working with real-time JMS applications utilizing the Flex and Java APIs.

More focus on scalable frameworks
Good developers move from technology to technology and look for frameworks that allow them to avoid the common problems when designing an application. Frameworks for doing both dependency injection for creating loosely coupled applications and Model-View-Controller (MVC) will be explored in more detail. Frameworks such as Spring ActionScript, Cairngorm, and Pure MVC (and possibly others) will be demonstrated.

House cleaning
There are other topics like building the application with Ant and setting up continuous integration that are important but not part of the main gist of the book, so we moved those topics into the Appendices of the book. There are other housecleaning items that are being performed to make this the best book possible on integrating Flex with Java.

We hope that you will be delighted with the upcoming changes to the book. Please feel free to provide us with any feedback you may have for us. Thanks again!

Sincerely,
BJ Allmon and Jeremy Anderson
Authors of Flex on Java

GROOVYMAG April & May Issues – Get Rich Quick with Flex and Grails

My co-author Jeremy Anderson and I had the recent pleasure of writing for GroovyMAG (http://groovymag.com) and working with Michael Kismal who is a cool dude. It just so happen to make the cover in April where we plug Flex into Java in part 1 of the series. Part 2 will make the application real-time with JMS. This is fun stuff so check it out!!

CODEMASH 2009

CODEMASH 2009 was again another great experience. I want to thank my company Click4Care for letting go for a couple days and Pillar Technology Group for letting me crash in the massive suites they had reserved! I think the pillar squad had more fun pairing with each other in the room then they did at the conference. I have to say it was really fun and they are some real nerds. 

Last year scripting was a big theme. Groovy, Ruby, Grails, and Rails took the conference by storm and this year was a continuation of that but did transition the baton more to functional programming (fp) languages like Scala and Erlang.

Concurrency was a keynote last year and with CPU clock speeds flatlining and more cores being injected concurrency was now the focus of atleast a few sessions this year. Ugh… I have come to a place with concurrency. I have a feeling that the best concurrency is the threaded code that didn’t have to be written at all. Find another solution! It’s just ugly. Just do it when there is no other way out of it.  I noticed in the conference that if you do have to do concurrency you may find yourself picking up a fp language in order to ease the pain.

Lunch with Venkat Subramaniam

During the last day at CODEMASH I had the pleasure of having lunch with Venkat. Venkat has authored such books as “Practices of an Agile Developer” and “Programming Groovy” and is a really fun speaker to listen too. Venkat’s presentations are riddled with personal experiences that he’s learned from.

Venkat seems like a great guy and extremely down to earth. If you have a chance to hire him as a consultant or coach do it!

If you haven’t had a chance to hear him speak look him up. He’s not hard to find. If you are a software developer or a development manager and interested in adopting good practices founded by experience read Practices of an Agile Developer. You will most likely be happy you did.

Stumbling over legacy code

A wise man once said that legacy code is anything without a test. This pretty much means if it was written 3 years ago or even 3 seconds ago. This is true if you consider legacy code anything that is poorly designed or at risk.

I would say that approximately 80% of projects and software that I’ve worked on in my career have been knee deep in legacy code. Most of these projects were going into situations that the client didn’t have unit tests in place already. This can be a very tough situation for an agile developer because this usually means that the build may not be in a place for running tests or the project structure may not be conducive to automation with feedback loops for Continuous Integration (CI) servers to broadcast to a team.

Many times a project that doesn’t start with an agile approach will soon be consumed by the complexity of the design over time. Here is where the cost of change over time grows expeditiously and fixing or changing the code becomes more and more painful.

It seems much easier to start a greenfield project with a good project structure in place. A team can start with an automated build that is ready to execute unit tests and provide feedback on code coverage and quality before you write the first lick of code is ever written. Iteration zero can demonstrate that you are ready to produce value. While you are there, go ahead and connect the build up to a CI server like Hudson and integrate it with your source code repository.

If all that is done before there are dependencies it’s no sweat. Now break to my reality; me stumbling towards agility with legacy code. Everywhere I’ve developed software I’ve heard many of the same and sometimes pretty unique reasons why teams or individuals aren’t leaning towards agility practicing anything that looks remotely agile. Embarrassingly enough, I’ve created some pretty good ones.

What I have found is that you will never reach the final destination of agility but don’t give up because you have to start somewhere. Once you think you’ve finally arrived you will only be surprised by another reason to get back on the bus. For me, it’s a constant challenge. Good me vs. Bad me most of of the time. (Read Venkat’s “Practices of an Agile Developer”)

I have a list of thoughts I’ve compiled for encouraging others to start somewhere when it comes to working with legacy code.

1. If your team must write software let it be the best software your team can write.
2. If your team must change legacy code let them be the right changes.
3. Refactoring legacy code with test driven development is fun! It’s extremely challenging and I bet your death march buddies will feel the victory, doing the touch down dance, and thriving on the new found time they have because of the quality produced. Less defects are always a good thing.
4. Leave the world a better place. When you go into a class to fix yet another legacy bug, look for other improvements that will make the code better. Get atleast the low hanging fruit like unused variables, imports, and methods. Also remove some of that white noise like useless comments, commented out “future enhancement” code snippets, and fixing other noise issues that make changing code more challenging. When I fix a method I check it’s code quality with a PMD IDE plugin and it’s coverage with a EMMA IDE plugin. These tools are freely available! I generally like to eliminate all medium and high priority PMD issues and refactor the method until it has 90% + code coverage. There’s lots of tools out there to try out. The next person that has to work on that code will appreciate your hard work.
5. If the methods aren’t testable make them. Get skilled in making a method or class testable before you begin changing it. Write a characterization test to protect it’s current behavior. Then, refactor the method to make it testable. An example is taking out instantiated objects out of a method that are evaluated and effect the testability of the method. If you take those out of the method you can set their value outside of the method and allow the method to either call for it or accept it as an argument. You may also enjoy the use of reflection for invoking private methods or to get/set private fields. You can also extract out code that could be in it’s own method. This is very common and extremely helpful when refactoring.
6. Unreasonable deadlines equate to things not getting done on time. This is no excuse to write poor code. You will be left with more of a mess in the end when still not making the deadline. It’s also possible that bitterness toward your employer will grow and begin to effect your craftsmanship. Take pride in what you produce and allow yourself to be excited to release it!
7. If death march driven development is what your team’s accustomed to, try to figure out the real problem. This may mean changing your estimation process, breaking work down into smaller chunks, time boxing legacy bug fixing, fixing architectural flaws, eliminating heavy processes or frameworks, and anything else that may be specific to your culture or development environment that is hindering agility or causing death march syndrome. Unfortunately, this expose those who thrive on death march development. It makes them feel heroic because of the “effort” and management even passes out the Scooby snacks for this. The problem with this is that it’s based on hours spent versus outcomes or value delivered. In the end, if what’s produced is the most important thing, do it right without killing yourself or taking others down with you.
8. Teams that want more agility should consider first what not to do. You may find that there’s no way possible to add any new practices to your already overly burdened team. Well, if you’re already over burdened you should take a load or two off your shoulders. Consider the things that you are doing that are not valuable to produce the required outcome. You may be doing some of these things out of practice or “methodology” only because it’s on your team’s SDLC diagram. Always question your team discipline and practices or lack thereof.
9. Being a developer is riddled with decision after decision, line after line of code, method after method, and integration after integration. Take the time to make the right decisions along the way. This right decision will try to fit into the time and budget and will for sure deliver what’s required without compromising the quality of the value delivered.
10. Know your code intimately. Emerge your code with tests. Start with a single small requirement, a little test, and a little code to pass that single test. Refactor the code to make it better and repeat those steps often.
11. Isolate and conquer. Most of the time refactoring legacy code with unit tests will provide proper focus and clarity. However, there are times when the legacy code you are working with is too large and too noisy. This sometimes invites isolating the slither of code that’s causing the problem and fixing it outside its normal inhabitance. Then put it back. I generally don’t like when I have to do this so it may not be that good to do. You may consider what it would take to first make the code less noisy.
12. Help others. The more everyone is making the code better the faster you will all succeed.

Simply said, there may be many challenges to start driving agility in the refactoring of a legacy application. Don’t look at the legacy application as a bunch of constraints as to why you can’t commit to making it better. Instead, embrace the challenge of making it better  one legacy fix after another.  You will always own that choice. Have fun with it.

This is not by any means an exclusive list of what to do. If you’d like to know more about making code better read Bob Martin’s book “Clean Code” or Michael Feather’s book “Working effectively with Legacy Code” for more ideas.

Introducing Flex on Java

I”m currently writing the book Flex on Java with Jeremy Anderson. Flex on Java is being published by Manning and is available now through the Manning Early Access Program (MEAP) and is estimated to be available on bookshelves by May 2009.

Flex on Java is a very exciting topic but Flex on the JVM is even better. Languages such as Groovy and JRuby can also take advantage of Flex and costs much less in development, configuration, and maintainability. This is why the book Flex on Java also covers integrating Flex with Groovy & Grails.

Chapter 1 is freely available to download and provides the details of what you will find in the book by topic.