LAS VEGAS -- One aspect of creating quality software is delivering a product that meets users' needs and expectations. To do that, you must use an agile development methodology.
That's the point both Venkat Subramaniam, founder of Agile Developer Inc., and Neal Ford, application architect at ThoughtWorks, stressed during their presentations at TheServerSide Java Symposium here last week. The reason for that, they said, is that those methodologies allow continuous communication with users during the entire development life cycle.
"Communication is emphasized in agile development," Subramaniam said. "Feedback is extremely important, so you need to put into practices that enhance communication."
Both Subramaniam and Ford said software makers must get away from waterfall development. With waterfall development, a significant amount of time is spent gathering user requirements and creating a requirements document. Developers then have to make many decisions a day based on that document; they're not able to talk with the users who often change what they want as development continues.
"It's a pointless exercise to try to gather all these detailed requirements because they're going to change," Ford said.
People who gather user requirements should instead gather high-level user stories to create a release plan. For every story, provide the business value that developers can focus on when developing rather than doing blind construction, Ford said.
Once developers have the user stories, they can begin coding. They do not need to wait weeks for the requirements phase to be completed. "With agile development, you spend much less time on requirements, and developers spend more time coding. Developers are coding all the time," Ford said.
This gives developers smaller tasks to do in shorter amounts of time, enabling them to show users their work and get feedback. Then the developers can go back and refine their work, repeating the process several times until the users are satisfied.
"The highest priority is to satisfy the customer through early and continuous delivery of valuable software," Subramaniam said.
Interaction is key among developers and between developers and their users or customers, he added. "The longer the gap between requirements gathering and getting users' feedback, the farther off you'll be from your target," Subramaniam said.
The point is to create the simplest possible thing now that meets the requirement and move on, noted Ford. That allows developers to add features later should the customer decide to do so.
The software may take a little longer to develop when using an agile methodology, but it will be more accurate. "It's not important to deliver on time but to deliver something that works," Subramaniam added.
Estimating product delivery
While Ford agreed that it's critical to deliver software that meets users' needs, he acknowledged that it's important to be able to predict when a project will be completed. But developers, business analysts and project managers need to work together on this.
"It's a bad idea to ask developers how long it's going to take to do something because it always varies. Every project has different characteristics," Ford said. "What you can ask is how complicated is this."
To determine the length of a project, the project manager gives the user stories to the developers to decide such things as the programming language that will be used, the architecture and the framework. After that, they sit with the business analyst and go over the story cards and rate their complexity on a scale of one to eight.
The business analyst then determines the load factor using the complexity determined by the developers. This allows them to get a good first estimate that can be honed as they start to get good data.
By using metrics, you can better determine the completion date, Ford said. Find useful metrics for your own situation, such as completion statistics, code coverage and tests, and validate your metrics continuously.
Project metrics should be interesting facts about the project, not Gantt charts and not speculation, Ford added. And the number one enabler of real project metrics is binary completion criteria for all tasks.
In addition to helping you estimate the project completion date, metrics can give you general statistics about the code and tell you how the team is performing. What they can't tell you, however, is the quality of your code; whether your development methodology is good for the project, team or company; how good your developers are; or if your project will succeed.
To determine the quality of your code, you need to test it. "The best metric you could have is a completed test," Ford said.
When using an agile methodology, developers need to acknowledge that even if they're smart, they can make mistakes. And they need to be willing to go back and fix those mistakes.
"Courage is also important," Subramaniam said. "You have to have the courage to say your code is bad and fix it."