mastering maven software team optimization · learn how agile teams win ... convention over...

Issue III | May 2009

Mastering Maven

Software Team OptimizationThe Art of the Ongoing Tune-Up

Honey, I Thunked The Kids Java Meta-Programming Techniques

Rifle-Oriented Programming with Clojure

Make Your Training Dollars Go Further In 2009NFJS brings a high-quality technical conference to your city... no travel required.Many of our speakers are the same people you will see speaking at JavaOne andother national events.

Develop Your SkillsStaying up-to-date can be overwhelming. NFJS helps developers: improve skills,solve problems, and be productive. The best developers possess many talents. NFJSevents deliver a select body of technical knowledge and hands on training. During anevent, there are always interesting sessions available to you.

Learn How Agile Teams WinSoftware is a difficult industry with very high rates of failure. NFJS emphasizes Agilepractices such as: Test Driven Development, Continuous Integration, Code QualityMeasures, and Team Building methods to stabilize your processes and improvequality. Do your work better and faster!

Exchange Knowledge with Your PeersDo you want to solve a problem? Get a fresh opinion. Few developer problems aretruly new! NFJS is a great opportunity to interact with your peers and exchange ideas.

Save Big with NFJS Discounts1) Earlybird Rates - register early to get the best rate2) Group Discounts - NFJS makes it practical to bring your team3) Alumni Discounts - Have you attended before? Watch your email for alumni rates. * Be sure to check nofluffjuststuff.com early to get the rate available.

Topics for 2009Most NFJS events offer 5 concurrent sessions. Throughout the duration of an event,there are sure to be sessions of interest available to all developers. Our content isupdated frequently. Check nofluffjuststuff.com for current session details.

Agile PracticesCore JavaEnterprise Java : EJB3 & JMSArchitecture & ScalingGroovy and GrailsSecurityDynamic LanguagesFrameworks: Hibernate, Spring, JSFAJAX, Flex, RIA, REST

For more tour dates and information please visithttp://www.nofluffjuststuff.com/ or [email protected]

Neal FordApplication Architect atThoughtWorks, Inc.

Ted NewardEnterprise, VirtualMachine and LanguageWonk

Venkat SubramaniamFounder of AgileDeveloper, Inc.

Tour ScheduleAtlanta, GA May. 15 - 17Denver, CO May. 29 - 31Dallas, TX Jun. 5 - 7Columbus, OH Jun. 12 - 14Raleigh, NC Jun. 26 - 28Austin, TX Jul. 10 - 12Salt Lake City, UT Jul. 17 - 18Phoenix, AZ Jul. 24 - 26Des Moines, IA Aug. 7 - 9Boston, MA Sep. 11 - 13Seattle, WA Sep. 18 - 20Omaha, NE Sep. 25 - 27Calgary, Alberta Sep. 25 - 27Minneapolis, MN Oct. 2 - 4Cincinnati, OH Oct. 16 - 18Atlanta, GA Oct. 23 - 25Reston, VA Nov. 6 - 8Chicago, IL Nov. 13 - 15Denver, CO Nov. 20 - 22

Featured Speakers

Issue III

No Fluff Just Stuff, the Magazine | 3

Greetings!

Welcome to our May issue of NFJS, the Magazine. It has been awesome to see the synergy between NFJS, the Magazine and the NFJS tour. Great articles, great sessions make an excellent tandem. We strive to always live up to our name – No Fluff, Just Stuff. Substance trumps Superficiality!

Attendees on the NFJS tour always inquire about what technologies they should be looking at to stay current. I always suggest looking at other JVM languages as a good starting point. Take a look at Groovy, which is very similar to Java. If you are looking for a total mind shift from Java look at JRuby or Clojure. By learning another language, you achieve a different perspective that in the end will help you write better code.

Always remember the person with passion for his/her craft wins. You express your passion by reading technical journals/books, learning new languages, attending NFJS events and pushing yourself to be the best you can be! Keep it up!! We are here to support your efforts. As someone once said; “the reward is in the journey not the destination.”

Until next month,

Jay [email protected]: NFJS, the MagazineTwitter: @NoFluff

NFJSOne Public Training Schedule

Featured Instructor: Jared Richardson

Test Automation Training

Minneapolis, MN June 22nd

Boston, MA July 15th

Reston, VA August 19th

Denver, CO September 16th

Software Team Optimization

Reston, VA June 17th

Atlanta, GA August 26th

Test Automation Overview:Test automation is a difficult, but vital, part of today’s development landscape. This class provides the tools and expertise you need to write great tests at the unit, package, and integration level, as well as addressing the human elements as well. Knowing how to write tests goes hand-in-hand with selling automated testing to your manager and coworkers. We’ll discuss introducing change, effective test introduction techniques, and more.

A solid testing effort shortens the debugging cycle for developers, frees up interactive testers for more advanced testing, and prevents bug regressions from derailing your project. We’ll help you keep your testing effort on course with this interactive three-day course. We’ll discuss and use the latest tools available.

Software Team Optimization Overview:Software teams are always asked to do more with less, but in economic times like these, it becomes even tougher. Our workloads stay the same through layoffs and downsizings. “Do the same work (or more!) with fewer people” is our new mandate.

We’ve got to find ways to tighten our feedback loops, but still be sure we’re getting the right work done. We’ll focus on five key areas to help you do this.

Requirements - Execution - Testing - Deployment - Maintenance

Go to www.nfjsone.com for registration details for all public training offerings.

{may2009}

4 | NoFluff JustStuff .com

Contributors

Publisher: Jay Zimmerman

Editor: Andrew Glover

Layout/Design: Alicia Weller

Author Contributors for Issue III:

Jared Richardson

Stuart Halloway

Matthew J. McCullough

Howard Ship

Wendell Burton

Letter from the Editor

Reading the various articles that appear in our third edition reminds me of an apt quote attributed to John M. Richardson that both summarizes this month’s issue as well as leverages the number three:

“When it comes to the future, there are three kinds of people: those who let it happen, those who make it happen, and those who wonder what happened.”

Indeed, reading Jared’s “Software Team Optimization” article certainly sets the stage for how one can improve a team as well as one’s self. Optimized teams (and people) make things happen -- those that let situations take over end up on the wrong side of history (or would that be the wrong side of a career?). One only need to think about well known projects (and teams) that made things happen and thus survive in our collective lore. Think putting a man on the moon or even the teams behind Twitter, Google, or Amazon. In fact, the readers of this magazine and the authors themselves represent a troupe of high-speed individuals that make things happen.

From that standpoint, it should be no surprise that those that make things happen are aware of new technologies or of innovative techniques that enhance existing technologies. Stuart’s Clojure article examines an upcoming language that is already making headway. Will you make something happen and see if Clojure could help you and your company, or in the future, will you wonder what happened when you fail to get that coveted job at that new company that adopted Clojure (or Scala or Ruby or Groovy) a few years back and thus doesn’t see you as a team player since you’re a one trick Java-pony?

Matthew’s Maven article also points out how to make things happen -- Ant is by far the ubiquitous build platform for Java, but Maven sure does have some appealing features that have more and more people leveraging it for new projects and even having them migrating off of Ant. Will you make something happen and solve that dependency nightmare on your current project by leveraging Maven, or will you wonder what happened when someone else does?

And speaking of wondering what happened -- do you find yourself confused when people rave about Rails or Grails and all their collective magic? Ever wondered where that magic comes from? Metaprogramming is essentially all about programs altering their own behavior, and as Howard points out -- it isn’t something limited to Ruby or Groovy. You can do it in Java! Talk about making something happen -- his article opens up a whole new world for those limited to a Java only environment.

Lastly, Wendell’s examination of software maintenance and our willingness to seemingly ignore it speaks to the notion of letting things happen. Are you on a project that just let the expense of software maintenance skyrocket because nobody made something happen early on by optimizing the software process to leverage CI and TDD? There’s still time to make something happen and wrestle those costs down!

Indeed, John M. Richardson’s quote hits the nail on the head, don’t you think? Now go make something happen and read our third issue!

Andrew Glover

Table of Contents

Software Team Optimization:The Art of the Ongoing Tune Up 5 - 11

Rifle-Oriented Programming with Clojure 13 - 17

Mastering Maven: Convention over Configuration conquers the Build Process 18 - 26

Honey, I Thunked the Kids: Java Meta-Programming Techniques 27 - 33

An Inconvenient Truth 35

Issue III


Software Team Optimization: The Ar t o f the Ongoing Tune Upby Jared Richardson

Software teams are always asked to do more

with less. If you estimate a product should take

three months, you’re asked to deliver in two. If

you tell management you need ten developers,

you’re given eight. How do we ensure our teams

are operating at top efficiency? How can we

make sure that we’re doing all we can with what

we’ve got? Here are some essential truths about

software teams and the software development

lifecycle that none of us can afford to ignore.

Software Development (Creating the Unseen)

Developing software is a difficult task even in the best of times. We gather requirements from customers who aren’t practiced at describing software, we translate those instructions into a workflow, then translate those ideas into a programming language that our customers can neither read or understand. We put a GUI on top of these ideas, then we ask the customer if we hit the mark. All the time we’re working with a hodge-podge of developers, ranging from novice to expert, but each with a completely different style and background. None want to be told where to put their brackets, much less how to “improve” their coding and architectural ideas. Not surprisingly software projects have an astoundingly high failure rate.

We Can Do BetterThere are two principles that we can use to transform this process. When we look at the new software methodologies, many of them are applications of these two ideas. Before we look at the steps, let’s understand the principles. Then you’ll be able to tweak the steps to suit your team.

Creation is Hard. Editing is Easy.Writer’s block is a fairly well-known phenomenon. It occurs when the writer can’t decide what to write next. It’s common enough that we can find dozens of techniques to help us overcome writer’s block. But who’s ever heard of editor’s block? I haven’t. And that’s the core of our first principle.

I never really learned this until I started writing my first book. My publisher kept pushing me to churn out content, then revise it into something worth reading. As we moved through the process, I came to see his wisdom. Generating an initial idea is the most difficult part. Once you’ve got an idea on paper, you can edit endlessly. The end result rarely looks like the initial scribbled notes, but those initial scribbles are what gets us moving. The same is true in software.

When you need information from a customer, how do you ask? If you request a list of their top priorities, you’re asking them to create. Instead, provide them a list and tell them it’s what you’re working on next. Then step back and watch the edits.

When your trying to document a new workflow with a customer, you’re creating. That’s hard. Instead, see how quickly you can get a basic idea running, then show it to them. You’ve moved them creation (hard) to editing (easy).

Who bears the brunt of this additional work? Who’s tackling the hard parts? You are. While it may not seem fair or fun to tackle the hard work, it’s actually very smart. You want to be the developer (or team) who’s invaluable. If your team consistently hits the target, satisfying customers and getting usable results, your job is secure.

Tighten Essential Feedback LoopsThe idea of a feedback loop is a basic idea in almost every area of life. If I see my children drawing on the wall with a crayon, I stop them. I usually provide a bit of negative feedback as well. If I didn’t provide feedback to my five year old, what would happen to my house? She’d think everything was fine and keep drawing on the walls. Before long every wall in my house would have a bit of “modern art” on it.

{teamOptimization}


Delaying feedback sends two messages. The first is that what she’s doing is okay, and secondly, that I don’t care what she does. Her behavior, good or bad, becomes habit. Practice doesn’t make perfect… practice makes permanent.

So let’s first identify what’s an “essential loop.” Then we tighten it. Rather than wait for my daughter’s birthday to provide feedback, I tighten the loop by walking over as soon as I see the behavior. I usually try to provide a bit of “negative feedback” as well.

There are five key areas in the software development lifecycle that we must target.

• Requirements• Coding• Testing• Deployment• Maintenance

Each has it’s own set of feedback loops we can tighten, but only you can decide which areas your team should target.

Requirements (I’ll Know it When I See it)Deciphering what a customer wants is always a challenge. Sometimes the customer “knows” exactly what they want, so you provide what they asked you to create. When you’re done, they decide you must be a bad developer, because the software you created doesn’t match what they think they described. Other times the customer has no idea what they want, and they still aren’t happy with what you present them. Requirements gathering is often a thankless job.

It’s All in Your HeadIn the bestselling book Made to Stick, the authors describe a fascinating social experiment. A group of people were asked to tap out a song while the another group of people tried to guess the song’s name. Unfortunately when trying to tap out a song like “The Star-Spangled Banner,” we hear the song in our head. Our minds fill in all the extra notes, drums, and entire orchestra. Unfortunately our audience can only hear us tapping. In the experiment they cited, only 3 out of 120 songs were identified by the listeners. That’s a 2.5 per cent hit rate!

This is the same problem we encounter gathering requirements. The person describing the requirements has an idea in their head. They’re trying to tap out the

requirements clearly, but it’s just not possible. There’s too much context tied up in their head.

Many software methodologies, especially waterfall, try to compensate for this lack of context by spending a long time tapping out requirements. Months, or even years, are spent tapping out requirements, interviewing users, sketching out GUIs, and mocking up pictures of the product. In the end, this enormous effort is only marginally better than a quick and dirty approach, and has the enormous disadvantage of letting the industry move on, while your customer is stuck waiting for us. By the time we’re done extracting requirements, then creating the product, the customer needs something different! Most of our hard work is wasted.

How can we do better?

Edit or Create?The classic requirements scenario has everyone creating requirements, and this is why it’s so difficult. Creation is an inherently difficult task. Let’s find a way to let the end user edit, not create.

The best way to do this is to present the user your working software so they can use it, then offer you feedback. Unfortunately, working software takes a long time to finish. There are two shortcuts we can take to make this easier.

Our Journey of a Thousand Miles Begins with a Single Step

As the old proverb says, you’re going to take any journey one step at a time. Software can be created the same way. This is one of the ideas that several agile methodologies focus on with the “time-boxed iteration.”

An iteration can last from one to four weeks, but at the end of it, each feature must be “done” (for some definition of done.) The goal is to break down our huge product into a series of more granular features. Work on these features in the order that your customer thinks is most important (when you can). Then, as you finish a feature and demo it, you can find out more about the context in your customer’s head.

Never wait for a project to be nearly done before showing it to the customer. Always get the product in front of the customer as soon as possible and listen carefully to their feedback. Your choice is to spend the

Issue III


extra time breaking down and completing features so the customer can see them and you can adjust, or wait until you’re done with the entire project and then finding out you completely misunderstood the message the user was tapping. Move from tapping to singing. (Please note that if you sing as well as I do, that still might not be the correct communication medium.)

We have more than one way to get that feedback though.

Mock ObjectsMock objects are especially useful when trying to make a GUI appear to run. Suppose you’ve got a screen that the user will use to run data analysis. If you “mock out” the server components, such as login ,fetch_a_data_set, or analyze_these_data_sets, then the user can click through the “working” GUI and see how the product will really work.

Of course, it’s not actually working, it only appears to work, but this approach let’s the customer use the product months before the database code is done. It’s a great way to avoid the long feedback loops we run into when we can only get feedback at the end of the product cycle.

This idea is more fully fleshed out in the idea of tracer bullet software development. When you use tracer bullets, you focus on mocking out every major subsystem in the project. This allows you to see exactly what works and doesn’t long before you normally could. Architectural and technology choices can be validated, or eliminated, months before a waterfall project would even be aware of their problems.

Tracer bullets moves into the realm of “macro object orientation,” but the idea is easy to follow. Instead of writing an entire database access layer, start filling in your database layer’s API with canned data. Then the other parts of the system can use the API, with an apparently working, very basic, set of functionality. Use this to discover what’s missing, or just wrong, long before you’ve completed all the hard work of implementing the low level database calls. You end up with an entire system of macro mock objects. It’s a fascinating and empowering way to write software.

25 or 5,000?Large releases tend to have hundreds, or even thousands, of new features. When we ask for help deciding what we should write first, the answer is usually “Yes!”. Ignoring that this is a complete abandonment of responsibility, let’s trick them into telling us what they want anyway. Remember the create or edit idea? When we ask for a “top 10” list, we’re asking someone to create a list, and that’s hard, so they punt.

Instead, we create a “top 10” or “top 25” list, in the order our team will add each feature. Provide that list to the customer, manager, or stakeholder, and tell them this is what’s coming next, and they’ll provide edits immediately. By creating the list, you gave them something to edit, and editing is much easier than creating.

Fence Me InA great tool to drive the shortened list is the time-boxed iteration mentioned earlier. Present your list to the customer and tell them it’s what you’re putting into the next two week iteration. This creates a sense of urgency, as well as an excuse for having the list back by a certain date. Tell them you’d love to have all 10,000 items as a top priority, but you need to identify the work for the next two weeks.

Coding (Training Cats)Here’s an area where it’s easy to cause more problems that we solve. How do we provide feedback to developers on their coding styles or feature implementation? Most developers have huge egos. If you don’t realize this, you’re one of the problem people. ;) How can we sidestep these egos, while still providing feedback? It’s easier than you think.

The Backup DeveloperMost teams have a set of practices that everyone is expected to do, but no one does. Or even if they try, everyone makes mistakes. Instead, let’s bring in a backup developer. Every time someone checks in code, let’s run a clean compile, just to be safe.

Then let’s also get a full-time tester to run every testing scenario, on every platform we support. Immediately.

When a developer in our shop checks in code, let’s have this feedback available in less than 30 minutes. Sounds prohibitively expensive? It is if you use people,

{teamOptimization}


but if we take a cue from John Conner of Terminator fame and use machines instead, it’s not expensive at all. Of course, T-800 model terminators are hard to come by, so we’ll use open source software instead.

Continuous integration is a great way to provide feedback to developers. It runs 24/7. It never

misses a code check in, and never complains that the tests are taking too long to run.

I find that developers who don’t like other developers or testers critiquing their code don’t seem to mind continuous integration software doing the same thing. If your CI system is running FindBugs and a good suite of tests, the feedback can be automated. This seems to sidestep the ego problems some developers have.

Testing is Hard!Most people agree that it’d be great to have a solid test suite, but it’s hard to create those tests. And they’re absolutely correct. Creating tests is hard, but editing tests is easy. (Does this sound like something you’ve heard before?) So let’s set up your team to edit tests, not create them.

BlitzkriegHave a single person on your team look at the available testing tools, pick one that works for your product, then create basic test templates for each area. Nothing comprehensive, but a “hello world” test for each major area of the product. If there are five main pages for the GUI, then they create five tests. If the product has 20 APIs, each API gets a basic test.

Other developers, or testers, now have templates to copy. They’re no longer creating, but editing. We’re making it as easy as we can for other team members to add to the test suite.

We want the tests for several reasons. The first is the edit/create principle. It’s easy to edit and hard to create, so we want to make it easy to edit the existing tests. The second reason we want automated tests is a tighter feedback loop for your developers.

Tighten the LoopWhen a developer edits code, we want the tests to run as quickly as possible. Then, if any of the product’s functionality is broken, the developer is notified within minutes, and with no other user intervention. Sometimes the developers will run some of the tests on their desktop, but they rarely run them all, and their desktop doesn’t look anything like the production environment. We want to run every test we have and run them against the realest scenario we have.

Testing (Didn’t We Just Cover Testing?)We did just discuss testing, in the section on providing developers with feedback. It’s a sad truth than many developers think testing is the job of QA or dedicated testing staff. The most effective shops I’ve seen share that responsibility. Developers and testers both contribute automated tests to the suite. This is the best way to build up a test suite that addresses both developer’s internal concerns, and tester’s acceptance test concerns.

And this is still an area that’s only now becoming commonly accepted. Humans just can’t work as fast as machines, and machines can’t do creative work. The best way to be tune up your team is to automate the repetitive work, then free the humans up for the more interesting, edge-case testing. There’s no reason a human tester should do “Hello world” click through testing on five platforms when a continuous integration suite can do it faster and more reliably. Instead, let’s get the human to exercise the more interesting parts of the code. You know what they are… they’re the ones that didn’t get tested in the last release.

The same principles we mentioned in the previous section apply. You want to help your team edit, not create, and then we want to tighten the feedback loop. The sooner a developer finds out they’ve changed the code in a way that breaks something, the sooner they can fix the problem. And hopefully learn from the experience and not repeat the problem in other areas of the code.

Deployment (Doctor, It Hurts!)Many years ago a man visited his doctor, stuck his finger in his eye, and said “Doctor, it hurts when I do this.” “Well then”, said the doctor, “don’t do that.”

It’s the simplest of all advice, but we often forget it. We think that in our case, it’s okay to be painful. Time and time again I see shops who deploy their product, then stay up with it all night patching bugs. Some teams mark off a week to stabilize their product after they’ve deployed it. Other times the code and database

Issue III


are almost in sync, but not quite, so the developers and the database admins stay up all night. There’s no good reason to work with way. We can automate deployments, just like we can builds and test execution. Does it “hurt” to deploy your product by hand? Then don’t it anymore.

We can use a tool like Ant to deploy our code. It can “exec” anything, knows about FTP and SSH, but there’s an awful lot of coding to make Ant jump through those types of hoops. Instead, let’s look at a few tools designed to deploy code.

Capistrano is a tool from the Ruby community, but it’s intended to be a language neutral tool. It allows you to set roles for different machines (database versus application server) and understands the notion of transactions.

Once you’ve created a decent deployment script (with whatever tool you prefer), you can deploy to production, staging, testing, or even to a developer’s desktop. Recreating your environment becomes trivial… developers and testers don’t have to spend their days restaging boxes. They just rerun the deployment scripts. If this sounds insanely easy and useful, it’s because it is.

Databases Aren’t CodeAnother area that can usually be cleaned up is database updates. We tend to do this all by hand, and even have a special priesthood of those worthy to touch the production databases. Instead, let’s script the database updates too. Databases aren’t code is a phrase you’ll hear. That’s true, they aren’t… but SQL is. In fact, it’s just flat text. There’s no reason that these changes shouldn’t be in the source code management. It’s just as irresponsible as the cowboy coders who refuse to check in their work.

I love the Rails concept of database migrations. It’s got a clean syntax, a well-tested system, and is worth keeping a Rails instance around just to handle your database migrations. It knows how to move your database schema from version 17 to 19, then back to 12 if need be. When you tag your code for deployment, you tag the database description files as well.

This not only is an enabling technology for your deployment scripts, it also makes it trivial to set up in any environment. We can recreate a database on a developer’s machine, or a staging environment. And we can test against the same changes that we’ll push out

to production later. Instead of running SQL by hand against the production system (during an upgrade), we’ll re-run the same script we used in development, testing, and the staging environment. We’ve made database updates reproducible. Creating a database for the new team member just became trivial as well.

Of course, you don’t have to use Rails to handle your database migrations. There’s an open source Java tool called Liquibase. I know many Java developers who love Liquibase, but I find the XML they use to describe the updates to be insanely verbose (and I usually don’t mind XML!)

Maintenance (Everyone’s Favorite Job)Doesn’t every developer love to get assigned to a maintenance project? You have no idea what the original developers were thinking, what their code does, and add insane time pressure to add features and fix bugs. There’s generally fewer testers helping to verify the changes didn’t break anything… this maintenance job is starting to sound like not much fun at all!

In fact, maintaining some else’s code usually isn’t very fun. For that matter, it isn’t fun to maintain your own code! We creative types love to build something, then move to onto something else cool and new. Last year’s projects get dumped on the younger developers, the less politically savvy, or the person unlucky enough to miss the meeting.

Unfortunately, most successful projects spend more time and money in maintenance than any other area. It becomes a difficult and tortured job because the entire knowledge base has moved to another project. We make changes while trying hard to follow the Hippocratic Oath (“First, do no harm”), but invariably we break something, and bugs make it out to customers.

How do improve our feedback loop during maintenance? Whether we’re fixing bugs, adding features, or porting to new platforms, the answer is the same. Test automation.

A good suite of automated tests, created during the product’s development, ensures that the original developer’s and tester’s intentions aren’t violated accidentally. Imagine working on an older product and having a test suite that tells you exactly what still works and what doesn’t? You could move the product from XP to Vista and find any problems in minutes. What if you’re porting from 32 bit Linux to 64 bit?

{teamOptimization}


How do you perform a comprehensive regression test? Automatically. Run the suite, and get a report on exactly what the problems are, if any.

Want to add new features? Put in a cache to help performance? Move to a new application server? Validate a new JDK?

If you’ve ever been in any of these situations, you’re smiling right now at the thought of this type of safety net. Add in a continuous integration system, and you’re in a very good situation.

Change the Oil NOWHave you ever put off changing the oil in your car? Many of us, when we were younger, didn’t change the oil in our cars, or even our lawn mowers, when we should have. And after we let it go for a few months, it just fades into the background, a forgotten task. Really just a waste of time and money. After all, the car is still running, right? Yes it is.

Right up until the moment it stops.

Once the engine locks up, it’s too late to change the oil. The small bits of metal have multiplied, perhaps the oil leaked out, and now the pistons are frozen in place. A major repair is due and it’s going to cost a lot more than we saved skipping those oil changes.

Our software teams are the same way. There are practices like test automation, continuous integration, time-boxed iterations, daily meetings, and more, that we could use. We often see the benefit, but we don’t really believe it. We “change the oil” because our parents nag us. Then one day, the product is so overwhelmed, we can’t add anymore features, or fix anymore bugs. It’s cost prohibitive. So the team says, “Okay, you can add a test now.” That’s like trying to change the oil after your engine locks up on the highway. It’s just too late. If you don’t start right now, you probably never will.

PerspectiveHow do you know where to focus? We briefly touched on five major areas: Requirements, code, testing, deployment, and maintenance. In each area, we barely scratched the surface of potential problems and solutions.

We also talked about the two keys to team optimization. Edit versus create and feedback loops. It’s always easier to edit something that’s existing than

it is to create something from scratch. That’s why software development tools have so many bundled code examples.

And feedback loops are how we all learn. It’s how we catch our mistakes and correct our miscommunications. In each of the five areas, we can identify feedback loops we can tighten to ensure a better, more targeted product. Tightening these loops eliminates irrelevant work and leads us into an automation mindset. Anything that’s automated can be run more quickly and more .

When you start to look for the areas your team’s trouble spots, don’t be afraid to bring in a third party to observe. I’ve often come into a client’s site for two to three days with instructions to watch the team work and make suggestions. It’s amazing what a fresh point of view can do for your team, especially if you suspect you’ve got a few blind spots.

Another place to search for problems is the lunch table. Sit down with the team, and listen. When you ask a team what their problems are, they’ll tell you what think their problems are. This tends to bring up known problems, but misses any blind spots the team might have. So instead of asking, listen to the complaints. When several people complains about any single issue, you know it’s a problem. Another way is to get people together and add beer. Stop taking notes after the third or forth round though…

Once you’ve identified a problem, remember our two key ideas.

It’s hard to create and easy to copy, so provide examples for people to copy.

Then remember that any feedback the team gets needs to be shortened. If the existing feedback loop was sufficient, you wouldn’t have a problem today.

When should you start? Today. Who should act? You.

Issue III


References

Made to Stick by Dan Heath and Chip Heath, http://www.madetostick.com, p. 19 “The Curse of Knowledge”

Ship It! A Practical Guide to Successful Software Projects by Jared Richardson and Will Gwaltney , http://www.pragprog.com/titles/prj/ship-it, p. 104 Tracer Bullet Development

The Pragmatic Programmer by Andy Hunt and Dave Thomas, p. 48 Tracer Bullets

“Ready, Aim, Release” by Jared Richardson, Better Software Magazine, September 2007, http://www.stickyminds.com/s.asp?F=S12760_MAGAZINE_2

“Continuous Integration” on Wikipedia http://en.wikipedia.org/wiki/Continuous_Integration

John Connor, leader of the human resistance, http://en.wikipedia.org/wiki/John_Connor

Terminator skull, http://www.flickr.com/photos/kadath/2986014832/

“The Case for Continuous Integration” by Jared Richardson, NFJS: The Magazine, March 2009, http://www.nofluffjuststuff.com/magazine_subscribe.jsp (see the free sample link on the page)

FindBugs, an open source static code analysis tool, http://findbugs.sourceforge.net/

“Blitzkrieg Testing” http://www.jaredrichardson.net/blog/2005/06/23/

Capistrano: An open-source deployment tool http://www.capify.org

About the Author

Jared Richardson, co-author of Ship It! A Practical Guide to Successful Software Projects, is a speaker, consultant, and mentor with NFJS One. Today he speaks at conferences, teaches classes, and helps teams work more efficiently. Jared has been in the industry for more than fifteen years as a consultant, developer, tester, and manager. He can be found on the web at http://NFJSOne.com and http://AgileArtisans.com

NFJS One provides access to the top technical talent in the industry. Our services include: in-depth

public and private training sessions, project consulting engagements, team mentoring, and on-

site private events.

Investing in your people should be your number one priority

The benefits of keeping your folks sharp and ahead of the curve are endless:

Increase your organization's productivity Reduce development costs Accelerate employees' learning curves

The NFJS One Model:

NFJS One takes pride in ensuring a recognized expert is matched to your organizational strategies and initiatives. Whether it be a private 3 day training class on a specific tool, an organizational assessment, a project coach, etc. Our first goal is to get a grasp on your environment today.

What are your strengths/weaknesses (toolset, process, initiatives, etc)? What challenges are preventing you from meeting your goals?

Once we come to an agreement on services and benefits, NFJS One will align you to one of our 75+ experts – ensuring this person is a 5 star resource on the subject matter at hand.

Training:Our courses range from beginner to expert on various tools, process, frameworks, languages and more. We align our courses to your environment, and don’t come in for a lecture – be prepared to get your hands dirty and leave ready to use what you’ve learned tomorrow.

Mentoring/Consulting:We have various models to meet our customer requirements, including organizational assessments, agile coaching, and technology evaluations

Private Events:NFJS One is an entity of the No Fluff Just Stuff Software Symposium. If you are ready to host a professional conference with the best speakers in the industry – NFJS One is your provider.

NFJSOne.com877-825-0663 ext. 2

[email protected]

Issue III


Coming up next month

The NFJS tour travels to the beautiful cities of Dallas, Columbus, Ohio, and Raleigh. Plus, NFJS,

the Magazine will feature another article from Venkat Subramaniam on Scala and new articles

from Srini Penchikala on leveraging AOP, Drools by Brian Sam-Bodden, and one from David Bock.

Until next month, enjoy reading May’s articles and remember -- make something happen!

mastering maven software team optimization · learn how agile teams win ... convention over...

Documents