Articles

Partially open computer showing a bright screen Software Development: An Industry of Amateurs

David Bernstein says the software industry is an industry of amateurs. It's a young field, and he doesn’t think it's yet graduated into a true profession. Here, David contrasts the software industry with other, more established fields, and he talks about what software professionals need to do in order for the industry to become accepted and esteemed.

David Bernstein's picture David Bernstein
Sticky tags that say "Hello, my name is," photo by Jon Tyson What's in a Name? Build Better Software by Naming Classes and Methods Clearly

One of the most important things to pay attention to when writing software is how we name our symbols. Data and behavior should be named in a way that represents the essence of what we're trying to do. Naming affects understandability and reflects code quality, so use names that clearly communicate your intentions, and refactor those names when your intentions change.

David Bernstein's picture David Bernstein
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

Pages

AgileConnection is a TechWell community.

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