![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Kayakers and canoeists don't get along, but when it comes to building an expedition, they put their differences aside. Canoes can hold more gear, and paddlers can get out of the boats easily for quick scouting; kayaks don't swamp in big water and are useful for rescuing the occasional canoe paddle (or canoeist) that slips out of the capsized canoe. It's not about personalities; it's about getting down the river in one piece.
This article is about getting through a different kind of activity in one piece: application development. Agile development processes like Extreme Programming (XP) and Scrum seek to reduce process overhead. While many different processes exist, they all have common currents running through them:
- Increased emphasis on customer involvement, rather than heavyweight requirements documents
- Improved quality and design through refactoring; heavy, automated unit testing; and continuous integration
- Small teams with less formal communication and more informal communication (15-minute stand-up morning meetings and more pair programming)
- Short, consistent cycles with customer feedback at the end
Agile methods strip away unneeded process until you're left with just enough to get the job done. While many programmers understand the power of lightweight, agile methods, most managers are accustomed to a more traditional process. If you think agility can help you, learn how reconcile traditional management with an agile development process by applying these ideas:
- Change the language you use to focus on principles, rather than processes.
- Create small, smart teams.
- Focus on measurable deliverables.
- Value simplicity.
- Refactor your code and automate your tests.
- Get feedback from your customers.
When you're trying to inject an agile process into a conservative company as a programmer or architect, it's best to stay away from dogma -- that is, keep the focus on principles rather than process. If you rave about the benefits of XP for 10 minutes, a typical boss will focus on one word: extreme. Because the boss is paid to mitigate risk, you're going to fail. Instead, you can pick up on a few problems your management wants solved. Then, choose agile principles that help solve them.
For example, consider pointing to a serious bug that shipped with your product, then ask to do more automated unit testing. Or, point out an incident in which your customer was not satisfied, and ask for better access to your customer through frequent demonstrations. You could ask to run automated builds with cruise control after an integration problem goes unnoticed.
In each case, you're pointing out specific problems and offering solutions. Each step also brings you closer to a more agile process. Stay away from controversial words describing practices that have failed or are unlikely to gain approval. For example, pair programming is often a tough sell, but greater teamwork or mentoring aren't. The first step in changing your process is changing your language.
In a conservative company, cultures may evolve that accept mediocrity. The single biggest criterion for a project's success is the makeup of the project team. Small teams with talent, skill, and motivation succeed. If you really want to improve your process, make sure small teams that know what they're doing are building the software. As harsh as it may sound, you will always have to deal with teammates who don't perform. With global pressures and the cost of building software today, it's too costly to carry dead weight, so the welfare of the whole team trumps the welfare of any single player.
Training is important, too. You might get away with skimping on training in the short term, but you will get burned if you do so for too long. You don't have to send people to classes for weeks at a time. You might lobby for a half day per week to study and play with new technologies. Excellent weekend symposiums like the No Fluff, Just Stuff series can help you ramp up without too much time away from the office.
Finally, make sure your team has all the personality types they need to succeed. You need innovators and meticulous record keepers. You need programmers who can trudge through details and those who can see the big picture. Make sure that all key roles are filled.
Each step of a process produces one or more measurable results and deliverables, called artifacts. Agile processes seek to reduce the number of artifacts to those the customer needs. Working code is the single most important artifact. Agile processes rely on frequent refactoring and unit tests to improve designs. Agile processes don't generally mandate piles of documents. You can always build design documentation that helps you do your job, but your focus should always be on delivering working code.
Conservative companies tend to want more documentation with a heavier process. The management probably equates fewer artifacts with less discipline. That's not true. Agile processes have just as much discipline; it just comes from other sources, as shown in Figure 1. Early and frequent customer contact combined with a simple requirements spreadsheet replace traditional functional specifications and sophisticated use case diagrams. Added emphasis on refactoring and automated testing improves designs dramatically without the need for notebooks full of class diagrams.
Figure 1. Sources of discipline in agile processes
If management demands formal documentation, you can often use tools to generate Unified Modeling Language (UML) diagrams directly from working code, rather than building the documentation from scratch. The products in the IBM Rational Suite® can produce documentation from existing code effortlessly and with very little user intervention. If you can't spend the money for such tools, for under US$200, you can use a tool called Enterprise Architect to build UML documents automatically from your code. With only a little layout work, you can deliver binders full of documentation with little impact on your schedules. It's often better to generate documentation after the fact if it helps move your agenda forward, rather than fighting a battle to formally change the process.
In larger companies, it's easy to slip into the bad habit of building in too much code to handle future requirements. True, you want to build flexible, extensible software, but you can go too far. It's far better to build code that's easy to refactor and exactly what you need. Premature optimizations, support for possible future features, and design patterns that don't support your immediate requirements can waste too much effort. If you find yourself falling into this trap, these techniques can help:
- Make a list of requirements for an iteration, and write only the code that supports those requirements. In extreme cases, create code only against a formal requirement or bug.
- Always look for a simpler solution before you code something. You want your code to be only as complex as necessary.
- Write your test cases first, and write only enough code to make your test case pass.
Refactor mercilessly, and automate your tests
If you commit yourself to simple coding, your simple abstractions will sometimes come up short. You've got to be willing to refactor your code when this happens. But you won't refactor, especially at the end of an iteration, if you're afraid of breaking something. Refactoring goes hand in hand with automated testing.
In larger companies, management often pushes back when they find developers doing automated unit tests. Be prepared to defend the practice. The best way to do this is to point out that your test cases help you limit the amount of production code you write, allow you to catch bugs when they first occur, and are cheaper (in terms of time and money) to fix. In my experience, test-driven shops are usually at least as productive as their counterparts.
Part of creating a quality product is making what you think you're making. Automated testing helps here. More importantly, quality means making what your customers want. You've got to get feedback from customers and get it frequently. These tips can help:
- Schedule demonstrations with your customers every week. Show them all the new functions.
- Users and managers get frustrated when they can't see progress. Keep in mind that to them, it's not done until you can see it on the screen. If you're working on plumbing, provide a way to see the plumbing through a user interface -- maybe an administration panel.
- Invite higher management to your demonstrations. They like being in the loop, and you've got a better chance to keep them on your side if they can see steady progress.
- Work on business requirements, rather then blocks of functionality, with the highest-priority item features first. If each coding task implements tangible business value, you can stop your iteration at any point and deliver the most important features to your customers.
Good feedback doesn't happen by accident. You need to ask for it.
Agile process and conservative companies don't have to be like oil and water (or canoes and kayaks). Developing software for big conservative companies doesn't have to relegate you to a traditional process, and you don't have to call what you're doing agile or extreme. You can gain tremendous value by integrating new agile practices.
In the next few articles in this series, I show you some alternatives to Java™ technology. We'll look at problems in the Java programming language itself that may hurt your productivity. Then, we'll explore frameworks like Ruby on Rails that provide excellent productivity for certain types of problems.
Learn
-
Lightweight development is a huge topic, and developers throw the term around so often that it's hard to tell what it means. "Secrets of lightweight development success, Part 1" introduces this series and you to the core principles and philosophies behind the movement.
-
Heavyweight architectures, such as Enterprise JavaBeans, can be overkill for everyday problems. Part 2 of the series introduces lightweight containers and explains how they can provide the services your business needs without tying you to a given programming model.
-
Learn the basics of lightweight containers in Part 3 of the series.
-
In "Part 4 of the series, Bruce Tate compares three popular containers: Spring, HiveMind, and PicoContainer.
-
Use Rational® software to build documentation from code after the fact, satisfying management without hitting your schedule so hard.
-
Better, Faster, Lighter Java, by Bruce A. Tate and Justin Gehtland, (O’Reilly, 2004) provides a good overview of lightweight development.
-
"Object-relation mapping without the container," by Richard Hightower, shows how to use Spring persistence with Hibernate.
-
Get evaluation products from DB2®, Lotus®, Rational, Tivoli®, and WebSphere® and start building applications and deploying them on IBM middleware. Select the Linux® or Windows® version of the Software Evaluation Kit (SEK).
-
Visit the developerWorks Open source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.
Get products and technologies
-
Innovate your next open source development project with
IBM trial software, available for download or on DVD.
Discuss
-
Get involved in the developerWorks community by participating in developerWorks blogs.
Bruce Tate is a father, mountain biker, and kayaker in Austin, Texas. He's the author of three best-selling Java books, including the Jolt winner Better, Faster, Lighter Java. He recently released Spring: A Developer's Notebook. He spent 13 years at IBM and is now the founder of the J2Life, LLC, consultancy, where he specializes in lightweight development strategies and architectures based on Java technology and Ruby.
Table of contents
Next steps from IBM
With the WebSphere Application Server you can benefit from the simplified EJB 3.0 development experience, new persistence model, and interceptors.
- Try: Download a free trial version of WebSphere Application Server Community Edition, the lightweight Java 5 application server with robust EJB 3.0 funtionality.
- Article: Learn how call patterns and components involved in making calls to EJB components deployed in the EJB container operate in WebSphere Application Server.
- Tutorial: This tutorials shows you how to create an enterprise J2EE application that implements both Plain Old Java Object (POJO) and EJB Web services endpoints.
- Demo: Watch this demo and learn how to configure and use the WebSphere Application Server and the Eclipse IDE with the Web Tool Project Platform.
- Buy: WebSphere Application Server
