Articles

Changeable code The Value of Test-Driven Development when Writing Changeable Code

Writing changeable code makes it easier and more cost-effective to add features to existing software. Writing changeable code doesn’t take longer, but it does require paying attention to certain things when building a system. It's important to have a good suite of unit tests that support refactoring code when needed, and test-driven development helps you create independently testable code.

David Bernstein's picture David Bernstein
Pencil to paper Document Why as Well as What: Finding the Purpose of Your Software

Code can express what we want to accomplish, but it’s a little more difficult to express why we’re doing something in the first place. The people who maintain code are often not those who originally wrote it, so documenting why helps set a context and gives clues as to what the author was thinking when they came up with a particular design, making developers' jobs easier.

David Bernstein's picture David Bernstein
Lines of code Project Teams Need to Overcome Their Fear of Coding

Many organizations appear to suffer anxiety at the thought of programming. They want to get everyone but the programmers in a room to discuss a project down to the minute and the dollar, without a full understanding of the coding required. But a few hours of code experimentation generates far more understanding than days of debate by architects and analysts. Don't be scared of programming.

Allan Kelly's picture Allan Kelly
Erasing debt on a page Paying Off the Technical Debt in Your Agile Projects

Just as you should not take out a financial loan without having a plan to pay it back, you should also have a plan when incurring technical debt. The most important thing is to have transparency—adequate tracking and visibility of the debt. Armed with the knowledge of these pending tasks, the team can devise a strategy for when and how to “pay off” technical debt.

Nishi Grover Garg's picture Nishi Grover Garg
Code on a computer screen Code Health Kaizen: Self-Organizing for Agile Improvement

People at Ben Kopel's organization were interested in improving their code health. It was something the engineers had control over and leadership didn't need to be involved, so code health was a great candidate for a self-organized initiative. Ben details the meeting they held, their discussions and plans, and how an agile team empowered themselves to improve.

Ben Kopel's picture Ben Kopel
mob programming in action Try Mob Programming to Inspire Team Growth

If you're familiar with pair programming, you know how much it can increase code quality and encourage developers to learn from each other. You should try mob programming—the same concept, but with an entire team of up to eight people and only one keyboard. It's a great way to explore new techniques and solve problems as a team.

Mark Richards's picture Mark Richards
Acceptance criteria checkbox Defining Acceptance Criteria for Agile Requirements

Acceptance criteria can be helpful in expanding on user stories in order to capture requirements for agile projects. However, acceptance criteria should not be a route back to long, detailed documents, and they are not a substitute for a conversation. This article tells you how and when acceptance criteria should be written and employed.

Allan Kelly's picture Allan Kelly
Two birds: pair programming The Benefits of Pair Programming

This article details a team’s experience in implementing pair programming as a way to get work done as part of its agile transformation. It delves into the many positive results from the pairing experiment, as well as some of the negatives that were encountered, and weighs whether developers think pair programming is a worthwhile endeavor.

Tim Groven's picture Tim Groven
Thinking Critically about Software Development BSC West 2015 Keynote: Better Thinking for Better Software: Thinking Critically about Software Development

Software developer Laurent Bossavit delivered the second keynote presentation, about why we need to think more critically about software development. He began his presentation by saying his intention was to make you question what you know—or what you think you know.

Beth Romanik's picture Beth Romanik
Using Your Tools Always Read the Label: Getting the Most from Your Tools

It is possible to find a new, innovative use for a tool, but it’s much more likely that you’ll do better using the tool in the way its creators intended. And whenever you reach for a tool, check that it’s actually going to help solve the challenge you’re facing. This article explains why first and foremost, conversation is more important than a shiny new tool.

Seb Rose's picture Seb Rose

Pages

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.