|
Picking the Right Branch-Merge Strategy A good branch-merge strategy facilitates processes among multiple developers and is the basis for any well-functioning DevOps pipeline that uses continuous integration. Let’s explore branching strategies, merging strategies, and how you can put them together in a way that’s right for your team in order to bring quality features to production faster.
|
|
|
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.
|
|
|
Examining Cross-functionality Bias on Software Development Teams 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.
|
|
|
When Software Development Becomes a True Profession 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?
|
|
|
3 Keys to Mastering Test-Driven Development 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.
|
|
|
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.
|
|
|
Why You Need to Be Doing Continuous Integration 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.
|
|
|
Find Your Metaphor for Agile Software Design 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.
|
|
|
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.
|
|
|
Fitting Technical Writing into Agile Development 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.
|
|