Cross-functionality means having all the necessary people and skills on one self-organizing team. Unfortunately, the execution of cross-functionality is often biased. The main traps we fall into are misunderstanding the value of specialization, hero worship, and not “walking the cross-functional talk” as organizations. Let’s examine each of these pitfalls in the hope that your teams may avoid them.
David Bernstein describes the software profession as an industry of amateurs. He argues that it does not yet have many of the things that a true profession has, such as a defined path of entry or good apprenticeship opportunities. A big reason is that computer programming hasn't been around as long as other industries, but what else will it take for software to rise in the ranks?
From his decade of teaching thousands of professional software developers how to be effective with test-driven development, David Bernstein has learned that there are three key ingredients for mastering TDD: understanding what it really is, making code reliably testable, and getting hands-on experience. Let’s look at each of these factors to see what it takes to use TDD effectively on your projects.
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.
It’s usually easy and inexpensive to set up a continuous integration environment for either an agile or a waterfall project. Perhaps the most obvious benefit of CI is the elimination of the integration phase that existed in traditional waterfall projects, where we typically slip the worst on deadlines. But there are many other benefits to continuous integration that you may not have considered.
How you think about software design can have a big impact on how effective you are when you do it. All of us have different criteria for success, and some of them aren’t even conscious. We have to figure out what resonates for us so that we make the right choices, and we can get a clue about the right choices for us by looking at the metaphors we use when we talk about software.
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.
As teams strive to move to a mature agile process, technical writers must adapt as effectively as the development personnel. This new agile process demands that knowledge dealing with software or product releases is only sparingly documented up front, making the technical writer's job of gathering information much more dependent on talking with people over reading requirements.
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.
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.