Java Meets Agile
On September, 10th Daniel Wildt and I presented at JustJava event (the biggest Java event in Brazil) the "Java Meets Agile â€“ A survival guide to adopt Agile inside Java teams" presentation. We presented some practices for Java teams to take that can help them to find problems early in the development process, focusing on business priorities and delivery of more reliable code and products.
The entire presentation is available here.
Here I summarize some of the practices we presented but it is important to remember first what is to be agile from development perspective.
- - Focus on business needs: The business users want working software. They want you focusing on what is important for them. Documentation is important? Of course it is, but first make your software work, donâ€™t spend weeks or even months producing documentation if software is what your customer wants. Focus on software first. Focus on business needs first.
- - Open and honest communication between team members, between business users and the team that is making the software.
Everybody should feel part of the same team, having each one responsibility to build a product.
- - Find problems early in the process. When you focus on the priorities set by the business team you can find potential problems
early in the development process.
- - Faster responses to change: With short iterations you can adapt in an easier way to the business needs and nowadays business needs change all the time.
Having said that, here I summarize these practices.
Practices from an Architect Perspective
- Generic Architectures (a silver bullet): When you spend time trying to design an architecture that tries to solve existing problems and also solve problems that donâ€™t exist yet you spend valuable time that you should be using for the customer needs, for what the customer said it is top priority. I am not arguing architectures should not be well designed, I am just saying that you should do what is enough for the business needs you are working on.
- Get your hands dirty â€“ Prove your architecture: A good approach in this case is to develop a proof of concept for the architecture you are designing, especially if you are going to deal with technologies that you have not worked yet. A good architect practice what preaches.
- Donâ€™t make your project a laboratory for new technologies: I already saw projects failing because too much time was spent trying the best of the technologies. Donâ€™t forget you need to solve your customerâ€™s needs. That does not mean you can never try something new but try it without losing your focus on what your customer wants. And baseline your architecture at some time with a set of technologies and donâ€™t fall in the temptation of trying the latest release of that wonderful framework.
- Think of adopting an SOA approach with an ESB. You can gain agility when having functionalities exposed as services when building new products. You also have a chance to perform transformation inside the ESB to compose new services. For products, you can try Mule, Service Mix or Aqualogic Service Bus.
Practices from a Developer Perspective
- Start coding the most priority tasks first. What would you code first? A complex business logic or the database access?
DAO layer is important, of course, but somehow you are going to connect to the database. But if you focus on that complex logic first than you have a chance to find problems early and discuss with the business team about them or even present to business team the results of your tests according to your view on that business rule. And if you really need the datasource to complete your business logic then you can mock it with easymock. The point is: Focus on what really matters for the business user.
- Have in place a profiling tool to assess how you are dealing with objects. In this post I presented a situation where a profiling tool helped me to solve a problem. Unfortunately, I found that problem in production, but remember that being agile you find problems early in the process so having in place such tool you can avoid problems in the future. So try putting in place tools like OptmizeIt or Netbeans profiler to find out how JVM is dealing with the objects you are creating in your code.
- Prove your tests with FIT. FIT allows you to focus on the acceptance criteria defined by the business team. With FIT you can assess your code is having the expected result according to what the business team defined.
- Coverage tools like Cobertura and EMMA give you information about how good are your test scenarios. With such tools in place you avoid finding later that your test cases have not tested the entire logic.
I would like to discuss with anybody the aspects related to agile methodologies in Java teams, what practices are your team doing and what are the results. If you want, contact me at giovani . salvador at gmail . com