In my experience in media companies and academia, developing or implementing new software is almost always a painful process. The people who are going to use the software can’t communicate what they want, and the developers don’t understand the end users’ needs. The developers think the end users have unreasonable expectations, while the end users think the developers are dragging their feet. Software projects are always behind schedule, and even after completion, everyone involved is dissatisfied with the results.
Such a scenario is bad enough when it plays out in the workplace. But the journalism "innovation project" I’m directing this term — involving the first two Knight News Challenge "programmer-journalist" scholarship winners and four other Medill School master’s students — simply couldn’t have these kinds of problems. Delays aren’t an option because the class has to wrap up by the end of the academic quarter, and frustrations with software development could leave the participating students with a sour taste in their mouths. Plus, the whole assumption of our Knight News Challenge grant was that software developers with journalism training could team up successfully with other journalism students and create something important for the future of journalism.
All of which is why I became interested in different kinds of approaches to software development — approaches with names like "extreme programming," "scrum programming" and "agile programming." Brian Boyer, one of our programmer-journalists, is a devotee of "agile programming," and our class has adopted this methodology. Brian is posting periodically to the class Web site about the agile approach — read the first two posts here and here.
After the first week of software development, I’m becoming an "agile" fan. Here are some of the things I like:
- The process nicely separates idea generation, design, coding and testing, which means different people can be responsible for different aspects of the project.
- Software development starts only when there is a clear vision for the design of a particular component.
- People who are not programmers themselves can be effective collaborators in software development.
- Programmers know exactly what they need to complete in each "iteration" of the software.
- User feedback is embedded in the process, reducing the likelihood that software development will go astray.
I’m also seeing that agile programming might be an ideal approach for collaborations between journalists and technologists — or journalism students and computer science students.
Amy Gahran, my fellow Knight News Challenge winner, blogged this week about the need for journalism schools to collaborate with computer science programs, but I know from experience that it’s difficult to make such collaborations equally valuable for students and faculty in both disciplines. In part, this is because journalists and programmers have different ideas about what kinds of problems are interesting to solve. Beyond that, there are cultural and communication gaps that I described earlier this year in a report from the first Computation + Journalism Symposium:
Too many journalists don’t respect technology development as a creative activity — they think developers should just build stuff they want. Too many technologists don’t respect journalism as an intellectual activity — they think journalists just pump out content for their algorithms to process. Too many journalists really don’t like technology change; they blame it for hurting media businesses, threatening their livelihoods and diminishing the quality of news available in local communities. Too many technologists think it’s not their job to worry about the negative impact of technology innovation on media companies and journalism — and when they do think about the consequences, think only about information at the national and global level (which is broader, deeper and more accessible than ever) and not at the local level (where online news ventures rarely do the kind of original reporting that newspapers do).
Agile programming offers a potential bridge between the worlds of journalism and technology. It imposes a structure that journalists (or journalism students) can learn to work with, and it forces them to carve a software project up into manageable chunks. It also clarifies and simplifies the work that developers need to do, protecting them from changing whims of people (such as journalists) who don’t have a deep understanding of how programming is done.
The software my class is developing is intended to improve online conversations around news, especially involving young adults. In the first week of software development, the development team figured out how to use Facebook Connect, a soon-to-launch tool allowing integration between Facebook and another Web site. Meanwhile, the design team mocked up an approach to a new kind of "comment structure" — one that will enable a user to ask a question about an article and get answers from other users.
This week, the development team is going to build the question-answer tool, while the design team comes up with an approach to another type of user interaction.
Next week, the development team will get to work on the second user-interaction tool, while the design team works on a third one and our "consumer insights" team gets feedback from end users on the question-and-answer component.
Even with just four or five weeks to focus on software development, I’m seeing that agile development provides our students with the structure they need to achieve a successful result: functional software that offers new approaches to user interaction related to news.
You can follow the class’s further adventures on the Crunchberry Project Web site.